Improved interrupt handling

Seems they culd improve the way interrupts are handled.

The latency of the ON INTERRUPT methodology is undesirable. The excelent code from Tim Box that stores all the complier internal variables, allowing for picBasic instructions in an assembler interrupt, improves this. However, a simple interrupt may not use all of those variables, so saving and restoring all of them is excessive. It seems the compiler could make an inteligent decision on which ones need saved and create the neccesary code.

Or, the compiler could use duplicate macros when a function is called in an interrupt routine.

Perhaps the best solution would be a configurable combination of these options. The reletive speeds and resource utilization of the potential solutions could be presented to the user, then the user could decide which one to go with.

Anybody have any thoughs on that?
-Denny

There are many PBP functions that would not take kindly to being interrupted... Take SOUND or FREQOUT, even a brief interruption affects the output quite considerably. DEBUGIN, SERIN & SERIN2 affects timing and data bits are dropped. Operation of COUNT, PAUSE, PAUSEUS, PULSEOUT, PWMOUT, RCTIME, SEROUT etc etc would all be affected. It's not just a simple case of saving the registers. Remember the PIC (or indeed any processor without parallel processing capability) can only do one thing at a time. If it's in the middle of a time critical task, any interruption - regardless how small, will affect that task. Remember too that most of the PBP functions and commands are given to you without using any of the PIC's hardware features like timers, and using the minimum of resources, leaving them along with most of the PIC's resources free for you to use in your application.

It should be remembered that even Tim's routines affect the operation of all the time critical functions and commands to an extent where their reliability is compromised and should be used with care.

Take for example a requirement to output a 1kHz tone for 1 second... FREQOUT pin,1000,1000 go interrupt that (with Tim's or anyone's routine) and report back what happened to your output. The current way PICBASIC handles the interrupt is by letting FREQOUT complete before jumping to your ISR, which is sensible because FREQOUT's operation is not compromised.

What MeLabs should do, is, at the start of section 5 in their manual, where the commands are listed, indicate with a symbol against each command those whose operation would be compromised through being interrupted. At least then you would be forwarned which PBP functions should not be used in any such program that you create.

Melanie

Granted, it's a little more complex than my first post would indicate, but I still think there's room for improvment in that area.

-Denny