Re: [avr-gcc-list] Overlays

[Geoffrey Wossum]

On Thursday 25 December 2003 07:15 pm, Ron Kreymborg wrote:

Hi Ryan,

> With Atmel introducing in situ re-programming as a standard part of the
> architecture, the capability to use overlays for low duty cycle function
> sets (say a few thousand times during the product life) from an off-chip
> spi eeprom looks very attractive.

Since Atmel officially only guarantees 1,000 R/W cycles of the program flash 
(at least the last time I checked), a few thousand cycles might be pushing 
your luck.  I don't have the ATmega product line memorized, but would going 
to a bigger part be an option?  I know a larger part might mean a larger 
footprint and higher price, but you're wanting to strap on an SPI E2, and do 
a lot of tricky programming... 

Another option you might consider is to write a tiny byte code interpreter, 
and run bytecode out of an SPI E2, similar to the Basic Stamp.  Much slower, 
but no reprogramming of the ATmega involved.  However, performance sensitive 
code would still have to run native, so you might not save that much space on 
your uC.

To more directly answer your question, I have thought about something similar 
to this before, but for doing field upgrades of my wireless network stack.  

> I can see one way it could be done using a named region in flash and a
> dispatch table in the BLS for all overlays that included whether they were
> present, their entry address, size, recent usage pattern, off-chip
> location/details, etc. The memory region would be maintained similar to a
> MRU list. If a function was called and found to be not present, the region
> would be examined for available space and, if available, the function
> swapped in and called via the new location vector. If not enough space the
> MRU list would be examined for a likely candidate based on size and usage
> and existing functions discarded until enough contiguous space is
> available.

That sounds complicated!!!  And not good for performance sensitive code, if 
you're dynamically keeping usage data, and possibly having to swap them in 
and out.  I bet you could write a simple byte code interpreter for the same 
code space that would take!  For your application, I think you statically 
know what needs to get swapped out and when, anyway.  I never used MS's 
overlay implementation, but I used Borland's.  From what I remember, it 
swapped the entire overlay in and out whenever it need a function not in the 
currently loaded overlay.  That sounds more like the functionality you'd 
need, and the level of complexity you might want.

One thing to keep in mind with all this dynamic swapping and what not, is what 
happens if your device crashes during the swap.  You'll need a bootloader 
that can return the uC program to a good state, so there's a little bit of 
your 16 kB taken away already.  You'll need to have something like that 
anyway even if you never got interrupt swaps, unless you keep information 
about whats in and out of program memory on the E2.

BTW, I scrapped my partial upgrade scheme for something much simpler and 
safer.  We put a large E2 on the device (1Mbit) that I can download my entire 
firmware image into over my wireless link.  I then have a bootloader in the 
ATmega that can reflash the part from the E2, only after verifying the CRC on 
the image in E2, of course.  I decided this was way simpler and safer, and 
that I really only wanted to do the other thing because it would be some 
tricky coding.  And this is for a product used in restuarants!  I'd 
definitely be conservative and go simple and safe for an industrial app...

---
Geoffrey Wossum
Software Engineer
Long Range Systems - http://www.pager.net