Seems like the ArduinoOTA works with arduino boards (doh) already (well, with the avr based ones only, I believe). Anyway, neither of them have any external storage. How do they do it?
OTA update alternative
- Thread starter someteen
- Start date
- Status
Seems like the ArduinoOTA works with arduino boards (doh) already (well, with the avr based ones only, I believe). Anyway, neither of them have any external storage. How do they do it?
defragster
Senior Member+
ESP-8266 can do it as it has built in WiFi - but that isn't generic UNO or AVR.
It takes a specially located set of code on AVR to write FLASH as well - in the onchip bootloader: hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/
It seems that can do block level erase and write AVR - something the ARM MCU's don't support with full erase required before programming.
I see, looks like a hardware (ARM) limitation.. now it finally makes sense.
In the mean time, I've did a quick research on this two OTA enabled boards: WiPy and Particle Photon.
Does anyone have any experience with them, to help me choose the better/more reliable one? Like I've said, I'm in a hurry and one of these boards could save a lot of time for now. Thanks in advance for any suggestion.
In the mean time, I've did a quick research on this two OTA enabled boards: WiPy and Particle Photon.
Does anyone have any experience with them, to help me choose the better/more reliable one? Like I've said, I'm in a hurry and one of these boards could save a lot of time for now. Thanks in advance for any suggestion.
potatotron
Well-known member
I haven't worked with the WiPy but I've done several projects with the Photon. It's acceptable. The firmware used to fall off the cloud fairly regularly (the MCU kept running its code, but you couldn't reflash it or access published variables) and it still does that once in a while but it's much better than it used to be. I'm not a huge fan of the idea that the company could go out of business any day and I'd be stuck with an abandoned product but so far so good.
I don't think I'd use the Photon in any large-scale project (cloud access fees + aforementioned risk of company going out of business) but for one-offs that require Internet access and/or remote upgradability I'm happy with it.
defragster
Senior Member+
The noted ESP-8266 is an Arduino supported device with OTA update built in to the IDE. I've made it work wired to a Teensy. That let me use the Teensy as the Serial programmer to get the OTA code loaded if nothing else. You can use the base Arduino samples or other - I found what seemed like a nice myWebServer library noted on that github that worked - have to enable a DEBUG in library to get OTA enabled as there is no password required - though it is supported now I think. Just came across another that is different but has MQTT support built in - but don't know about OTA with that.
I backed a KS for OAK that is just an ESP_8266 based board that teamed up with PHOTON to share their code - that support is still coming online. The OAK also supports BLYNK for WEB UI - haven't worked with that either. You can get an OAK for less than a Photon and just push on the Arduino RAW IDE core and IIRC the silkscreen on the other side of the OAK PCB labels the Arduino interface pins #'s - that should get you up and running on Arduino with OTA WiFi and an onboard power supply and support circuitry not found on a RAW ESP - unless you piggyback it to a Teensy like I did.
I backed a KS for OAK that is just an ESP_8266 based board that teamed up with PHOTON to share their code - that support is still coming online. The OAK also supports BLYNK for WEB UI - haven't worked with that either. You can get an OAK for less than a Photon and just push on the Arduino RAW IDE core and IIRC the silkscreen on the other side of the OAK PCB labels the Arduino interface pins #'s - that should get you up and running on Arduino with OTA WiFi and an onboard power supply and support circuitry not found on a RAW ESP - unless you piggyback it to a Teensy like I did.
@potatotron:
Many thanks for your Photon recomandation. I'm not a big fan of cloud IDE neither but, as they have noted on the product documentation page, you still can compile and upload your sketch locally (using dfu-utils) hence chances are your Photon may live after their cloud are out of business.
@defragster:
OAK looks promising but is just as featureless as any other current ESP8266 single board implementation (only few GPIO pins available, only one ADC input and so on).
By using Teensy for awhile, I'm accustomized with having lots of features (thanks Paul) to accomodate with any small-medium scale project. Beside, I only found available the two aforementioned boards (Photon and WiPy) thus I have to make a choice for one or another.
Once again, I'm talking about a little educational project (an introduction to the embedded/IoT concepts for my son) hence he needs an easy access to an IDE and a simple uploading procedure (+1 Photon).
He already have some past experience with lua/python scripting for Minecraft hence the WiPy board (micro python) could be an attractive option, too.
I may end up buying both boards as I can't afford to ruin his Christmas holiday with a wrong choice.
Many thanks for your Photon recomandation. I'm not a big fan of cloud IDE neither but, as they have noted on the product documentation page, you still can compile and upload your sketch locally (using dfu-utils) hence chances are your Photon may live after their cloud are out of business.
@defragster:
OAK looks promising but is just as featureless as any other current ESP8266 single board implementation (only few GPIO pins available, only one ADC input and so on).
By using Teensy for awhile, I'm accustomized with having lots of features (thanks Paul) to accomodate with any small-medium scale project. Beside, I only found available the two aforementioned boards (Photon and WiPy) thus I have to make a choice for one or another.
Once again, I'm talking about a little educational project (an introduction to the embedded/IoT concepts for my son) hence he needs an easy access to an IDE and a simple uploading procedure (+1 Photon).
He already have some past experience with lua/python scripting for Minecraft hence the WiPy board (micro python) could be an attractive option, too.
I may end up buying both boards as I can't afford to ruin his Christmas holiday with a wrong choice.
potatotron
Well-known member
I've used dfu-utils and can confirm you can definitely reprogram a Photon without the cloud via the USB connection. I've also confirmed you can skip their cloud publishing via SYSTEM_MODE(SEMI_AUTOMATIC) or SYSTEM_THREAD(ENABLED) + a local web server to do user interface etc. No problem at all with that, and I can fairly strongly recommend a Photon if that's what you need to do.
My concern with the Photon is if I had to put something "mission critical" out there that depends on OTA upgrades you're trapped by their ecosystem. If something happens to Particle (or there's an Amazon Web Service outage) you're dead in the water. Having said that, I have 4 Photons around the house doing various IoTish tasks and so far so good.
Thanks again, I've just placed an order for the Photon board. Just to clarify a thing: if the cloud connection is unstable (during downloading the sketch to your device), there is a risk of bricking or malfunctioning or it preserves the old firmare? Does it have a telnet server for manual remote commands?
GremlinWrangler
Well-known member
Another random contender for this sort of thing is the onion Omega, but suspect the python based boards will give you better hardware control and better probability of shipping before 25th.
Re bricking along with the just 'power falls-everything dies' problems designing for OTA gives a whole bunch of trade offs around enabling or blocking the user to set things like power saving modes that can never wake or clock speeds that block the OTA interface. You can OTA commercial devices by knowing the traps and testing for them before release but allowing arbitrary code to be run on hardware you take money for means you need a robust process and or rig your downloader to block code that touches those things, such as the Teensyduino process preventing people setting the write blocking bits and some others.
To make a truly robust hobby device I think you have to have two CPUs with a shared flash space where only one gets to execute user code, the other (RF capable one) is fixed and only exposes a limited interface to the main CPU.
Re bricking along with the just 'power falls-everything dies' problems designing for OTA gives a whole bunch of trade offs around enabling or blocking the user to set things like power saving modes that can never wake or clock speeds that block the OTA interface. You can OTA commercial devices by knowing the traps and testing for them before release but allowing arbitrary code to be run on hardware you take money for means you need a robust process and or rig your downloader to block code that touches those things, such as the Teensyduino process preventing people setting the write blocking bits and some others.
To make a truly robust hobby device I think you have to have two CPUs with a shared flash space where only one gets to execute user code, the other (RF capable one) is fixed and only exposes a limited interface to the main CPU.
Thanks for your good advices. The Photon board (packed with lots of sensors) will ship tomorrow thus the Christmas is already saved.
Speaking of that, I always thought that a dual boot (holding both the old and the new firmare) could be a fail proof solution. It only needs a double flash size then the bootloader will make a decision of what firmware to load based on a flag. If the new firmware uploading was successful (based on CRC verification or something), it will write the flag to load that firmware after the next reboot.
Is such a procedure (or a better one) already available for a commercial board?
Speaking of that, I always thought that a dual boot (holding both the old and the new firmare) could be a fail proof solution. It only needs a double flash size then the bootloader will make a decision of what firmware to load based on a flag. If the new firmware uploading was successful (based on CRC verification or something), it will write the flag to load that firmware after the next reboot.
Is such a procedure (or a better one) already available for a commercial board?
GremlinWrangler
Well-known member
I think the ESPs often use up to 8 banks. Critical part is first making sure that your bank switching undo process works even if the in use bank has contents that hard fault straight up (easy fix is a delay on user code to allow load of fixed code, but that delay is then always there unless you complicate things) and second to make sure user code can't get into the other banks and trash them during an array overflow or something. IC design also starts to matter since if any critical to OTA settings persist through a reset by design (AVR fuses) you really can't let the end user tamper there, potentially locking out useful features. So example I met was setting power saving on a Uno that I think disabled the clock such that even a reset wouldn't allow the bootloader to run long enough to achieve anything. What you were supposed to do was set a pin interupt before doing this to wake it up again but I'd missed that step. Thankfully ICSP saved the day with that one.
All solvable problems but not aware of anything that has yet got the magic combo of cheap, pleasant to use, powerful and reliable.
All solvable problems but not aware of anything that has yet got the magic combo of cheap, pleasant to use, powerful and reliable.
Epyon
Well-known member
From another thread: the open source Printrhub contains a (documented) way to wirelessly load new firmware on a MK20.
potatotron
Well-known member
AFAIK no risk of bricking the device; you don't overwrite the firmware boot code in an OTA reprogram. If the cloud has problems you just lose the ability to reprogram wirelessly.
They periodically publish system firmware upgrades and I did manage to semi-brick a Photon early on by interrupting it in the middle of a system upgrade, but the aforementioned dfu-utils brought it back.
[edit - answering 2nd question]
No telnet etc. server is built in but it's easy to add one to your own code. Built in access is via the Particle cloud interface (web page or command line tools you can install) which tell you if the device is online, contents of published variables, etc.
Last edited:
@Epyon:
I guess the key for OTA updating of the MK20 is the availability of an external storage (a SD card, for the aforementioned github project). Or, the key might be the Teensy's bootloader (which is missing in that project).
@potatotron:
I've read some more documentation about Photon (and particle.io cloud for that matter) and I find it a very interesting concept. I'm going to set up a local web server for offline development but the whole cloud environment (including the ability to publish events on google drive) it's quite impressive.
I'd like to further discuss about it but I'm afraid we can't do it right here (this is Teensy realm after all). Maybe we can talk about it on particle.io forum or something?
I guess the key for OTA updating of the MK20 is the availability of an external storage (a SD card, for the aforementioned github project). Or, the key might be the Teensy's bootloader (which is missing in that project).
@potatotron:
I've read some more documentation about Photon (and particle.io cloud for that matter) and I find it a very interesting concept. I'm going to set up a local web server for offline development but the whole cloud environment (including the ability to publish events on google drive) it's quite impressive.
I'd like to further discuss about it but I'm afraid we can't do it right here (this is Teensy realm after all). Maybe we can talk about it on particle.io forum or something?
potatotron
Well-known member
Sure, I'm potatotron over there as well.
Epyon
Well-known member
It's always about the availability of a buffer to store the hex file. Don't know why you keep focusing on the bootloader. The bootloader is just a handy tool to flash a hex file onto the MK20, saves you from having to use SWD or a programming tool.
@Epyon: Thanks for posting that. In fact, I am the author of the Printrbot Printrhub that combines a Teensy with a ESP-8266 to implement OTA updates of the Teensy (and ESP) firmware. If you have a look at our design, you only need to get the hardware right (we also provided PCB layout and schematics) and use our software stack for the updates. That is in fact quite simple. ESP-8266 downloads the new firmware binary from the web and uses a software implementation of an ARM flasher to flash the binary to the MK20. You don't need Paul's bootloader chip. In fact you cannot combine our implementation with the Teensy bootloader chip. This slows development times down, so we had revision one with Teensy bootloader chip to get that fast and nice Teensy workflow. In final revisions we removed the bootloading chip and connected MK20 to ESP-8266 instead.
We have also implemented a software called CommStack (http://www.appfruits.com/2016/11/printrbot-simple-2016-commstack-explained/) which handles all the hard communication work between ESP-8266. If you want to download a URL in your Teensy firmware, you just tell ESP-8266 the URL and ESP-8266 handles everything and sends the file piece by piece to Teensy. CommStack is reliable as it has fall back, error correction and all that stuff that makes your life easier.
If you don't want to reinvent the wheel twice have a look at what we have done before and that is already running in production! And, if you want to add a nice LCD with UI software stack, that is available, too!
http://www.appfruits.com/printrhub/
Cheers,
Phillip
We have also implemented a software called CommStack (http://www.appfruits.com/2016/11/printrbot-simple-2016-commstack-explained/) which handles all the hard communication work between ESP-8266. If you want to download a URL in your Teensy firmware, you just tell ESP-8266 the URL and ESP-8266 handles everything and sends the file piece by piece to Teensy. CommStack is reliable as it has fall back, error correction and all that stuff that makes your life easier.
If you don't want to reinvent the wheel twice have a look at what we have done before and that is already running in production! And, if you want to add a nice LCD with UI software stack, that is available, too!
http://www.appfruits.com/printrhub/
Cheers,
Phillip
Epyon
Well-known member
No idea if Teensyduino would run on what they call 'Mainline Linux' (seems to be Debian, so should work?), but if so this $16 CHIP PRO board seems to be the ultimate Teensy companion. Comparable footprint, maker friendly, USB host functionality, integrated Wifi and BT, preconfigured tools that gives you remote access anywhere and same price range.
I could easily see myself build some stuff using a Teensy to do the critical operations and one of these to provide connectivity, a nice webmin and OTA Teensy update ability.
I could easily see myself build some stuff using a Teensy to do the critical operations and one of these to provide connectivity, a nice webmin and OTA Teensy update ability.
MichaelMeissner
Senior Member+
Yes, but the Teensy doesn't do boot loading via the serial port like the Arduino Uno did. I would suspect that device only works on AVR 328p's, and not even AVR 32u4's (Leonardo, Feather 32u4) or the Mega.
If you want to upload hex files to a teensy via a serial port, the "flasher" code here works well.
https://github.com/Photosynq/PhotosynQ-Firmware/tree/master/multispeq1
https://github.com/Photosynq/PhotosynQ-Firmware/tree/master/multispeq1
One of the gurus might have a better response for if that is possible.
My thought is to develop a very small program that checks at the beginning of every boot for a valid update file from the uSD, if none is detected then it jumps to the main programs starting address in memory.
Essentially having two programs.. first one never gets overwritten.. it does all the erasing and flashing for updates.. and second one is your main code that gets updated.
Having it setup like that ensures the chip can reprogram incase of power loss ect as it will revert back to the first application which should remain untouched.
Kinda like having your own bootloader I guess.
defragster
Senior Member+
IIRC Teensy mcu does full flash erase to program. Thus the external program chip. To program via code works iff running from ram.
Last edited:
- Status