The GHI Firmware Update tool likely uses XModem-1K for file transfers (I think).
I wonder, how are the padding bytes handled? Since XModem uses the character (ASCII 26) for padding in order to fill up a packet, wouldn’t this distort the file length?
For example, let’s say I’m transferring a file that’s originally 1,028 bytes long. The 1st packet will contain 1,024 data bytes, followed by the 2nd packet which will only have 4 data bytes padded with 1,020 characters to fill up the required packet length. Suddenly, on the receiving side, I’m going to end up with 2,048 bytes. How does FEZ know what the original file length is? And what does it do with the padding bytes?
On the surface, you might say, “Oh, if you see a bunch of characters at the end, then it’s padding and it can simply be discarded.” But what if your binary file (firmware file) legitimately does have several characters at the end that really are supposed to be there? How would the receiver know which ones to discard?
Or does FEZ have some other clever way of handling this? . . . . Maybe a character is never supposed to show up in a deployment file? Or maybe a firmware file is always a fixed multiple of 1,024 bytes, so that padding is never an issue?
[Update] Since .HEX files are basically text files, the byte should never show up. What about .SIG files, which are binary? Are they actually transmitted to the FEZ or are they simply used locally?