Programming Propeller via Radio
JoeCreate
Posts: 36
Has anyone tried programming the Propeller via a Radio link?· I'm thinking XBee Radio.· I'm tired of making my robot come back to get reprogrammed (although it is well-trained).·
If the XBee can transmit DTR/RTS signals properly, does this sound possible?· I·wasn't sure how the propeller might handle delays during the programming process.· I haven't looked into the details of what happens during the programming process.·
I'm just wondering if it's worth attempting or if due to possible latency it wouldn't be possible.
·
If the XBee can transmit DTR/RTS signals properly, does this sound possible?· I·wasn't sure how the propeller might handle delays during the programming process.· I haven't looked into the details of what happens during the programming process.·
I'm just wondering if it's worth attempting or if due to possible latency it wouldn't be possible.
·
Comments
I would use a C8051F305 (a 10-pin 8051) or similar programmed with a radio protocol and lines from it to the props I2C and reset lines. Sure, all of us would like to do it without an extra micro but it isn't going to happen except on the bench, out in the field it's a different story. If you rolled your own transceiver module then you could probably incorporate the protocol into the transceiver's cpu much like the nordic chips with on-board 8051s.
It may be possible to to use the xbee virtual wire mode to program the eeprom but maybe someone with some xbee experience could comment.
*Peter*
After reset, the serial programming line uses a sequence of pulses whose widths conveys zero and one bit information. These pulses are encoded into bytes so are relatively easy to generate and could be carried over XBee or any other link.
Using an XBee as a drop-in replacement for a serial cable is possible in many applications but probably not in this case.
From my own experience and others who have written downloaders, the Propeller seems to have some timeout in that it will abort programming if the pulses are too far apart. That would likely happen while the XBee were busy building a packet of bytes for transmission.
More problematical, the Propeller Tool doesn't use hardware or software handshaking so it blindly sends its serial data not knowing if the receiver, or in this case the XBee, is actually ready to receive them. I'd expect to see a lot of lost data unless there was buffering for transmission.
A third-party downloader could be tailored to using XBee's for transmission ( and byte data could be sent to improve throughput ) but that would need something at the other end to buffer the Eeprom image and program the Propeller Chip.
I think the answer is that it would be possible, but not as easy as one would hope for.
Graham
One idea is stoping the Propeller, taking i2c control write program in the eeprom then let i2c and restart the Propeller.
That must be not so difficult if i can get the programing protocol ?
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
Post Edited (inservi) : 10/2/2007 11:40:35 AM GMT
http://forums.parallax.com/showthread.php?p=591445
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Sounds easy 'nuf, right?
I was hoping to be able to press F10 on the Propeller Programming Tool and it would be seamless.· But I see that is probably not going to happen without a very reliable flow of data.· The XBee can be set to not buffer bytes into packets before sending them and send byte-by-byte, but it would still be iffy.
I could use an 8051 but it's been a while since I programmed one I don't have development tools or remember it very well·for it to be practical for me.
I Like PIC's (for some things).· The PIC could be a serial link between the XBee and the EEPROM's i2c bus directly.· The PIC could buffer, verify, and write to the EEPROM, then perform a hardware reset on the Prop.
I'm thinking it would not be safe to receive the·file using the Prop (or anything) and write directly to the main 32k EEPROM until it is all verified.· One bad byte and I'd have to bring the bot back on a stretcher.
Post Edited (JoeCreate) : 10/2/2007 2:24:40 PM GMT
I think if I were to try to do this, I would buffer the EEPROM image at the receiving end and then flash the EEPROM, possibly after error checking. Basically what T.D.S. suggested. The only thing that makes it difficult is that you need the entire Prop RAM to buffer the EEPROM image. What do you fall back on if the transmission is bad or aborted?
[noparse][[/noparse]edit] ...on second thought...I suppose you could just reboot if that happens. As long as your application can do that..[noparse][[/noparse]/edit]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Post Edited (Ken Peterson) : 10/3/2007 2:56:22 AM GMT
"2.1.4. Transparent Operation
RF modules that contain the following firmware versions will support Transparent Mode: 1.0xx (coordinator) and 1.2xx (router/end device).
When operating in Transparent Mode, the modules act as a serial line replacement."
What I like about putting these transceivers into the usb cord is the hypothesis that you could let usb handle the misses/wrong data on its own. Eventually, I suspect the system would settle down to a simple bit in bit out state, where the transceivers gab in their protocol and the usb handle theirs.
Post Edited (Fred Hawkins) : 10/3/2007 5:12:39 AM GMT
As long as you're willing to not download directly from the Propeller Tool, but save an EEPROM image and transfer that via XBee, it would be straightforward to use something like XModem or YModem protocol file transfers. The XBee actually does the error checking, so any kind of block oriented transfer protocol would work. You'd need a program on the Propeller end and a terminal program on the PC end that supports the file transfer protocol. I think someone wrote a receiving program for XModem for transferring bitmaps for graphics. You might be able to find it here on the forum. You could write to the EEPROM a piece at a time since there's a lot of error checking going on. The only problem would be if the link failed completely during the download. If you used a Protoboard with the extra 32K, you could keep an "operating system" in the first 32K that would checksum the 2nd 32K and automatically load it into RAM and execute it if the checksum was ok.
One thing I was wondering about (and hedging) is the transfer speed of the usb port when the propeller gets programmed. Just how fast is that? These two radio chips seem like they can easily keep up with the data speed demands, but frankly I'm guessing. Personally they both look interesting enough to add to my toy collection on their own...