SMB/CIFS for uTasker/Coldfire?

Doh! I've already been through this and forgot: ucLinux will not run with just the piddly 32 kB internal RAM of the MCF52235. You must have external RAM.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
http://www.digitalsignallabs.com

I was about to say something in that line (I just assumed linux etc. heavy things are not meant for MCUs, not by orders of magnitude).

A few years ago I used the mcf52211, stripped down the DPS scheduler (the oldest one which ran on a 68340) and did a few things since, the

16k RAM was plenty in all cases (I had no Ethernet so I did not need deep buffers, if you need these you'll have to put external RAM anyway). The scheduler and the few system calls I used (I/O, hex/dec etc. sort of thing, only 20-30 calls) took about 2k, each task uses 2x256 bytes for stack (system and user stacks).

I suppose you are after some packaged thing to use with C etc. which will be a lot more wasteful though, so none of the above will be much help - hopefully it can be some reference.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

I was thinking the same thing...

The smallest ucLinux system I have seen, on a Coldfire v2, had 2 MB flash and 4 MB ram. But that was an old system, with a 2.0 or 2.2 kernel and very limited functionality. ucLinux is now part of mainline Linux as the "no mmu" architectures, rather than a separate project - but it is not much used. A decent ARM Cortex A or MIPS device capable of running proper Linux is so cheap that very few people use non-mmu Linux now.

Back to your idea of using SMB/CIFS on something other than Linux - I don't think such clients exist. I am not sure how much of the SMB/CIFS client code is in the Linux kernel or in user space. Certainly the Samba "smbclient" utility is available for other *nix systems and for Windows - but I don't see it being suitable for a 32 KB microcontroller.

I think you would need to look at something much smaller and simpler for such a device. Would tftp be suitable? It would let your microcontroller read and write remote files, and should be fine to implement on such a device.

TFTP might be a good idea indeed - mostly because it does not need tcp. The higher level would not take much once he has tcp - e.g. I can look at the dps ftp client and it is just 22k of code (for power). But tcp is another matter, something like 200-300k - and the worst part is the incoming buffering it takes. True I have only implemented it on a power machine with 64M+ RAM and buffering has never been an issue at 100 Mbps, but even taking the trickiest tcp approach will run into serious problems with a total of 32k system RAM, I would not seriously consider such a system (especially nowadays as you mentioned, some time ago some 10Mbps or even UART/ppp ideas might have been explored :).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

Thanks David and Dimiter. TFTP does sound like a great solution and is probably the way I'll go. There was a miscommunication in the requirements and I thought we HAD to implement a SMB/CIFS client. Apparently that is not the case.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
http://www.digitalsignallabs.com

Sometimes clients /do/ try to demand the impossible, which can be inconvenient.

TFTP is quite easy to implement, especially if you stick to the simplest parts (such as fixed 512 byte blocks). There are servers and clients for Windows easily available, and *nix systems will have them as standard. I use it for software updates - with the embedded system being the server side.

Please be warned: TFTP changes the server UDP port after the first datagram exchange. Some firewalls are not smart enough to follow the change, and this may create a broken transfer. If you update the first block of the transferred file before the change, you may end with a bricked target. I recommend saving the first block until the second one arrives (from the changed port), and touch the local storage only after that.

Been there - done that.

This does not mean that TFTP is not good for the simple file update task. It was developed for networked booting with very limited resources, and it is the best standard protocol for the limited situation. IMHO, it is aeons better than a SMB/CIFS solution.

--

-TV

Thanks for these helpful, very detailed, low-level pointers, Tauno. I am just proposing this solution at this point, not implementing it. I will definitely use the information you provided as a reference if I am tasked with the implementation.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
http://www.digitalsignallabs.com

Ha ha ha! Yeah, impossible is slightly inconvenient...

Thanks for the feedback. Sounds like TFTP is the right solution for this task.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
http://www.digitalsignallabs.com