AVR-Chat

On Apr 26, 2005, at 8:33 PM, arhodes19044 wrote:

> This makes sense.  Did you truncate off the high bits down to (2048-
> 1)because the CPU you were using had only 2k bytes of EERPROM?
> Since the 128 has 4K, I guess then the address would be truncated to
> (4096-1)?

The target is intended to be an ATmega64L, so when I code that is the 
manual I'm looking at. Is only recently I've had my 64L target hardware 
running so previously was loading on a MAVRIC-II and staying within the 
64 subset on the 128.

Masking values to the available range is an old habit in attempt to 
fail in a safe way and doesn't do much good here. No doubt if one tries 
to write a value too large to EEAR the effective address will be masked 
and wrapped-around by the hardware. And if one aims to be safe, thats 
the wrong way to do it. If out of range the read/write should be 
ignored, not forced to fit.

Have spent some time this afternoon looking at the avr-libc routines 
eeprom_read_block() and eeprom_write_block(). If you have looked at the 
source code I don't understand your (previous?) concern about IRQ. The 
write routine only disables IRQ for the minimum possible interval 
exactly the same as mine.

Then I started playing with my ee_writes() and ee_reads() routines in 
C, making them closer to the library's assembly routines. My count is 
only 8 bits rather than size_t's 16 bits, but my C generates smaller 
code by a few bytes. No big deal. But I'd rather have C in my project 
than assembly in a standard library when things are this close, and 
when its not something as common as memcpy().

In imitation of the assembly routines I copied SREG off into a uint8_t 
tmp, cli(), tickled bits, then SREG = tmp;, and only added 2 bytes to 
the generated code.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.