Safe usage of PBP commands within ASM ISR

[sougata]

Sougata,
Use these parts PIC12F/16F182X Controllers . Check the features and data sheets and you will see why.

I already had the PIC16F1828 in mind

the newer 16Fs (Ordered a Few Samples last week) seems promising with some interesting 18F like features : PWM steering, Internal Reference, Hardware Multiply, Enhanced Speed upto 32MHz, Even 16 bytes of common RAM like the Access Bank in the 18Fs.

and I was talking about its features

[Darrel Taylor]

So I was wondering if a list could be made available by the Gurus ( DT counting on you mostly!!! ) here on tested usage of PBP commands within the ASM ISR by II

That's a difficult proposition, because even within the same command there are different possibilities.

This statement would be OK if X was a BYTE...
IF X = 100 THEN Somewhere

But if it's a WORD, the comparison would require a call to a library function and use of system registers.

This statement would be OK ...
MyVar.0(3) = 1

This one would not ...
MyVar.0(X) = 1

Any of the major PBP commands should never be used in an ASM interrupt ... PAUSE, DEBUG, SERIN, I2CREAD, HPWM, RCTIME, SOUND, SHIFTOUT etc.

But HIGH, LOW, TOGGLE are OK.

The only way to know for sure is to search through the .LST file for system variable usage.
Not only in the immediate code for each statement, but also following all calls to the library. Not much fun, and prone to errors.

If in doubt, always use PBP type interrupt handlers.

[pedja089]

What about using math operators like //(Remainder),*, ~(Not) , with bytes?
I'm using them in interrupt for RTCC and counters, so far everything works fine...

[sougata]

This statement would be OK if X was a BYTE...
IF X = 100 THEN Somewhere.....

HIGH, LOW, TOGGLE are OK.

The only way to know for sure is to search through the .LST file for system variable usage.

Thanks Darrel for replying. Conditional branching, interrupt Flag testing and reload of Timer Values thus seems okay. How about moving bytes here and there. Like from the ADC registers to some variable etc. This makes the ISR more comprehend able to PBP users with limited ASM exposure. What about simple MATH like ADD/Subtract or Bitwise operation which are otherwise supported by the instruction set natively ?

[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.

[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.