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

[Moritz Struebe]

Joerg Wunsch schrieb:
> As Moritz Struebe wrote:
>
>   
> > Is there a comprehensive list of problematic functions?
> >     
>
> Well, any.  So far, nobody volunteered to compile a list of functions
> that /are/ reentrant, thus except for a few things where reentrancy is
> obvious (like strtok_r()), all functions have to be considered
> non-reentrant.
>
> This is also what's written in the preamble of the documentation
> (second section, ``General information about this library'').
>   

Although I understand the basic concepts I'm still a beginner, so let me 
see if I get things right. There are two main Problems:
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.
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).
Are there any other problems?

Here are some more questions that came to my mind looking into this.

- 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?
- 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).
- 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?
- 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?

Cheers
Morty