STM32 X-modem/Y-modem/Z-modem

[kkraus]

Posted on February 18, 2010 at 13:57

STM32 X-modem/Y-modem/Z-modem

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

The ST implementation for Y-Modem is a dumbed down implementation derived from an open-source version. I would not recommend it as a general solution. I'd be pretty sure there are vendors for embedded libraries supporting these and other protocols.

What kind of application are you working on? Wireless modems often support TCP/IP directly. -Clive

[armmcu2]

Posted on May 17, 2011 at 13:40

Hi,

From my knowledge the Ymodem protocol is well supported/sourced in AN2557 application note available in ST web site.

No idea about Z/X modems.

[trevor23]

Posted on May 17, 2011 at 13:40

Xmodem will pad the end of the file so that a file is always a multiple of the Xmodem block size. This is OK if you know the length of your file by some other method (e.g. header in the file etc.) . Ymodem does not suffer from this issue as the file length (and name) is transmitted (in the first block I think).

You might be able to remove the Xmodem padding if the file is ASCII but if it's binary it will not always be possible to remove padding as the last byte of the file might be a pad character.

[Andrew Neil]

Posted on May 17, 2011 at 13:40

Xmodem is an extremely widespread - almost ubiquitous - protocol. It should be easy to find a microcontroller implementation.

One of the beauties of Xmodem - apart from its ubiquity - is also that it is very simple. So it isn't hard to implement from scratch. The only difference between Ymodem and Xmodem is that Ymodem adds the facility to transfer multiple files - the block structure & block protocol is identical; it just makes a special case of ''block0'' to transport the filename. The Xmodem/Ymodem protocol specification is widely available for free on the internet, and gives everything you need to know to implement it from scratch; eg,

http://www.techheap.com/communication/modems/xmodem-ymodem_reference.html

http://www.techfest.com/hardware/modem/xymodem.htm

[Andrew Neil]

Posted on May 17, 2011 at 13:40

Xmodem (and, thus, Ymodem) use a fixed block size (128 or 1024 bytes) - hance the ''padding''.

The issue is discussed in the article I cited earlier. If you are sending a file, you will know its length from the filesystem; If you are transferring arbitrary data, then your application will have to decide  a suitable way to deal with this.

[trevor23]

Posted on May 17, 2011 at 13:40

While the sending end can know the file size from the file system the point is that the receiving end does not know the file size (unless it acquires it by some other method as outlines above).

Padding in Ymodem is not an issue as it is part of the Ymodem receivers job to not put the padding bytes into the received file. Regards Trevor

[Andrew Neil]

Posted on May 17, 2011 at 13:40

Oh yes - I get you now!

When using Xmodem for a firmware update (as in the app note), the block can be safely padded with FFs - as that's the erase state of the Flash...

[trevor23]

Posted on May 17, 2011 at 13:40

The pad byte is control-Z I think, not FF. I (like you) prefer to use Xmodem over Ymodem (simpler and smaller and supported by TeraTerm) but I always have a length in a header at the front of my firmware file and I therefore can ''tweak'' my Xmodem receiver to not pad. If I need to support other binary files I use Ymodem if I can't live with the padding.

Regards Trevor