Re: [avr-libc-dev] [RFC] New eeprom.h

[Rick Altherr]

On Feb 28, 2008, at 10:23 AM, Shaun Jackman wrote:

> The solution you're recommending is possible, and in fact probably the
> only solution with the current architecture. The only catch is that it
> requires one device-specific function for each location of the EEPROM
> registers. How many EEPROM register locations are there across the AVR
> product line?
>
> Cheers,
> Shaun
>
> On Thu, Feb 28, 2008 at 9:53 AM, Rick Altherr <address@hidden>  
> wrote:
> > While it's possibly a bit late for this option, you could write  
> > device-
> > specific methods with different function names.  Then, the header  
> > file
> > can defined a macro that expands the generic function name that gets
> > used in the source code to one of the specific methods.  That should
> > result in a larger library overall, but only the function used by the
> > device will actually be pulled into the final binary.  It would
> > prevent inlining any code at all.


Well, it would require one function per unique EEPROM register  
location.  In fact, even that isn't true.  It requires one function  
per unique code sequence required.  The register locations could be  
arguments to the function that are supplied in the header's generic  
macro.

--
Rick Altherr
address@hidden

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."
 -- Slashdot signature

smime.p7s
Description: S/MIME cryptographic signature