ESP8266 or Arduino OTA to Arduino?

[joelucid]

So could you please share this beta "works great for normal installations" version?

I've put together another preview for executiveul. If anybody else is interested in testing the bootloader let me know. The caveat is there is very little UI. I currently just upload configuration files and images to the esp8266 using curl - just as I like it. But it's fully functional and will deploy any sketch reliably in a couple of seconds without external flash. ISP programmer required for the initial install of the bootloader.

Joe

[perky]

Just as a matter of interest, is any of this OTA bootloader stuff based on avrdude? There's plenty of support for that on linux and Windows PC. You'd need to set a virtual serial link up but there are serial bootloaders out there that could be tweeked relatively easily to do that, even add xmodem support.
Mark.

[joelucid]

Just as a matter of interest, is any of this OTA bootloader stuff based on avrdude?

In my case it isn't. I use a esp8266 as gateway and it talks a custom protocol to the installing node. You use a http post to copy hex files and the config file to the esp8266. Not sure how avrdude would help here.

[Humancell]

I have been looking at this for a while, and I can't understand why this is not possible.

First, I want to outline a few criteria, and then ask a few questions, and propose how this *could* be done.  I too am anxious to complete this and have this work for myself.

My scenario is:

• Sensors built using the Moteino boards, with the flash memory necessary.
• A gateway, with a ESP8266 connected using TTL serial to a "local" Moteino

When I look at the OTA code, it appears that the "PC" or "Python code" is simply sending the .HEX file to a Moteino using a specific protocol format.

• There is an initial "handshake" that must be done (e.g. FLX? / FLX?OK)
• There is a "target set" that indicates the target address for the Moteino to be updated (e.g. TO:{address} / TO:{address}:OK)
• The HEX file is then sent, using a line-by-line record format with sequence numbers (e.g. FLX:{sequence}:10042000FF4FA591B4912FB7F894662321F48C91D6 / FLX:{sequence}:OK)
• There is some retry logic that has to be written, in case the FLX:{sequence}:OK is not received, or out of sequence, or timeout.
• There is a "EOF" handshake that indicates it's done (e.g. FLX?EOF / FLX?OK)

This is a quick - first look - at the code, but it all seems possible to write this protocol to run on the ESP8266.

In my scenario, I would see this working like:

• ESP8266 makes a GET request to a web server, passing the remote Moteino node address and current firmware version (it got this from the remote Moteino)
• The web server will pass back a response indicating if no firmware update is required (some short "NAK" string)
• If the web server finds that an update IS required, it will begin to return an "ACK" header, and then the contents of the HEX file
• The ESP8266 will read from the GET response and look for the "NAK"
• If the response is NOT the "NAK" string, and is the "ACK" header, then there is a firmware update for the remote node
• The ESP8266 will begin the handshake with the remote Moteino, over the TTL serial connected local Moteino
• The ESP8266 will read the HEX file being sent by the web server and update the remote Moteino using the protocol above

I do understand there will be timing issues that have to be looked at, and how to read the incoming file stream from the webserver and push these to the remote Moteino, but I can not see any reason that this could all be done without using a PC at all.

Thoughts?

What are the critical issues that I have missed, or that I am not thinking of?

Good evening everyone. To clarify, here is my ideal situation:

ESP8266 is the Gateway / Hub and talks over MQTT to a broker somewhere in the Ether. The ESP8266 can OTA, upload sketches to motes using RF69 modules without external EEPROM. Using an ESP8266 or variant would reduce the cost of a Gateway significantly by not needing a Linux/Windows system.

[Felix]

The code I released assumes a Moteino "programmer" (which takes the HEX and relays it to your listening "re-programmed" node).
However everything is handled over serial so the GUI doesn't care what your programmer is as long as it follows the protocol.
Not to say this will definitely work because I haven't tried it but I think it should be very similar, you may have to change pin defs etc.
Only the target has to be in RX mode (listen) and have a FLASH MEM chip on it.
One day WP (OTA) will work in true listen mode 

[WhiteHare]

• A gateway, with a ESP8266 connected using TTL serial to a "local" Moteino

There exists a simple interstitial board that will do that part for you.  You can download it free from here:   https://www.openhardware.io/view/273/ESP-LINK-ESP8266-WeMos-D1-Mini-Adapter-Board
and get it fabbed at your favorite fab.
 

The photos show it connected to a pro mini, but it could just as easily be connected to a Moteino.  It then doesn't matter whether what's feeding it in a PC or an ESP8266 or a server or whatever.  The proof of concept was initially done with a PC feeding it over a wireless "virtual" serial link (which is what ESP-LINK provides) using an earlier prototype and msjfb's software here: https://lowpowerlab.com/forum/wireless-programming-(aka-ota)/windows-program-for-wireless-programming/  The combo of D1 Mini and Interstitial board and Moteino simply boils it all down to something that's easier for people to make.

For what it does, it works very well.  You may want to leverage it.

[/list]

[WhiteHare]

In my scenario, I would see this working like:

• ESP8266 makes a GET request to a web server, passing the remote Moteino node address and current firmware version (it got this from the remote Moteino)
• The web server will pass back a response indicating if no firmware update is required (some short "NAK" string)
• If the web server finds that an update IS required, it will begin to return an "ACK" header, and then the contents of the HEX file
• The ESP8266 will read from the GET response and look for the "NAK"
• If the response is NOT the "NAK" string, and is the "ACK" header, then there is a firmware update for the remote node
• The ESP8266 will begin the handshake with the remote Moteino, over the TTL serial connected local Moteino
• The ESP8266 will read the HEX file being sent by the web server and update the remote Moteino using the protocol above

...

Thoughts?

By the way, there is a swiss guy who has put together something similar to what you described (http://iotappstory.com/how-to/get-started).  It's free, and it's cloud based, but it presently just works with ESP8266.  I'm not sure, but maybe it would not be hard to extend it to include Moteino's.

Then, of course, there's Joe Lucid's wireless bootloader, which works great but isn't GUI oriented.  If you're good at making GUI's, I'm sure you'd find a fit there.  In fact, that may be your shortest path.