Wireless Programming

electric550

Has anybody had luck programming the prop over wireless. It looks like the XBEE modules have tx rx and dtr for the reset so they could simply swap out for the USB programmer. I was just wondering if lag caused a problems while programming.

jazzed

Lag will cause problems.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Leon

You could interface a small PIC or AVR with external flash memory to the XBEE module and use that to program the Propeller.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/9/2009 1:58:33 AM GMT

localroger

I have tried various serial--RF--serial schemes over the years, never with good results. They lose data, introduce lags, and generally only work when everything is perfect. Plus, you need a scheme that can transmit DTR with the proper timing to reset the Prop and then get the comms going. Parallax have said that a special protocol is used to deal with timing differences that result from the different speedsof RCPROP clocks (the chip can be running at a wide range of speeds, resulting in a similarly wide range of baud rates). I doubt any generic RF to serial conversion scheme could properly deal with that.

Mike Green

Jazzed and localroger have both mentioned the problem involved ... timing.· None of the wireless link techniques can be used for downloading using the built-in protocol.· You could use pretty much anything if you develop your own downloader.· Look at the YBOX2 for one example that downloads over the Internet and could use a WiFi interface to do it.

BradC

I have a method I've been playing with for a while using RFM12B modules, but it's _slow_.

Basically it uses 2 proto boards and runs a pair of cogs on each end. On the PC end one cog pretends to be a bootloader on different pins and receives the program from the Prop Tool storing it in the on-board ram. It then flags the other cog to start sending it to the other end.

The transmission consists of 64 byte packets that are coded using a horrible home-cooked encoding based on differential-manchester with a 16 bit CRC. Each one is sent and acked when it hits the other end. I used the nasty hacks I did as the receiver can auto-sync to the bitrate of the transmitter from 115,200 bps to about 300bps with no accurate clock and no prior knowledge of the inbound rate required. This is so the transmitter and receiver can both be running off RC oscillators and still communicate reliably. The RF cog is self contained, with 64 byte buffer, CRC checking/generation and all RF code built in. This removes the requirement to use HUB ram while communicating.

The Cogs talk to each other using the last long of RAM (as no normal program image is ever going to put something there)

On transmission of the final packet, it signals the other end that things are complete and to load the prop.

The remote end receives the packets and builds a 32K image in its ram. When the image is complete it signals the second cog to reset and load the target propeller.

I have about 2/3 of it working (The PC end and the data transmission) but I've been working on it on and off for 4 months now and never really got around to finishing it off.

The big downside is it's very slow. The upside is it can be done with a prop plug, 2 proto boards and 2 RFM12B modules and is relatively cheap.
The comms is bulletproof as its all packetised and CRC checked.

I can get an effective rate of 115,200 baud if the boards are less than about 30cm apart. That drops to 2400-4800 if they are in the next room and about 1200 if it's out in the garage.
Even at 115,200 it takes a good minute to reliably transfer a full ram image across. I've never benchmarked it at 1200 as it's far quicker to walk out there with my laptop, plug it in and download the image.

I'll finish it off one day, but you can't rush these things.

I've taken to using 6 core 7/0.20 security cable between the prop plug and the target board. If I ground 3 wires and use the other 3 for signalling I can usually get about 20M between the PC and the target. If I need more I use 2x3M USB extenders between the prop plug and the PC.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

Leon

That's basically the same as my suggestion, but costs a lot more.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Chad George

I wrote a serial boot loader some years ago (based primarily of the PropOS work by Mike Green)

Basically, I had a gumstix with WiFi and used socat to forward a TCP port to the gumstix's serial port which was connected to the propeller.
I could then send hex files to the propeller which it would load into RAM or directly onto the EEPROM and reboot.

The bootloader was part of the debug/comm driver cog between the gumstix and propeller.

I never did it with just an XBEE, but it certainly should work, the delay and lag isn't a problem because its using a real UART not chip's magical version that auto-syncs (which was brilliant, but in cases like this a real pain)

