Poll: Who's programming their Moteino wirelessly (OTA)? Who isn't but wants to?

[WhiteHare]

if the radio and SPI code, or a near equivalent, were folded into the bootloader, would the code still be accessible from within the regular application program space?  Or would it require some duplication because of it residing in a protected region of flash?

Sharing is possible.

Well, then, if sharing is possible, I would argue that the radio and SPI code should go in the bootloader, because then OTA Programming could be used as the default, straight out of the box.  Unless you are planning to not load the radio and SPI code at all (in which case, why are you using a Moteino at all?), I don't see how it is that you're "saving" flash space by putting it outside the bootloader.  When you add it all up, wouldn't the total amount of flash that's occupied be the same either way? 

[kobuki]

Well, then, if sharing is possible, I would argue that the radio and SPI code should go in the bootloader, because then OTA Programming could be used as the default, straight out of the box.  Unless you are planning to not load the radio and SPI code at all (in which case, why are you using a Moteino at all?), I don't see how it is that you're "saving" flash space by putting it outside the bootloader.  When you add it all up, wouldn't the total amount of flash that's occupied be the same either way?

Partly this is why I said I don't really like the idea -- the radio and flash/SPI code needs space either way. But add to that the fact that in the available boot loader space you still need to code things on a minimal footprint, and then you don't have the capabilities and features of the full-fledged libs. And you need quirks to access them. If we had like 64 kB or ram or more, this would be a no-brainer and Moteinos should ship with a... hm, well, TripleOptiBoot

[WhiteHare]

Well, then, if sharing is possible, I would argue that the radio and SPI code should go in the bootloader, because then OTA Programming could be used as the default, straight out of the box.  Unless you are planning to not load the radio and SPI code at all (in which case, why are you using a Moteino at all?), I don't see how it is that you're "saving" flash space by putting it outside the bootloader.  When you add it all up, wouldn't the total amount of flash that's occupied be the same either way?

Partly this is why I said I don't really like the idea -- the radio and flash/SPI code needs space either way. But add to that the fact that in the available boot loader space you still need to code things on a minimal footprint, and then you don't have the capabilities and features of the full-fledged libs. And you need quirks to access them. If we had like 64 kB or ram or more, this would be a no-brainer and Moteinos should ship with a... hm, well, TripleOptiBoot

I don't know about footprint requirements, so I don't know enough to evaluate that, but I'm pretty sure you wouldn't have to put the entire radio library into the bootloader, just the part that's needed for the OTA Programming.  So, rather than a monolithic library, you could divide it into two libraries: 1. the bare minimum code needed for OTA Programming and which goes into the bootloader, and 2. all the rest of it, which needn't go into the bootloader, if there are footprint limitations.

How big a bootloader footprint is possible?  Maybe that's the critical question.  If it's 8K, then it should be easy, right?  I mean, the original arduino bootloader was what, 4k?  Now optiboot is 512bytes.  If 4k were the limit (and I don't know that it is), could spi and the essential radio code be fit into 3.5K? 

[kobuki]

I don't know about footprint requirements, so I don't know enough to evaluate that,

How large is your own, non-flash OTA bootloader?

I'm not sure what you're asking.

Wah, sorry, I didn't pay my full attention to the forum I wanted to ask Joe about that, sorry. I deleted my post.

[WhiteHare]

If the entire bootloader needs to reside in the NWWR section, then from Table 26-14 of the 328p datasheet, the maximum size is just 2K. 

[joelucid]

Maximum bootloader size is 4K (that's also the size of mine) but as I've said previously nothing can stop you from calling from the bootloader into normal flash so as long as the jump tables are generated correctly you could add code below the bootloader which it would use.

That said I think the bootloader should really be a fairly static piece of code. I wouldnt want to have much of the regular libraries in it so that they can be updated without changing the bootloader. I think the 4K ota bootloader is a sweet spot that works well in all but the most extreme cases.

[joelucid]

Bottom line: ota updates are hugely attractive. Felix method and the bootloader method both work each with their own pros and cons. In some cases only the bootloader works:

When you don't have space for the flash
When you need special code to enable coin cells
If you have a habit of uploading broken hex files - happens to me all the time.
If you need the option of ota bootloader changes.

We have a potential mechanism for replacing the bootloader. But all the discussion is moot unless there is actually a ota bootloader that's publicly available. Mine works but is tightly coupled with my environment plus I don't yet have the nifty device. So for now we're stuck with a vision of what could be done bootloader wise  - and Felix existing, stable and reliable method.