Re: [Sdcc-user] Interrupts on a PIC18 - what can I do ...

[Raphael N. <rn...@we...>]

Hi,

>> it would make life easier if I can use multiple interrupts - however
>> inside an interrupt routine I need to be able to call other functions  
>> and do some floating point math. I also need the main interrupt to be
>> reentrant, so the longish bit of code that is doing the FP calculations
>> which takes a handful of millisecs can be interrupted by something else.
>> (e.g. button push, ADC conversion end, etc.)
>
> AFAIK, the PIC code generated by sdcc is *not* reentrant, so you'd  
> better take care not to call functions recursively, or have an
> interrupt call a  function while the main program has already called
> the same.

I disagree. We do not require complete reentrancy, we only require properly
nested execution of the code: If the main program is in the middle of any
routine Rn (called from main (R0), R1, R2, ..., R{n-1}) when the interrupt
fires, the interrupt routine can call each of these routines Ri (and all
others) because we save the access bank registers in the function prologue
and restore them in the epilogue. As long as the interrupt routines do not
meddle with the stack pointer (i.e., switch to a different stack), properly
nested execution of all the code generated by the PIC18 (-mpic16) target
should not be a problem.

>> or will I have to re-compile the math libraries to be re-entrant
>
> ...or you could do that.

The PIC targets (-mpic14 and -mpic16) do not support any of the
--int-long-reent or --float-reent switches and thus cannot be compiled
with (full) reentrancy enabled.
As I guess that this should not be required for the stated task, though,
I don't think that this is a real problem.
Context switching (meaning support for multiple threads with separate
stacks and arbitrarily interleaved concurrent execution of code is
not easily possible with the current code generation approach (using
a large, unspecified number of register in the access bank for locals).


Raphael