SMB/CIFS for uTasker/Coldfire?

On 9/9/2016 5:01 AM, David Brown wrote:
> On 09/09/16 13:05, Don Y wrote:
>> On 9/9/2016 3:20 AM, David Brown wrote:
>>>>> For TFTP, it is simpler if you stick to 512 byte data blocks (plus
>>>>> the 4
>>>>> byte TFTP header).  If you are looking for optimal transfer speed of
>>>>> large files, it is worth negotiating bigger block sizes (assuming both
>>>>> sides support it), but for 4.5 KB it is easier just to send 9 packets.
>>>>> You also don't want to deal with big UDP packets when your
>>>>> microcontroller has little ram - why mess about trying to put together
>>>>> separate Ethernet frames into a single UDP packet when you can have the
>>>>> packet entirely within one frame, and use it directly without any
>>>>> copying?
>>>>
>>>> A smarter move is to negotiate a larger window size.  So, the "next"
>>>> transfer can begin before your acknowledgement of the earlier one
>>>> has been received.  But, you have to 'remember more' to implement this
>>>> (on server and client).
>>>
>>> UDP does not have a "window size" - it has a packet reassembly buffer
>>> size.  And with TFTP, your next transfer /cannot/ begin before the
>>> acknowledge of the previous packet is sent - that is fundamental to the
>>> TFTP protocol.  It is a simple query-response protocol.
>>
>> No.  Later RFC's enhanced the protocol to allow for the sender and
>> receiver to negotiate a number of outstanding yet-to-be-ACKed
>> packets.
>
> Ah, okay.  I have only used TFTP in its original /trivial/ version.  I
> know you can negotiate certain aspects, such as block size (and
> apparently the number of outstanding blocks), but I did not bother with
> such "features".  That would completely miss the point, as far as I can
> see.  And when an 200 KB update takes a second or so, including flash
> erasing and programming, there's little need to complicate things.

It's value is in moving many files and big files without all the
ping-pong activity of (traditional) TFTP.  Negotiate a large
packet size AND a large window size and you will approach/exceed
the throughput of some of the SMB/NFS implementations with very
little overhead on either side.

[The bulk of the overhead is in parsing the messages.  The rest is
pretty simple/obvious.  The downside is you may get NOTHING that
you desire -- if the other party isn't willing to honor your
"enhanced" request(s)]

>> So, if you specify a window size of 8 (packets), the sender can
>> send up to 8 packets (the size of each can also separately be
>> negotiated) before requiring an ACK from the receiver.  An ACk
>> indicates the block number that is being acknowledged.  It
>> *implies* acknowledgement of all consecutive block numbers
>> up to and including the block in question.
>>
>> By way of example, a sender can push packets 1, then 2, then 3, then
>> 4, then 5, then 6, 7, 8 onto the wire BEFORE waiting for an
>> acknowledgement (in the case of a window size of 8).  If it receives
>> an "ACK(8)", then it knows packets 1-8 have been successfully received
>> and acknowledged.
>
> For high throughput, especially over higher latency routes, I can see
> this making sense.  But if I needed something like that I would be
> tempted to make my own simple protocol over TCP and let the TCP stack
> handle all the details here (as well as making firewall traversal much
> easier).

The advantage to the TFTP extensions is that they are a "standard"
instead of a "custom implementation".

I've used X terminals and diskless appliances rather extensively
over the years so have had to deal with various "low profile"
protocols for bootstrapping a system.  For "connected devices",
I now much prefer it to having application-specific resident
firmware; there's never a need to push an upgrade as it is
automatically delivered as an inherent part of the next IPL!

(if the incoming image agrees with the image present in
your FLASH, no need to write "that block")

For implementations with lots of RAM where you can
afford to execute out of that RAM, then there's not even
a need to consider reflashing!

Hi

I didn't understand the exact transmission requirements (apart from that
SMB/CIFS is not required and the processor is a MCF52235).

Based on the opening uTasker reference, I should point out that there
should besically be no problems with UDP or TCP based transfer protocols
on the device since the uTasker TCP/IP stack is optimised for small memory
footprints and RAM and can achieve high speed transfers of large data.

It includes TFTP, but FTP is usually preferred, where it included as both
a client and a server and can achieve must higher data rates:
http://www.utasker.com/docs/uTasker/uTaskerFTP_client.pdf
http://www.utasker.com/docs/uTasker/uTaskerFTP.PDF
(the server has however been upgraded since the referenced server document
to support multi-connection clients)

File transfer are also often done with HTTP where I once did a M52235
based development for ambulance services where there is a voice recorder
built into the medics' emergency box which helps post-analysis of
incidents. We had the sound recordings saved to high reliability SPI Flash
(several hundred MBYTES) and simply used an internal web server to allow
access via an Ethernet cable.

Also Ethernet/IP has been used on the M52233, together with FTP and web
server with total 32k RAM.

My other remark is that today it is very uncommon to start new work with
V2 Coldfires since they are legacy devices. Freescale/NXP has effectively
replaced then with their Kinetis parts (check out the K64) which have many
advantages:
- much more memory
- quite a lot faster
- smaller code size (about half the size compared to Coldfire)
- lower power
- cheaper
- more and better peripherals
- Ethernet includes checksum offloading and so UDP is around 4x faster on
a K70 that on an M52235:
http://www.utasker.com/docs/uTasker/uTaskerBenchmarks.PDF

Regards

Mark

http://www.uTasker.com




---------------------------------------
Posted through http://www.EmbeddedRelated.com