Safe usage of PBP commands within ASM ISR

[Darrel Taylor]

You should not use any multiplication, division, modulus (remainder), shifts (<<,>>) greater than 1 or 90% of any other commands in an ASM interrupt.
In general, you should just not do it at all.

But if you absolutely must ... then you will have to search through the list file to see if what you wrote uses any system variables, FSR's, TABLPTRx or HW multiplier registers.

Like I said before, there is no list of "These statements are ok, and those are not". Many statements you think are ok, won't be if you use them differently.
Use them at your own risk, or use PBP type handlers and don't worry about it.

If you do do it. Don't post the code. People don't understand the problem and try to do the same thing, creating huge problems.

I know ... I've posted them before ... but I wish I hadn't.

[pedja089]

Just found R0 in my ISR... And it's from remainder...
So what is the fastest way to save and restore PBP system variables?

[pedja089]

Just found my answer in ReEnterPBP-18 file... Thanks Darrel
I think that is too much things to save, and restore. So it would bi much better to do everything in ASM even if it requires to write basic functions like reminder in this case...

[Darrel Taylor]

Sorry, I meant to get back to this sooner but I knew it would take awhile, which is part of my point in this thread.

Just found R0 in my ISR... And it's from remainder...

It's more than that.

Along with the R0 you see in the immediate code generated by the modulus (//) statement, there's also a call to DIV in the library code.
DIV uses the R0, R1, R2 and R3 system variables.

So unless you take the time to follow every CALL (library routines call other functions too) you can't be sure of what variables you need to save.

Just found my answer in ReEnterPBP-18 file... Thanks Darrel
I think that is too much things to save, and restore. So it would bi much better to do everything in ASM even if it requires to write basic functions like reminder in this case...

Well, just think of DT_INTS as a stepping stone.
Now that you understand what it takes to write interrupts that don't conflict with PBP ... Go for it!
Or use DT_INTS and get some sleep tonight.

Either way, keep in mind that DT_INTS runs ASM interrupts with very little overhead and greater control.
It's only when ReEnterPBP.bas is used with PBP interrupts that the system variables are saved.
ASM interrupts will always give the best performance.

[pedja089]

Now I wrote INT in ASM.
The problem is that the device must be powered with battery for several years...
So INT must be as fastest as possible...

[sougata]

Now I wrote INT in ASM.
The problem is that the device must be powered with battery for several years...
So INT must be as fastest as possible...

Depending on your application, a short wake period (Higher Fosc) may not translate into the lowest average power drain. Optimizing your code and the oscillator frequency (which may not be the shortest execution) are needed. Also while measuring current for the XLP devices try to keep the ambient temp similar. Changes in ambient temp results in current changes as I have experienced.

[pedja089]

I didn't think on short wake period. I meant INT routines should have the smallest possible number of instructions.
For now average current consumption is about 10uA at 3V (CR2302), Pic running on INTOSC 4MHz.

[sougata]

If you do do it. Don't post the code. People don't understand the problem and try to do the same thing, creating huge problems.

Well Darrel that is an important piece of suggestion. I am quite comfortable with assembler and the whole point is making the ISR more readable to PBPonly users. So the whole purpose gets lost when the code is lifted and messed around in other apps.

P.S. : That also means that I have to SHAMELESSLY ask for asm versions of your other routines.