AVR-Chat

I did like your C version of the eeprom routines.  When I found out 
how to see the asm source of the library routine, it was hard to see 
what was happening without a listing of all the registers.  Even 
then it was inconvenient.

I also saw that the library routines had CLI just before what 
appeared to be the time-critical instructions.

I had read SOMEWHERE that the library routines did NOT clear 
interrupts, and that it had to be done manually before before eeprom 
access.

This is incorrect.  The library routines DO (seem to) clear the 
interrupts.  So, I do not have to worry about manually doing it, and 
ending up with them cleared for an entire multi-millisecond block 
transfer to eeprom.

THANKS!!!

-Tony

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> 
> 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@H...
> 
=====================================================================
===
> Whom computers would destroy, they must first drive mad.