Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
Original issue reported on code.google.com by
gru...@gmail.com
on 4 Sep 2011 at 8:42