Possible re-entrance issue with USART INT handle

[GoogleCodeExporter]

The sei() issued near the beginning of the USART RX INT handler leaves the 
return code (pops and original compiler generated sei) open to re-entrance.

The sei is needed as early as possible (directly after the RX byte is read), to 
enable global interrupts for the PPM_out INT handler to prevent excessive PPM 
jitter.

The only was to solve this problem (besides using hardware PPM_out switching -- 
another story on its own) is to write the entire USART RX INT handler in 
assembler. This will not be difficult.

NOTE: The chance of actual re-entrance occurring at 9600 baud serial receive is 
highly unlikely. But it should not be left a possibility.

Thanks to Bertrand for keeping on this until I finally realised there was a 
problem. I was putting too much reliance on the C compiler without checking the 
assembly code! My bad.

Original issue reported on code.google.com by gru...@gmail.com on 4 Sep 2011 at 8:42

[GoogleCodeExporter]

I give up.

I spent half a day trying to get both in-line assembly and a full (.S file) 
assembly version of the ISR routine working. I failed miserably, due to 
avr-gcc's complete inability to handle mixed assembly and C properly. 
Specifically, the compiler fails recognise and save clobbered registers when a 
C function is called from assembly. (The C compiler and assembler do not talk 
to each other in the right direction.) Since there's no way to know what 
registers the compiler will choose for the C function at any given time, it is 
completely useless even trying. (The same issue exists using ISR_NAKED and 
in-line assembly. You cannot call a C function inside the ISR without 
unpredictable register corruption.)

So, we're just going to have to live with this, knowing that it won't be an 
issue on the newer boards anyway, due to hardware PPM_out switching.

Original comment by gru...@gmail.com on 5 Sep 2011 at 11:11

• Changed state: WontFix

[GoogleCodeExporter]

Even on actual stock PCB, there is no real problem, unless the module sends 
data (and the CPU receives) at a higher speed: today around 100ms between two 
characters.

I even think that we could leave the USART RX interrupt as it is during the 
whole function.

Original comment by bson...@gmail.com on 6 Sep 2011 at 9:39

[GoogleCodeExporter]

But I still prefer having it with the sei() AND the cli() as you did, even if 
practically the problem should not occur.

Original comment by bson...@gmail.com on 6 Sep 2011 at 10:14

[GoogleCodeExporter]

The reason for putting the sei in there in the first place was because jitter 
was hitting over 120us.

Original comment by gru...@gmail.com on 7 Sep 2011 at 1:35