Bits and Bytes

Programming the Propeller over Wi-Fi?

Rate this Entry
[ATTACH=CONFIG]109199[/ATTACH][SIZE=3][B]A Long Time Coming[/B]

Ever since 1998, we at Parallax have been interested in providing wireless devices for use with our microcontroller products. Over the years, we've experimented with and provided many wireless devices to our customers ranging from simple key fob transmitter/receiver pairs, to high-frequency transceivers.

My experience with some of the early products quickly taught me (well, okay... [I]not quickly[/I] enough) the crazy kinds of problems associated with RF communications. Dynamic things like high-frequency noise, dropout, multipath reception, RF sinks, and antenna issues plagued me almost endlessly. I wasn't then, nor am I now, any kind of RF expert- but I sure gained a lot of knowledge in a short time... the kind that made me realize RF Engineers are some kind of magicians. I didn't want to be one of them, but I wanted to use the products they designed! Not just to turn on a light remotely, but to send real information- lot's of it if I could.

My wish at the time was to program BASIC Stamps wirelessly. How cool would that be back before Y2K?!

I failed miserably.

Everything that was capable would be too expensive. It was a dream.

A few years passed and somewhere around 2003 a new RF product landed at Parallax that could meet the need. I think it was called the Screamer. It was a 900 MHz device that seemed to have enough speed to do the job, and we made a special mode in the BASIC Stamp Editor software to deal with the inherent extra delays. It worked! Pretty reliably too, for the time. I'm not sure why it didn't sell better; maybe it was still too expensive, or bulky, or the demand just wasn't strong enough. Regardless, it became history and we were once again left without a good wireless programming solution- for years.

Fast-forward to the mid-2000s and wireless seemed to be reaching everywhere! (That’s another one of the RF problems, by the way). Everybody was doing it, even without realizing it. And Wi-Fi was maturing at a steady pace and gaining major ground as a prevalent and reliable (and secure?) standard.

We ran into a company that was on the edge of releasing some Wi-Fi chips. Ken and I had significant meetings with them and we were both very excited by the opportunities it could lead to. We decided to make a Wi-Fi module to enable remote programming of our microcontrollers (Propellers and BASIC Stamps). It would have worked too, except that the cards were still stacked against us! Expensive setup, need for RF design, FCC testing and approval, power issues, conceptual issues, and more. Another failure. It was a learning experience.

Now it’s 2014.

While on a quest to devise a solution to program the Propeller via an iPhone/iPad, the first clear barrier was obvious- we needed a wireless interface. The forums were great at helping us visualize all the possibilities (thank you guys!) and we met another great developer with iOS expertise, Mike Westerfield of Byte Works Inc. At the same time, Digi approached us with their second rev of their XBee Wi-Fi product, the S6B. We quickly decided that Wi-Fi was, once again, the way to go and Mike and I set out to experiment with it. Simultaneously, at least two of our other forum members and valued collaborators, David Betz and Steve Densen, started solving problems and demonstrating possibilities. It was very exciting and we love all the efforts!

In Feb, Mike and I struggled for three days and finally got an iOS app built that could program a Propeller. It worked, but there were problems. By March it was more reliable, but still struggled to work in certain network situations.

[/SIZE][CENTER][SIZE=3][B]Here's a video of the first iOS attempt:[/B][/SIZE][/CENTER]

[SIZE=3]I started looking deeper. While David and Steve had finished and proven their solution, and Mike was working on other tasks we gave him, I set about to study the other features of the XBee Wi-Fi and try things in different networks. One of the tasks was to get it running in a PC-type system in anticipation of absorbing the capabilities into various development systems we offer. Two months, a few moments of success, and countless moments of frustration later...

[B]I think I have something![/B]
It's [I]fast[/I] and from the user's perspective works the same way as the standard Propeller programming sequence, except wirelessly!

[CENTER][B]See the demo here:[/B]


I’ve documented the process in much more detail now; it is shared in the [URL=""]Propeller Programming Using the Digi XBee S6B Wi-Fi Module[/URL] document, and in the [URL=""]example code project[/URL].

[B]How Does It Work (in Layman’s Terms)?[/B][LIST][*]The Propeller development board must have a crystal. For now, the typical 5 MHz crystal, but more flexible options will be possible soon.[*]The XBee Wi-Fi is preconfigured to associate with a local wireless access point and is also wired directly to the Propeller’s programming pins.[*]The downloader software finds the XBee Wi-Fi and uses UDP/IP to download a micro boot loader.[*]The micro boot loader then runs in the Propeller (at high-speed) to receive the target Propeller Application image from the downloader software (very quickly, but also accepting of big delays), then launches the target application and wipes itself from existence in the process.[/LIST][ATTACH=CONFIG]109202[/ATTACH][B]How Does It Work (A Little More Detail)?[/B][LIST][*]Wire up an XBee S6B Wi-Fi module to the Propeller’s Rx, Tx, RESn, and Vss pins. Also, connect an I/O pin 4 of the XBee Wi-Fi to it’s own RTS pin.[*]Ensure a 5 MHz crystal is connected to the Propeller.[*]Configure the XBee Wi-Fi to associate with the desired wireless access point.[*]Ensure the Propeller development system is connected to the same access point (recommended) or a network that can reach it (works, but is trickier).[*]Run the downloader software, load the target Propeller Application’s binary image, and transmit it.[*]The downloader software…[/LIST][INDENT][LIST][*]Uses UDP/IP only.[*]Opens an IP socket to the XBee Wi-Fi.[*]Communicates with the XBee’s Application Service, checking and configuring certain critical settings, including setting the Wi-Fi-to-Serial baud rate to 115,200.[*]Transmits a command to generate a reset pulse (100 ms in length).[*]Transmits a command to hold serial transmission (for 200 ms).[*]Transmits a single packet (short of 1,400 bytes in size) containing a compressed timing template, handshake sequence, and a micro boot loader as an executable Spin+PASM image. This is received early, but not transmitted serially to the Propeller until the serial hold condition ends 100 ms after the reset pulse ends.[*]Transmits a full 1,400 byte-sized packet containing timing templates. This, and the above, activates and utilizes the Propeller’s built-in boot loader to receive, program, and execute the micro boot loader contained in the single packet.[*]The micro boot loader now executes in the Propeller (essentially taking the place of the built-in boot loader) to handle the rest of the conversation in a much more delay-tolerant fashion.[*]Waits for a “ready” response from the micro boot loader.[*]Commands the XBee Wi-Fi to switch the Wi-Fi-to-Serial baud rate to nearly 1 MBaud.[*]Transmits all packets of the target Propeller Application using a send, acknowledge, retransmit-as-necessary procedure.[*]Transmits the final command to launch the target application.[*]Closes the IP socket.[/LIST][/INDENT]
Here's some logic analyzer captures of the signals from the XBee + Propeller connections.

