The next major feature addition will be an XMODEM based EEPROM programmer/dumper. I'm looking at XMODEM code examples and protocols now. Any help would be great.
The next major source change will update all libraries to use a central variable struct that holds the command syntax. This will make it easier to add new values without changing each individual library, and takes a bunch of stuff off the stack. It'll also be possible to recycle the 4000byte command buffer for things like XMODEM.
what is XMODEM?
XMODEM was a primarly a file transfer protocol that ran over RS-232 lines (before Ethernet and T-1 lines became popular/affordable). You typically used it to download files via your serial modem. It's probably a 20-25 year-old protocol. Think of it as FTP over serial -- assuming you even know what FTP is....!
Unless you refused to change, you probably switched to Kermit at some point because it was implemented on many more platforms, well before the time that modems joined the dinosaurs.
Kermit implementations probably started out smaller than what XMODEM was at the time, but also ended-up bloating as people started addding features to do more than just pushing files from point to point.
I actually used to maintain both the XMODEM and Kermit ports when I worked at HP in the 80's. They were both very useful and necessary evils.
So, Ian... why? Wireless error-detecting/correcting wireless programmers? I'm not sure I get it.
I'm thinking of using XMODEM for some basic packet transfer and flow control of binary data between the terminal and the Bus Pirate, it's needed for bulk stuff like programming or dumping EEPROMs. XMODEM seems to be supported by everything, the implementation looks very simple, and it's in the public domain. I think it will be easier to program/dump several thousand bytes from an EEPROM by XMODEMing a .HEX file, than it will be to dump raw data into the terminal and hope for the best.
http://www.menie.org/georges/embedded/xmodem_specs.txt (http://www.menie.org/georges/embedded/xmodem_specs.txt)
After looking at this spec, the only confusion I have is how file level control works. If all packets contain 128 bytes, then how do you do that last 64bytes and signify the end of file? Is there another layer to XMODEM that I'm missing?
There's this LGPL code, but I think I can make it a bit easier, smaller, and in the public domain:
http://www.menie.org/georges/embedded/xmodem.c (http://www.menie.org/georges/embedded/xmodem.c)
Quick update: I abandoned this approach in favor of new binary IO modes that can be scripted from Perl, Pyton, etc. There's a some Perl test scripts here:
http://code.google.com/p/the-bus-pirate ... nk/scripts (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/scripts)
This is much cleaner, let the PC do all the heavy lifting for more complicated file transactions like this.