On Thu, 12 Nov 2009, Raphael Neider wrote:
> 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.
This is good news!
main() will never call any functions that are called from an interrupt,
and there is no recursion either. I'm not fiddling with the stack pointer
either. My concern is something in main() doing floating point, then being
interrupted, the interrupt task also doing floating point, returning, then
the result of the FP operating being carried out in main() being
corrupted.
>>> 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.
We need more documentation on this - I may even volenteer after I've done
my project, and even give examples...
My experience of using the PIC16 variant of SDCC has been very good
so-far, despite almost being put off by lots of warnings on various web
sites - trouble is, they're all dated some years back!
> 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).
Essentially what I have is an interrupt driven/assisted coroutine manager.
I have a regular timer interrupt, and this scans a list of tasks, and
calls them as needed (based on an abolute or relative time). However, it
re-enables interrupts before it calls the task, so that if the task takes
a time longer than the tick time, another task can be executed. (It will
never call an active task twice). The tasks are not allowed to sit in a
loop forever (well, one could, but only one, and then main() would never
continue!) they must relinquish control in a timely manner (like
coroutines) I've been running this tiny scheduller for a few different
projects on AVR platforms, but now I have a nice PIC project to do and
want to use the same framework.
So from what you're said above it looks like it should work OK.
I'll give it a go and let you know :)
Thanks,
Gordon
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
