Re: [avr-libc-dev] eeproms and interrupts

[Joerg Wunsch]

As Bernard Fouché wrote:

> Well there are not re-entrant but interrupt safe, even for eeprom
> access since eeprom_write_* blocks interrupts correctly.

You're right.  It's more about reentrancy problems.

We could add reentrant functions if needed.  They are commonly denoted
by appending the suffix "_r", as in strtok_r().  People with OS'es
usually need them, but then, I'm not sure whether they are served that
well by blocking interrupts, or they'd rather rewrite their own using
a mutex or such.

> I was not sure about eeprom read, and "brberie" comments and Atmel
> documentation confused me about that.

It appears from the comments above those examples they generally
believe it to be common practice to access the EEPROM from within
ISRs.  They explicitly state the needed interrupt protection between
step 5 and 6 in the write sequence (which we do handle), yet
`recommend' protecting everything starting at step 4 (setting EEADR).

> Why not having something like: "All functions are interrupt safe but
> may not be re-entrant[*]. The user is advised to read Atmel
> documentation about features directly related to hardware like
> eeprom or flash write for instance."

Hmm, maybe.  I might want to add the half sentence at [*]:

"so cases where library functions are called both inside and outside
interrupt service routines should be carefully examined, and proper
protection added if required"

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)