Downloading programs from the computer to a Propeller via Xbee
MJHanagan
Posts: 189
Is it possible to download SPIN code from the Propeller Tool to a Propeller via an Xbee module? I have a Prop tucked up above my basement ceiling tiles which makes it cumbersome to wire it to my PC to load new code. Being able to download new code from my living room would be quite convenient. I scanned through the Xbee manual available on the Parallax website but didn't see anything that described the downloading of code to the Propeller chip. Any ideas on how or if this can be done?
Comments
-Phil
Apparently Bluetooth is another option for wireless Prop programming.
Ah! That was the application note I read many moons ago. I couldn't remember where I got the idea but that must have been it. Thank you.
I read it over quickly this morning and it seems fairly straight forward. It costs you a cog to have the capability but this same cog also process any Xbee traffic data. For my current setup I have two open cogs and a few unused I/O pins.
Do you know if I can use the "XStick" on the PC as the Xbee transceiver, or do I need to buy an actual Xbee module and the accompanying USB adapter board?
Yes, works perfect wit a Xstick also.
Is it possible to obtain the source of LoadPropXB please ?
I'm getting stuck with xbee_loader.spin object so I may need someone's help please.
I read AN007 about programming a propeller via xbee, I also made a prototype and tried LoadPropXB.exe and everything was running well.
I would like to make my own loader software but for now without xbee's. So I'm using the same prototype but instead of xbee I wired up everything to PC my serial port and I'm sending data directly from my PC towards the prop. Communication with prop is fine but I got stuck by getting the xbee_loader object to respond to "Open, sesame!###" magic string or "Open, sesame!###" followed by "#" and "¥Z"
I was curious what's going on on the serial port during programming via LoadPropXB.exe to find out why my loader is not working? I found out that instead of "Open, sesame!###" , "Ïðåî¬ óåóáíå¡£££" was sent followed by "#" and "¥Z"
Then I did sent the same thing which is basically the same string if you extract 128 from each ASCII value (ex.: "O" = ASCII 79, 79+128 = 207 which is "Ï") however isn't working either way.
I did google a lot and I found some spin codes suppose to do the same thing but still those seems to not work on my bench.
For example one is doing:
ser.str(string("Open, sesame!###")) 'send string to put loader object into command mode
ser.tx("#")
ser.tx($a5)
ser.tx($5a)
this one is sending "Open, sesame!####¥Z"
the other one:
phrase byte "Open, sesame!###",0
repeat i from 0 to strsize(phrase) - 1
ser.tx(byte[@phrase + i]|$80) 'send string to put loader object into command mode
ser.tx("#")
ser.tx($a5)
ser.tx($5a)
this one is sending "Ïðåî¬ óåóáíå¡£££" followed by "#" and "¥Z" exactly like LoadPropXB.exe is doing
So basically each of those are doing more or less the same thing. Absolutely no trick in timing, no trick inside the string but still something should be there. I also went through xbee_loader.spin object but could not find any trick but still there is definitely something I have missed.
Should you need the spin files or the serial port monitor results just let me know.
Many thanks in advance!
I haven't tried to use the XBee loader myself but my uneducated guess is it would work with a wired connection.
Well, it looks like I was not clear enough :-) So, let's try again in more detail.
First of all I made a bench setup with a PC to Xbee - Xbee to Prop
As I wrote earlier communication was perfect, I could download software to prop with the LoadPropXB.exe tool.
Now, I have removed the Xbee's so I'm using only a serial connection to the propeller (9600) to check If i can upload the binary.
A found out quickly that the prop is not listening to the magic string "Open, sesame!###"
Because of this I monitored again the original setup with the Xbee's included, where thighs are working and I found out that the magic string sent never looks like "Open, sesame!###", it is "
I think I understand better what you're trying to do.
My guess is you aren't able to type the magic string into the terminal fast enough to satisfy the "correctly-timed" part of this comment in the loader code:
I think these constants determine the time limits placed on the incoming message.
You could try increasing the numbers to see if having more time to type will allow your plan to work.
I think each increase of 1 unit will double the time limit.
You could try 5 and 2 or 7 and 3. I don't think physically damage anything by making these changes but the code may stop working.
I don't have any guesses why you're getting the strange characters.
Well, I was also trying not to type the magic string and I sent it with a java "outs.write" and also tried it by sending it with X-CTU's terminal (without Xbee) where is possible to build a string and then send it at once, but no luck.
Yep, me too I think it should be something wrong with the timing somewhere. Thanks for pointing this out, I will give a try as soon as I can.
I also will give a try to measure the magic string time while it's being sent with LoadPropXB.exe tool and will compare it with the others, let's see if I can catch it with my scope....
Will turn back soon with the results.
Some programs will end a string with both a carriage return and a newline character. I think the newline character could cause problems (not sure though).
Unfortunately this is not an issue here. All the whitespace characters where monitored with the serial port monitor (see the hex part of my second post)
CR is 0D and LF is 0A but non of those are in the log.
Meanwhile I was trying to modify the values you suggested. Again, no luck :-(
I also measured the "Open, sesame!###" string sent with X-TCU, but had no time to setup the x-bees to check it with LoadPropXB.exe, I will compare it later.
I finally figured out what's going on and I need to say it's tricky.
The loader starts to communicate with the xebees with 8 bit data communication then once the destination has been set by sending ATDH and ATDL will close the command mode with ATCN and the trick comes. it turns to 7 bit (us ascii 7 bit) data and 2 stop bits and will send the magic string and the binary file in this way. So this is the reason why the prop never listened to my terminal application which was set to 8 bit data only.
Does somebody has an idea how to modify xbee_loader.spin to keep listening in 8 bit mode?
I will attach my scope screenshots shortly.