Over the air updates
-
I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib :) Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.
-
I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib :) Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.
-
I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib :) Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.
@Damme said:
I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib :) Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.
If you want to stay with the AVR:
ATMega1284 based: http://lowpowerlab.com/moteino/#whatisitMEGA $20+shipping. This can add a RF69* radio, but you could instead (or also) attach a nRF24L01+
ATMega2560 based: http://www.ebay.com/itm/121391548557 $15 shipped This has even more lines broken out than the Arduino Mega2560. (If you don't mind the larger form, Arduino Mega2560 clones start under $14 shipped).
Or you can switch to an embedded ARM system. Teensy 3.1 for $17+ship. STM32F103 board on eBay for $7. DUE clone on eBay for $18. STM Nucleo from distributors for $11+ship (eMed programmed).
And of course you can use the Raspberry Pi or BeagleBone Black with a faster but power hungry ARM running Linux.
-
I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib :) Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.
@Damme said:
I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib :) Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.
Did you try not using MySensors but the reduced nRF24 driver version I used for the bootloader itself? If the node does not need to do routing and is expected to only respond to one or two types of messages, that might be an option and is definitely smaller...
-
Hi @ToSa
Do you know if your OTA Bootloader uses more flash mem on the atmega328 vs the Optiboot bootloader?
I have a sketch which needs Optiboot to fit and really hoping i can one day use your cool OTA stuff.
Looking at your github it seems MyOtaBootloader.hex is 9.36k whereas Optiboot v5,0a the optiboot_atmega328.hex is 1.418k ( but there is also a optiboot_atmega328.lst file at 19.778k - I dont know enough to know if this is part of the bootloader or if its just the source???)
Cheers,
Greg -
OptiBoot fits in 1/2 KiB (the binary on-chip size, not the hex file).
The OTA Bootloader is obviously larger. If you are using close to 31.5KiB on an ATMega328p, it won't fit with any bootloader larger than OptiBoot.
.
Make sure you use the latest compiler - 1.5.7 seems to squeeze harder (smaller binary), and I presume 1.0.6 (which has also been upgraded to a newer compiler) will also do so.How big does the compiler say your sketch is, at the end of a compile?
-
@Zeph said:
use the latest compiler - 1.5.7 seems to squeeze harder (smaller binary), and I presume 1.0.6 (which has also been upgraded to a newer compiler) will also do so.
How big does the compiler say your sketch is, at the end of a compile?
I'll check when i get home tonight.
Very interesting about the new compiler. I'm pretty sure im using 1.0.5-r2, and i've recently begun using Atmel studio with Visual Micro addon - just soooo much better when dealing with long sketches!!!
Cheers,
Greg -
@Zeph said:
use the latest compiler - 1.5.7 seems to squeeze harder (smaller binary), and I presume 1.0.6 (which has also been upgraded to a newer compiler) will also do so.
How big does the compiler say your sketch is, at the end of a compile?
I'll check when i get home tonight.
Very interesting about the new compiler. I'm pretty sure im using 1.0.5-r2, and i've recently begun using Atmel studio with Visual Micro addon - just soooo much better when dealing with long sketches!!!
Cheers,
Greg@gregl the fuses determine how much space is reserved for the bootloader. I don't have the datasheet at hand but I think it varies from .5k to 4k. Optiboot is one of the smallest out there and the OTA bootloader consumes the full space because it needt to includs the (shrinked) wireless driver.
-
I think the OTA bootloader which does not rely on any extra memory is a great option!
And I think the option of having external flash may work out well too. Sending an image to be written to SPI flash might not expand the application code as much (it already has the library). Then the bootloader just has to copy from SPI to application flash. I'm thinking that might make for a smaller total footprint, since there would be no need to fit 2 nRF libraries in the 32KiB flash - a trimmed down nRF library in the boot section plus the full nRF library in application section.
Of course, if the application gets hosed, you would not be able to do OTA bootloading and would have to physically access the node to recover, but if it's a matter of fitting or not fitting into FLASH, that might be a risk one is willing to take.
-
I think the OTA bootloader which does not rely on any extra memory is a great option!
And I think the option of having external flash may work out well too. Sending an image to be written to SPI flash might not expand the application code as much (it already has the library). Then the bootloader just has to copy from SPI to application flash. I'm thinking that might make for a smaller total footprint, since there would be no need to fit 2 nRF libraries in the 32KiB flash - a trimmed down nRF library in the boot section plus the full nRF library in application section.
Of course, if the application gets hosed, you would not be able to do OTA bootloading and would have to physically access the node to recover, but if it's a matter of fitting or not fitting into FLASH, that might be a risk one is willing to take.
@Zeph said:
Sending an image to be written to SPI flash might not expand the application code as much (it already has the library).
Because I am sure that Flash memory will come in handy sooner or later I have added the Winbond W25X40 to the first version of my board already :).
-
@tekka
That sounds great! Can you post your code (or share a pull request)? This would either allow us to free up the remaining space or to add encryption :)
The only neck-breaker would be if any of the size reduction increases the risk for a bricked node that needs manual intervention (e.g. reset / power cycle etc.). -
what is the current status of the OTA firmware updates? Is external flash necessary at all? Is someone working on it?
Right now I am trying to get DualOptiboot from lowpowerlabs.com to work with my board, and an external flash / eeprom. But was wondering if it would be used at all.
Then when I got the bootloader working, I need to test firmware updates, but the road is still long and windy to get there (at the moment, only have 1 hour here, and there, to work on the hardware)
-
@tbowmo
Did some work on the OTA bootloader: combined optiboot (for uploads via IDE / avrdude) + OTA bootloader with some major modifications. Current version is stable and works for regular OTA updates :)I will post the source once I find some spare time to clean and comment it.
-
I have been thinking about OTA the last couple of days, while trying to get DualOptiboot working (using external SPI flash). If program directly, then the firmware needs to be send in a ordered way by the controler, in order for the bootloader to get things done.. What if a single package is missed?
What if we have 100 nodes, that all needs software update at the same time? Is the system able to handle that?
A part of me says, go with the direct method (that is, skipping external SPI flash) for my minimized module, but then again.. I realy want to have the added "security" of having an external flash, where I can download to, and only when checksums are correct, then I can issue a "Reload software command" to the node.
In theory, I could send the software to 100 nodes, and then when they all are ready, broadcast an "restart node" to all the affected nodes.. (future plans I know..)
Just my thoughts rambling around in my head :)
-
I have been thinking about OTA the last couple of days, while trying to get DualOptiboot working (using external SPI flash). If program directly, then the firmware needs to be send in a ordered way by the controler, in order for the bootloader to get things done.. What if a single package is missed?
What if we have 100 nodes, that all needs software update at the same time? Is the system able to handle that?
A part of me says, go with the direct method (that is, skipping external SPI flash) for my minimized module, but then again.. I realy want to have the added "security" of having an external flash, where I can download to, and only when checksums are correct, then I can issue a "Reload software command" to the node.
In theory, I could send the software to 100 nodes, and then when they all are ready, broadcast an "restart node" to all the affected nodes.. (future plans I know..)
Just my thoughts rambling around in my head :)
Yes, in the current setup, the node requests FW blocks the way they will flashed, i.e. page-wise. If one block is missing, the bootloader will re-request that block several times and reboot after a few unsuccessful attempts. The nRF24L01 has CRC on the payload and auto-retransmission of corrupt payloads (see RFInit; 15x every 150us).
As soon as the OTA update is initiated, the CRC is invalidated and the sensor remains in the bootloader until the update is successful and the CRC is valid.Updating 100 nodes simultaneously: for my understanding, the limitations are if the gateway and/or repeater nodes can handle the traffic and the connection quality). Updating sensors semi-sequentially (e.g. 5 nodes at a time) works from my experience.
Having added "security" with an external flash is certainly a nice feature (and opens other very interesting applications), but is it that important for OTA updating nodes with a down-time of a few minutes? Again, one could instruct the controller to update the nodes in a controlled fashion...
-
Sure for a temperature sensor, downtime of a couple of minutes is not an issue, but there might be other types of nodes that shouldn't have downtime.
What if we bring in the WAF? Let's say the node we want to update is the one that turns on light in the wife's walk in closet, And she is getting ready for a night out with the girlfriends :-) Then "a few" minutes downtime could be fatal to your own health :-)
-
Sure for a temperature sensor, downtime of a couple of minutes is not an issue, but there might be other types of nodes that shouldn't have downtime.
What if we bring in the WAF? Let's say the node we want to update is the one that turns on light in the wife's walk in closet, And she is getting ready for a night out with the girlfriends :-) Then "a few" minutes downtime could be fatal to your own health :-)