Unfortunately, I don't think Chip ever implemented my "auto-save-a-binary-copy-every-time-you-compile" feature, so you have to manually save the binary output... A file watching script can easily initiate the download process after that.

Chad George

I'm currently working on a project that has XBEE's onboard. I'll get it working with them and post it.

As general purpose serial bootloader and com port ... its pretty useful. I think I need to update the interface to be compatible with the Parallax Serial Terminal since that didn't exist back when I wrote it.

It also allows arbitrary manipulation of the propeller's RAM remotely and a some data logging features...nothing close to what you can do with viewport though.

Actually I really like the work hanno did wit h the viewport tool. I've had good success using that over wireless, but I don't think he ever put a bootloader into his protocol.

HollyMinkowski

If this is something that is done rarely then you could do something cheap and maybe just get by.
There is so little data to send maybe you could use an LED as a photodetector and just write your own
bootloader code and transmission protocol and just 'blink' the data over This might work for small
upgrades of a product by users.

There are many possibilities for sending the blinking data using a PC or some dedicated device.

This is a rather silly way to do this but I'm always looking for the cheapest way to do anything and if
your device already has an LED somewhere on its case this might cost nothing at all.

Oldbitcollector (Jeff)

I've hit on a couple ways to do this, but I've been keeping this part
of the project under wraps until after UPEW.

I'll give the hint that it is based on the Remote Compiler project.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages @ Warranty Void.

EricR

I just posted a way to load EEPROM, like F11, using Kermit protocol. First you save a .eeprom file from Prop Tool or BST. Sorry, I did not include F10 like support for RAM loading. This needs a program like Hyperterminal (came with XP) or ZTerm (shareware for Mac) to do the load of an .eeprom file. It is slow, about 1.5 minutes, but can happen while a control loop is doing other things.
See: "Kermit EEPROM Console" in the Protocols section of the Propeller Object Exchange.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric

Unknown

There was an obsolete protocol developed by Steve Punter.· The amount of blocks sent was based on whether the computer encountered an error so the speed of the file transfer would be based on how clear the phone lines were.· I think "GOO" meant "Go" so when the protocol sent that, the file transmission would take place.· There are other protocols like Z modem but it requires faster computers.· Punter is probably a good protocol or Xmodem CRC (has checksums).

What It Looked Like to the User

Not all of the transmission was visible to the user. The most noticeable part of the transmission was the report of status codes like ACK, GOO, BAD, and SYN for handshaking results. A typical transmission might look like ACKGOOGOOGOOGOOBADGOOGOOGOOBADGOO, with bad blocks reported to the user just as frequently as they occurred. This allowed users to record the error rate according to hour and day of the week, and determine which hours of the day, and which days of the week had cleaner phone lines. Unlike modern PC computers, the C-64 and C-128 could poll the User Port (where the modem was interfaced) at slightly different BAUD rates and connection speeds. For instance, a transmission at 1200 BAUD on Sunday evening might actually produce fewer errors than 2400 BAUD on Tuesday afternoon. By choosing slower BAUD rates, files could actually be transmitted faster than at higher BAUD rates, inasmuch as there were fewer re-sends in a given transfer.


http://en.wikipedia.org/wiki/Punter_(protocol)

Unknown

Here is the description for the Punter Protocol:

http://cbmfiles.com/genie/geniefiles/TelcomTools/C1-PROTOCOL-DESCRIPTION

···· John: Put part "A" in hole "D".

···· Ken:· Understood, putting part "A" in hole "D".

···· John: Acknowledged, let me kow when you are ready for the
·········· next instruction.

···· Ken:· Go ahed, what do· do next?

···· John: Put screw "E" through slot "T".

···· Ken:· I didn't undertand that, could you please repeat.

···· John: Oh ok, tell me when you're ready for that instruction
····················· again.