Re: [avr-libc-dev] pgm_read_byte_far & Interrupts

[Joerg Wunsch]

As Moritz Struebe wrote:

> The first problem is, that when an interrupt occurs not all
> registers are saved and restored. Especially the RAMPZ, which is
> used during memory access.

In general, *no* IO registers are saved except for SREG.  This is a
reentrancy problem, not strictly an interrupt problem.  (It would also
apply to other recursive calls, albeit they are not very frequently
seen outside of interrupt handling and everything related to that.)

> The second problem is, that certain commands don't like Interrupts,
> because they have time limits (SPM has to be called at most 4 cycles
> after the SPMCSR is written).

Yes, that's the second one, and it's a genuine interrupt-only problem,
not a reentrancy one.

> - Is it reasonable to wrap all lib-functions that use RAMPZ / SPM /
> EEPROM write in a "sreg = SREG; cli(); / SREG = sreg;" by default.
> (Using macros to turn that off.) And if not - why?

Not inside avr-libc itself.  It would cause a penalty for every user,
even for those who intentionally keep their ISRs short and free of
"problematic" function calls.

> - The doc says that I do have to turn Interrupts of while writing to
> Flash/EEPROM, but it isn't very clear about (E)LPM/reading
> EEPROM. Are there any problems besides (RAMPZ not getting saved).

Well, that would be part of someone volunteering for reviewing all
functions involved...

> - Will a {SREG = sreg;cli();} cause one interrupt to be handled (If
> I understand things right, after RETI the cli will be executed
> before any other Interrupt is handled), or will the cli turn of
> interrupts before any interrupts get executed?

As enabling interrupts is always deferred by one CPU cycle but
disabling is immediate, no interrupt could break into the above
sequence.

> - To make those functions reentrant they would have to loop the read
> functions until RAMZ_before = RAMPZ_after and the write functions
> would have to loop until until the corresponding bits get
> cleared. Right?

I don't quite follow you on that.  Why looping?  Just wrapping the
access into an ATOMIC_BLOCK (<util/atomic.h>) should IMHO suffice.

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

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