-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Dmitry K.
Sent: 24 July 2005 03:17
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] New eeprom library. Comments please
On Friday 22 July 2005 18:38, Nigel Winterbottom wrote:
> The Attachment was missing (me being a buffoon). Now Added.
...
Thanks, the code is good optimized.
Notes:
You use short commands (rcall/rjmp). Very well, but it is necessary to use
subsections in this case (look, for example, libm or ctype.S).
I am not assured of necessity to do functions atomic. In that case it is
necessary to rewrite all Avr-libc. But if to agree with such necessity your
realization is unsafe, for example:
.global Rd
Rd:
1: sbic _SFR_IO_ADDR(EECR), EEWE
rjmp 1b ; Make sure EEPR is ready
<< Interrupt with writing to EEPROM>>
in __tmp_reg__, _SFR_IO_ADDR(SREG)
cli
...
Here record of byte in EEPROM will be crashed.
Personally I use functions from Avr-libc in simple cases. In the same place,
where the big volume of record is necessary, I use my own library based on
interruptions.
Regards.
----------------------------------------------------------------
Many thanks for your comments Dmitry,
I've investigated ctype.S, is uses a macro like this
TEXT_SEG(ctype, isascii)
However I can't find where the sub-section (ctype) is defined. Can you explain
more please. Can I use an arbitary sub-section that another file may also be
using ?
Concerning the atomic read, You are correct that my routine is not "bomb-proof"
to correct this would require that interrupts are disabled for the duration of:
1: sbic _SFR_IO_ADDR(EECR), EEWE
rjmp 1b ; Make sure EEPR is ready
This loop could take as long as 9ms or so, this is far far too long to be
acceptable therefore I am going to remove this feature. If any programmer
writes an interrupt routine or a pre-emptive task switching routine that wishes
to access the eeprom then he must guard against concurrent access himself.
Regards
Nigel
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
