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

[Rick Altherr]

On Feb 28, 2008, at 7:54 PM, Shaun Jackman wrote:

> Well, your suggestion would solve the code size issue, but the
> function wouldn't be particularly fast if all the EEPROM register
> accesses were indirectly addressed. In most applications, EEPROM
> writes aren't usually time critical; although I can imagine that
> exceptions exist.
>
> Do the EEPROM registers always fall in the same locations from a
> single base offset address?
>
> Cheers,
> Shaun
>
> On Thu, Feb 28, 2008 at 11:48 AM, Rick Altherr <address@hidden>  
> wrote:
> > 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.


Having finally looked at the header Eric sent out, it seems there are  
2 issues:
- If E2END > 0xFF, the EEARH register needs to be used for accessing  
the EEPROM
- EEARL and EEARH seem to have 2 different memory locations depending  
on the device

The 1st can be resolved by either making the routines do this  
conditionally inside one unified routine or by having separate byte  
and word access routines.  Eric seems to have taken the second  
approach which is perfectly fine by me.

The 2nd means that references to EEARL and EEARH when the library is  
compiled will cause it to invariably use the wrong location for at  
least subset of devices.  Having the compiled function take addresses  
as arguments would resolve that but introduces either 1 or 2 indirect  
stores.  Looking at the mega8 datasheet (it was handy), it looks like  
in and out instructions take 1 cycle.  Indirect loads and stores take 2.

If we stuck with separate word and byte access routines, then we'd  
minimize the additional cycles added.  Here's the breakdown:

__eeprom_read_byte_address_byte() would get 5 additional cycles:
  - EEARL out (1) => st (2)
  - EEDR in (1) => ld (2)
  - EECR sbi (2) => ld (2), sbr (1), st (2)

__eeprom_read_byte_address_word() would get 6 additional cycles:
  - EEARH out (1) => st (2)
  - EEARL out (1) => st (2)
  - EEDR in (1) => ld (2)
  - EECR sbi (2) => ld (2), sbr (1), st (2)

__eeprom_write_byte_address_byte() would get 3 additional cycles
  - EEARL out (1) => st (2)
  - EEDR out (1) => st (2)
  - EECR sbi (2), sbi (2) => ld (2), andi (1), st (2)

__eeprom_write_byte_address_word() would get 4 additional cycles
  - EEARH out (1) => st (2)
  - EEARL out (1) => st (2)
  - EEDR out (1) => st (2)
  - EECR sbi (2), sbi (2) => ld (2), andi (1), st (2)

For the multibyte reads and writes, just multiply the additional  
cycles by the number of bytes.  There probably would also be a few  
more cycles burned dealing with the additional arguments.

All in all, we aren't trading that many cycles for code size, but it  
could go either way.  If a program only used the eeprom functions in  
one particular location, inlining has no real penalty.

There might be an intermediate ground where the core functionality  
could be written as a set of inline functions.  The library code could  
just make a non-inline function that calls the inline routine.  In the  
header, we could then provide 2 sets of API: one set of inline  
functions that call the internal routine and a set of macros that call  
the non-inline function.  That should allow the end user to choose  
between code size and speed.

Personally, I'd go for code size over speed.  Unless someone is  
writing a program that is using the EEPROM on an interrupt handler  
that is being triggered very quickly, they won't really notice.  If  
they are in that position, they can always crib the code and  
streamline it.

If anyone is interested in the 2 API version, I could probably whip  
something up fairly quickly.  I might even have time to do it on Sunday.

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