Interrupts and variable saving

[Ioannis]

Hi.
First post here as I consider to be a SF compiler user.

I am trying to understand how to find which variable I have to save/restore entering the ISR.

In the example of this link https://www.sfcompiler.co.uk/wiki/pmwik ... r.SegCount

there is a context saving of TABLEPTR. Where did that variable came up from? Unfortunately, I could not find this variable anywhere within the example program or in the manual.

Like the above example I found others also with different variable also not appearing in the program. So the question is general. What should I save in the ISR and how am I supposed to find them?

Thank you,
Ioannis

[janni]

Hi Ioannis,

There are processor registers that the compiler uses and are not visible in Basic. That's one of the reasons we use high-level programming languages - to abstract from processor innards. Unfortunately, especially in small processors, that's not always possible. In this case, TBLPTR registers are used whenever one recalls constants saved in program memory (well, not always, mostly when compiler cannot foresee at compile time which value is needed - like constant array element indexed by a variable). So, if you intend to use a constant array in ISR, like in the recalled example, you need to save the table pointer. Otherwise, similar operation in main code may fail due to corrupted pointer.

So, bad news is that, unlike when writing a PC program, one needs to know some details about the procesor used and how it operates. There's no escape from checking things in processor datasheet. And servicing interrupts may be complicated - the more so the more one tries to do in the ISR. Therefore the rule of thumb: if possible use ISR only to signal tasks to do in main code.

[Ioannis]

Thanks for the reply, although this makes things more complicated.

Currently I use a dying compiler that had an addition from a member of its forum for the support of ISR. Despite what you do in the ISR there is no need to be a private detective to find what variables are needed to save.

If only there was a guide to know/find which are the necessary registers to be saved... For a begginer this is like chaos!

[Jerry Messina]

In terms of interrupt context, SF is very flexible in that it lets you specify exactly what to save in order to get the best performance.
That can get a little involved, especially for a first-time user.

Here are some hints -

Important uC registers and typical usage includes:
PRODH/PRODL - used by hardware MUL instruction, array index computations
TBLPTRU/TBLPTRH/TBLPTRU/TABLAT - used to access constant data arrays and strings in program space
FSR0/FSR1 - used primarily for strings and arrays located in RAM
FSR2 - not used by the compiler, but maybe by user modules

Hardware register names can be found in the device .bas file (ie 18F16Q40.bas) which is in the 'Includes' folder

In addition to the uC registers you also need to consider system library calls and user subroutines.
System libraries can be invoked "behind the scenes", so it's good to check for calls or variables that start with "SB_".
Since SF shares variable usage among different routines through it's frame recycling mechanism you can also specify to save any parameters and local variables used by any subroutines you call.

Using 'save(0)' will save all the system library variables ('SB_SVx'), and the FSR0, FSR1, PRODH, and PRODL registers.
The only hdw regs it doesn't save are the TBLPTR regs and FSR2, so if you want to be ultra-paranoid you can use

Code: Select all

save(0, FSR2, TBLPTRL, TBLPTRH, TBLPTRU, TABLAT)

Add to that list the names of any subroutines you call in the isr, and that should cover everything.

Many times you don't need to be nearly this conservative... it all depends on the ISR code.
Most times you can get away with just a few regs here and there but it may require some investigation on your part.

If you are using one of the new 18F devices that support vector tables (ie K42, Q family) you might want to
also checkout the IVT module in the wiki 'articles' section https://www.sfcompiler.co.uk/wiki/pmwik ... Interrupts

Download the free SE edition and play around... it's the same compiler just with the ram limited to a single bank.
As always, we're here to help.

note: edited 21 MAY 2023 to add saving TABLAT
see forum post ISR context - saving TABLAT register for more info

[Jerry Messina]

I should have mentioned a few things...

If you're coming from another compiler (like PBP), then the ultra-paranoid context save method

Code: Select all

save(0, FSR2, TBLPTRL, TBLPTRH, TBLPTRU)

is pretty similar to what it uses.


If you're using one of the xv18 core device (K42/K83, most Q family) there's an additional set of options that can be used:

Code: Select all

// individual ISR_SHADOW_LOW/ISR_SHADOW_HIGH options (SF 2.2.2.6 and above)
// used to select context save method for high and low priority interrupts
//   true = use hdw context (no software save & 'retfie 1')
//   false = use software context save (save using MOVFF/MOVFFL & 'retfie')
// for backwards compatibility ISR_SHADOW behaves as before (at least it should do)
// default setting: same as ISR_SHADOW (ISR_SHADOW_LOW=false, ISR_SHADOW_HIGH=true)
// for _xv18 core devices set both ISR_SHADOW_LOW/ISR_SHADOW_HIGH = true for best performance
'#option ISR_SHADOW_LOW = true
'#option ISR_SHADOW_HIGH = true
#if not defined(_xv18)
  #if (ISR_SHADOW_LOW = true)
    #error ISR_SHADOW_LOW, "ISR_SHADOW_LOW should not be used with standard 18F core devices"
  #endif
#endif

I'll try and do a write up on all this and post an article on the wiki in the next few days.
It would be nice to gather all the info into one spot.

[Ioannis]

Hi Jerry.

Thank you very much for the detailed reply. It is more clear now.

Yes I am coming from PBP, a more easier for the user compiler but of course with a lot of overhead in such cases.

The wiki article would be really helpful for many new-comers and I'll be looking forward to.

Thanks again,
Ioannis

[Jerry Messina]

I finally got around to writing something up.
See the wiki article on Interrupt context saving

I think I may try my hand at developing an app to aid in all this, sort of an "ISR Adivsor" tool...

[Ioannis]

Thank you very much Jerry for your effort.

Will study this detailed article. I think the tool you have in mind will help many more!

Ioannis

[Jerry Messina]

I agree. After writing that I realized how complicated a topic it can be, especially for someone not versed in all the details of the 18F.
We'll have to see if I can come up with something that helps make sense of it.

Since the original question was about the usage of TABLEPTR, I added that to the article.

[Ioannis]

Well, yes. The TABLEPTR was the initial trigger as I could not find that in the manual and got confussed. Then came all the other stuff regarding the ISR on top of the complicated 18F series chips!

Ioannis

[Jerry Messina]

I finally put together a program to aid with all this. See forum post ISR Context Analyzer

[Ioannis]

Hi Jerry.

That is a great tool! Thank you for your efforts. I am sure it will help a lot of users. New and old one.

Ioannis

[David Barker]

Thanks Jerry!

[Jerry Messina]

I am sure it will help a lot of users. New and old one.

Me included!

I should have done this years ago, it certainly makes life a lot easier. Eventually I'll add it to the compiler plugins.
Now if I can just figure out a way to get the events incorporated directly into the isr section ...