[B]Why does it work better than our earlier attempt?[/B]

The most notable reasons are:[LIST][*]It strictly uses UDP/IP, instead of TCP/IP, for communications.[/LIST][INDENT][LIST][*]TCP/IP implementations seem to introduce lots of overhead leading to very indeterminate timing. UDP/IP is much lighter weight, and testing revealed very consistent results with it.[*]The loss of automatic transmission control (the need to watch for out-of-order packets, missing packets, and to negotiate retransmissions) is all handled by the micro boot loader and the download software in a very efficient way.[/LIST][/INDENT][LIST][*]It checks and automatically reconfigures XBee settings, reducing the possibility of user-error creeping in.[*]It uses the XBee Wi-Fi’s self-timed I/O pin pulse options to:[/LIST][INDENT][LIST][*]Generate a consistent 100 ms low reset pulse[*]Generate a consistent 200 ms low serial hold pulse[/LIST][/INDENT][LIST][*]The hardware connection ties our designated “serial hold” I/O pin (output) to the module’s RTS (input) pin. The serial hold pulse, above, entices the module to hold off on transmitting any serial data to the Propeller until just the right time.[*]It sends the most critical packet (the one containing handshake and executable micro boot loader) immediately, priming the XBee Wi-Fi’s serial transmit buffer.[/LIST][INDENT][LIST][*]As long as this gets there within 200 ms, the Propeller will see it 100 ms after reset is released… perfect![/LIST][/INDENT][LIST][*]The miro boot loader is very accepting of large inter-packet delays.[/LIST][B]What’s next?[/B]

I’ve documented the process in much more detail now; it is shared in the [URL=""]Propeller Programming Using the Digi XBee S6B Wi-Fi Module[/URL] document, and in the [URL=""]example code project[/URL].

We’re also revising our development boards that include an XBee socket, starting with the Activity Board, to automatically connect the XBee to the Propeller’s programming pins. This will make it natural and easy for users to choose this wireless programming option… wiring it yourself is the pits; it’s so simple yet there are so many gremlins lurking in the shadows, particularly with how most development boards are configured.

There’s more to do in software too! I’ll be revising and optimizing the working code example here and there. We’ll be updating the iOS app to match the techniques employed here and release it along with the new Activity Board. We’ll also be updating SimpleIDE and Propeller Tool to include this capability naturally.

We look forward to what community members will do with it as well![/SIZE]
Attached Thumbnails Attached Thumbnails Click image for larger version

Name:	20140618_145457.jpg‎
Views:	437
Size:	83.0 KB
ID:	109199   Click image for larger version

Name:	20140618_145632.jpg‎
Views:	218
Size:	88.5 KB
ID:	109202   Click image for larger version

Name:	Download-02-Annotated.jpg‎
Views:	211
Size:	40.7 KB
ID:	109237   Click image for larger version

Name:	Download-01.jpg‎
Views:	206
Size:	39.7 KB
ID:	109235   Click image for larger version

Name:	Download-01-Annotated.jpg‎
Views:	206
Size:	58.8 KB
ID:	109236  

Click image for larger version

Name:	Download-03-Annotated.jpg‎
Views:	212
Size:	52.2 KB
ID:	109238   Click image for larger version

Name:	Download-05-Annotated.jpg‎
Views:	204
Size:	47.4 KB
ID:	109239   Click image for larger version

Name:	PC-Video_Thumbnail .JPG‎
Views:	197
Size:	21.1 KB
ID:	109341   Click image for larger version

Name:	iOS-Video_Thumbnail .JPG‎
Views:	193
Size:	17.9 KB
ID:	109340  

Submit "Programming the Propeller over Wi-Fi?" to Digg Submit "Programming the Propeller over Wi-Fi?" to Submit "Programming the Propeller over Wi-Fi?" to StumbleUpon Submit "Programming the Propeller over Wi-Fi?" to Google

Updated 06-30-2014 at 04:07 PM by Jeff Martin

Propeller , ‎ Programming , ‎ Engineering


  1. Publison's Avatar
    Nice write up Jeff.

    I'm going to check this o tomorrow.