Re: [avr-gcc-list] Overlays

[Richard Urwin]

On Friday 26 Dec 2003 4:05 am, Geoffrey Wossum wrote:
> 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...

An update count of 1,000 may still be enough. That's every day for three 
years. Depending on the application, that's probably enough. But the project 
is dangerously threatening the KISS principle, so you need to keep that in 
mind at every step.

> [snip]

> > 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.

> [snip]

I agree; too complicated and non-determinate. I would just have two possible 
overlays in the E2, one loaded at startup, the other loaded on command.  
Don't do demand paging, it's just a chance to add bugs and lose update 
cycles.  Try to avoid the end-user idly switching through the modes for fun. 
If it's expensive for the MCU it should be expensive for the end-user. 
Remember, if the user beats the 1,000 cycle limit then you'll be exchanging 
their kit free-of-charge, and apologising to them.

>
> 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...

Hold the KISS principle firmly in mind, and avoid clever code. Clever code is 
fun to write, but it is always bad code; hard to debug and inflexible.

-- 
Richard Urwin