avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-libc-dev] New eeprom library. Comments please


From: Nigel Winterbottom
Subject: RE: [avr-libc-dev] New eeprom library. Comments please
Date: Mon, 25 Jul 2005 14:27:36 +0100


-----Original Message-----
From: address@hidden
[mailto:address@hidden
On Behalf Of Dmitry K.
Sent: 24 July 2005 03:17
To: address@hidden
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]