Wireless programming update

The initial code commit for wireless programming was a little sluggish and the performance wasn’t very good. I had to add delays to make sure everything was synch-ed and the protocol was working. The result was a rather slow wireless upload of a new sketch, especially if it was a large sketch. But it worked…

Today I worked on improving the protocol and was able to cut down the over-the-air upload time by a factor of ~5. The gains are mostly from improved serial communication. This will still take about twice as long as normal sketch uploads by means of an FTDI adapter. For instance, a 9,8Kbyte sketch takes me about 11 seconds to upload directly to a Moteino using an FTDI cable; wirelessly programming that same sketch takes about 22 seconds. Not bad given how involved the whole handshaking protocol works. And much better than almost 1 minute with the old code. So I’m classifying this new release as a beta. More improvements or bug fixes might be added later, but it’s definitely a functional release. I’ve uploaded different sketches of around 10KB several times without a glitch.

The wireless sketches examples (gateway and node) and the python script are in their github repo. The SPIFlash library was also updated (the WirelessHEX part of it), so get latest before you try this.

As mentioned before, the target node of the wireless programming protocol will need to have an SPI Flash chip attached (if they don’t have one already), and also run the DualOptiboot bootloader for this to work. Moteinos come with this bootloader (all orders since the other Wireless Programming post and code was released). If you have all these components right, any Arduino clone with an RFM12B transceiver and an SPI Flash chip of at least 32Kbytes of memory will do the job.

Just for fun, here’s how the end of a wireless upload looks like, notice there were 617 packets sent all the way from the PC (through the python script) to the attached Moteino (gateway), wirelessly to the remote Moteino (target node):


Moteino wireless programming source code

I managed to put together a library and refactor the code that I used to achieve Moteino wireless programming.

There’s a new WirelessHEX file in the SPIFlash library. There are new WirelessHEX classes for RFM12B and RFM69W/HW transceivers. These files contain helper code that handles the new sketch over-the-air transmission for both the transmitting and receiving ends. It will increase your sketch size by a few KB, that is just an unavoidable tradeoff.

The target node that is to be wirelessly reprogrammed will need to have code to listen for a potential new sketch. I uploaded the example sketch along with everything else to the RFM12B library examples.

The gateway node sketch, target node sketch, python script that passes the HEX file to gateway node are all located here: 


The custom DualOptiboot bootloader allowing the reflashing with the sketch stored on the external SPI FLASH memory chip is here: https://github.com/LowPowerLab/DualOptiboot
I managed to keep the size just under 1k. So in the future Moteinos will probably ship All Moteinos (R2 and R3) are now shipping with this bootloader to allow for potential wireless reprogramming if you also have the FLASH chip onboard the target mote.

I would call this an alpha release even though it works pretty well. Sometimes it’s a hit or miss because of the delays I’ve set in python. Those could be refactored and code improved to be smarter about initial requests for a sketch transmission. But it seems in most cases it works the first try.

Further improvements are:

  • increase speed of transmission
  • test with larger sketches
  • refactor python script, WirelessHEX library and gateway/target node sketches

I’ll try to keep up with changes and updates. Right now I have no idea if anyone will find this useful or not.

Wireless programming step 2: SUCCESS!

It works! I was able to reprogram a remote Moteino over the air with a blinky sketch!

Definitely not a ground breaking achievement, but it really felt like “Hello World” all over again! 🙂

I didn’t expect to overcome this so soon but I managed to get past what I thought would be the biggest hurdle: customizing Optiboot for wireless programming. Actually it’s just reading the new flash image from the external flash chip and transferring it into the internal flash memory. The “wireless” part happens in Step 1. Continue reading

Wireless programming step 1: SUCCESS!

UPDATE: See Step 2 for actual results.

Well, the title may sound somewhat misleading. But read on. After many days/hours of trial and error I was finally able to validate and transmit an intel HEX flash image to a remote Moteino, which stores it on an external SPI flash chip (soldered to the new SPI Flash footprint available on all Moteino R2s). This is the first step towards wireless programming, and probably the easier step.


I really hate to write bits and pieces of an unfinished solution and keep the readers in suspense/anticipation of what’s coming next (I see there’s a trend for this on some blogs, to increase blog hits and keep users “hooked”), but I think the wireless programming endeavor is rather long and complicated. Yesterday I achieved what I long wanted, to get a new sketch wirelessly transmitted and stored on a remote Moteino, for later interception and reprogramming through a custom bootloader.

For those unfamiliar with a HEX file, it’s the file generated by your Arduino sketch, and then uploaded to your Arduino/Moteino when you click “Upload”. It all happens behind the scenes and through the attached FTDI adapter. It’s a complex protocol that involves a handful of moving parts. The most important is the bootloader which lives on your Arduino/Moteino, which must be able to intercept the “Hey here’s a new program for you!” request and start re-programming the internal flash memory. But for all this you need wires!

Wireless programming of your Arduino/Moteino is useful when you have nodes sitting in trees, on top of your house, in your attic, underwater, underground, inside sealed enclosures, generally where it’s very hard to physically reach once you have a node deployed.

Continue reading