Its a small but most essential part of our m2m project. We were looking for a solution for wireless programming solution independent of the transport layer and DualOptiboot does exactly that.
The problem is, Atmega328 just does not have enough RAM. For our application, we needed lots of RAM and atleast two uarts. Atmega1280 did not fit our bill (way too expensive). Our best bet was PIC32 series which has microchip released boot from SD bootloader. But again, SD cards add to BOM significantly with the added space and adapter requirements. Ofcourse we could modify the SD card bootloader to work with external flash, but we realized DualOptiboot does exactly what we want. With some discussion with Felix over mail, this is what we have come up with.
1. The chip used will be Atmega1284 (~4$ against 1.8$ for atmega328). Gives us lots of RAM and additional UART
2. Original Optiboot will be modified, taking cue from DualOptiboot. Aim is to get Atmega1284 compatible DualOptiboot.
3. Work on our application specific transport layer (to transfer image to external flash)
The project is yet to takeoff in full swing, so updates may be fewer initially.
Couple of key issues with current DualOptiboot
1. Application layer is responsible for transferring the file to the flash external flash memory and verify the image. In case there is a bug in the application software, the process may not work as intended and any future wireless updates will not be possible unless the device is reflashed.
2. To encounter issue 1, we intend to have a back up image of minimal required code for wireless programming. There should be a way for the chip to recognize there is a bug and then it should boot from the backup image. Not sure how the first part would work though.
One can very well argue, that application code should be tried and tested before deployment, but errors do happen, and when the device is at some remote location 1000's km from your lab, you cannot afford to brick it.
All suggestions are welcome and appreciated.
Regards