Upload Prop programs via XBee
Phil Pilgrim (PhiPi)
Posts: 23,514
It's been my goal for awhile to be able to upload programs to the Propeller via an XBee module. I finally got a chance to work out the details. Attached is the result.
The XBee module makes this task difficult, since the sending XBee can't directly stimulate handshaking pins on the receiving XBee, nor can it send a BREAK character or alter the receiving XBee's baud rate. So you're pretty much left with monitoring and interpreting character streams in order to trigger the bootload process.This carries a slight cost, since it's no longer possible to send just anything to the XBee without some special formatting considerations.
In order to pull this off with a minimum of special formatting, I decided to use the data link escape character (DLE = $10) as the trigger for commands to the XBee driver. Any time the XBee driver receives a DLE, it's hairs stand on end, ready for something special. If it receives a second DLE in sequence, it just queues both of them and stands down. This is the singular fly in the ointment. Any PC host program sending a $10 byte to the Prop as data has to send it twice for it to be recognized as such.
Otherwise, a DLE can trigger two built-in functions:
1. A DLE followed by an ATTN (DC1 = $11) and an ID byte tells the driver to accept further data if and only if the other byte matches the driver's unit ID ("A" to "Z", as presently configured). This permits simple master/slave networking using the XBee's transparent I/O mode.
2. A DLE followed by a SYSREQ (DC2 = $12), an ID byte, and ### forces the driver to enter monitor mode, where program uploads are handled. In this mode, a two-second period of inactivity forces a chip reset, in order to avoid a hang situation due to bad or incomplete communication from the host.
I've included the entire bootloader within the XBee serial receiver, so no funny games would have to be played with overlaying user EEPROM code with a resident bootloader. As long as the user program starts the XBee object for serial I/O, the boot loader will be ready to jump in when necessary. When monitor mode is entered, all cogs except the one hosting the XBee receive driver are stopped immediately. From there, special monitor commands (such as "upload to RAM") can be accepted and interpreted.
Included in the attached zip are the xbee.spin object and a PC-resident loader, LoadXB.exe. Give them a try. Feedback is welcome!
-Phil
Edit: 'Forgot to mention: the xbee.spin file is formatted for self-documenting via my documenter at:
Addendum: In this post, I've added a new version of this program that uses a completely different (and simpler) addressing scheme. Check it out!
The XBee module makes this task difficult, since the sending XBee can't directly stimulate handshaking pins on the receiving XBee, nor can it send a BREAK character or alter the receiving XBee's baud rate. So you're pretty much left with monitoring and interpreting character streams in order to trigger the bootload process.This carries a slight cost, since it's no longer possible to send just anything to the XBee without some special formatting considerations.
In order to pull this off with a minimum of special formatting, I decided to use the data link escape character (DLE = $10) as the trigger for commands to the XBee driver. Any time the XBee driver receives a DLE, it's hairs stand on end, ready for something special. If it receives a second DLE in sequence, it just queues both of them and stands down. This is the singular fly in the ointment. Any PC host program sending a $10 byte to the Prop as data has to send it twice for it to be recognized as such.
Otherwise, a DLE can trigger two built-in functions:
1. A DLE followed by an ATTN (DC1 = $11) and an ID byte tells the driver to accept further data if and only if the other byte matches the driver's unit ID ("A" to "Z", as presently configured). This permits simple master/slave networking using the XBee's transparent I/O mode.
2. A DLE followed by a SYSREQ (DC2 = $12), an ID byte, and ### forces the driver to enter monitor mode, where program uploads are handled. In this mode, a two-second period of inactivity forces a chip reset, in order to avoid a hang situation due to bad or incomplete communication from the host.
I've included the entire bootloader within the XBee serial receiver, so no funny games would have to be played with overlaying user EEPROM code with a resident bootloader. As long as the user program starts the XBee object for serial I/O, the boot loader will be ready to jump in when necessary. When monitor mode is entered, all cogs except the one hosting the XBee receive driver are stopped immediately. From there, special monitor commands (such as "upload to RAM") can be accepted and interpreted.
Included in the attached zip are the xbee.spin object and a PC-resident loader, LoadXB.exe. Give them a try. Feedback is welcome!
-Phil
Edit: 'Forgot to mention: the xbee.spin file is formatted for self-documenting via my documenter at:
Addendum: In this post, I've added a new version of this program that uses a completely different (and simpler) addressing scheme. Check it out!
Comments
John Abshier
I want to effectively do the same thing using the SI/SO (P31/P30) pins directly connected to a USB connector to the PC using one of the prop USB drivers. This would remove the requirement for a propplug. No time at present, but everything you do here should also work using the prop USB driver. All my new pcbs will have a mini-USB-AB (or connector for both 5V power and optional 47R/47K resistors to the D+ & D- pins. (I have discussed this previously). Now this will be another step closer
This thread should be added to the Propeller / Hydra: Key Thread Index Sticky. Will you be adding the Spin and exe files to OBEX? I'm sure this addition will get a lot of mileage out of it.
-Phil
The loader program uses the PC-connected XBee to scan for and locate remote XBees, any one of which can be selected for uploading. As a consequence, all communication is transparent, without the necessity of including DLEs with special command codes, thus greatly simplifying data I/O.
Due to its comparative simplicity, this will likely become the supported version of the XBee object and loader. I do want to work on the loader some more, however, to provide the option of forcing inclusion of the XBee object when it's not included in the Spin source. This will ensure that all uploaded programs are capable of fostering further uploads.
Anyway, those of you who have XBees, give it a try. Feedback, as always, is welcome!
-Phil
Looking forward to trying the ‘remote programming’ of the propeller.
Thanks Phil!
The new version works great!
Steve
-Phil
When i try to load a .spin file with the loadpropXB.exe, it asks me for the location of the propellant.exe file. i thought i had it at once but it cant find it. im using prop tool v1.2.7r2
Nevermind, found it in propbasic, still playing with it.
Thank you very much for posting this!!!
I am new here and am interested if anything new is happening with this project? I was going to buy the new USB wireless HUB from Parallax but called them and it will not work with Windows 7 64 bit. So I talked to Kevin at Parallax and he send me some files and info on this XBee project. I spent time on reading documentation and tried to load test program (xbee_loader_test.spin), but the process failed with the message from Xbee loader V1.0, "No response from Propeller, or upload failed".
The Xbee is setup with default factory settings.
I can do a loop back test on remote Xbee OK.
Xbee Loader finds a unit ID.
Test button works OK.
Load RAM and ROM button displays the "No response..." message.
Propeller XBEE Loader V1.0 used.
XBee_loader.spin V1.0
I think that about covers it. I will try again later.
Thanks Frank
Then, ran XBee Loader and it loaded the test program and ran it which blinked the LED.
So, I will continue along and test my Robot program without cables and test.
As I keep gathering some info around over the air (OTA) multi node re-programming scenario I came up with the following question...
Is your program capable of hopping between say 2 or more xbee modules and delivering a packet to that n-th node over the mesh network and finally to re-program that particular Prop?
Thanks,
John
p.s. I am not xbee or Prop user (not yet) so forgive me my ignorance
-Phil
-John
http://www.ladyada.net/make/xbee/arduino.html
Thanks for the very fine link and your amazing wulfden.org. You (plus PhiPhi and Tracy Allen of course) certainly got my interest renewed in XBee for my next wireless project around.
-Phil
-Phil
*edit*
Could you elaborate a bit more about why this method wouldn't work with a mesh network? I have a feeling it has more to do with the EXE than the bootloader, but I could be wrong.