Safe usage of PBP commands within ASM ISR

Hi All,

I initially did my Sinewave inverter in PIC18F, then came up with a version on 16F entirely built on ASM (later C+ASM). Now the goal is to make one for the proposed Wiki in PBP+ASM.

While this is quite possible on almost any PIC18F 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. I intend to try it out on a 16F+PBP+ASM+II recipe. This has the chance of making it a commercial design too, (Low Production Cost) which in turn translates into definite attention from my side and faster time to WiKi.

Obviously DT's II would be used, but lack of interrupt priority in the 16Fs seems a bottleneck when using PBP interrupts since they backup a whole bunch of PBP system variables and consume time and memory.

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. I have seen that somewhere else like the USB Service being called from within ASM ISR and have a strong feeling others exist too. Sorta ISR Tips and Tricks compilation.

Also banking issues on the 16Fs are something to be taken care of. Usage of Banksel sometimes upsets PBPs paging schemes if I am not wrong.

I have not used the 16Fs for a long time and I my exposure to 16Fs is also limited, but seems most of the forum members are using it and the only popular family of PIC in the Indian market. So an attempt to give it a try with PBP, if I fail then would port one of my existing 18F based design into PBP+ASM.

Also it would be benefical to have opinions on the choice of 16F/18F. Cause it is a modular design and the motherboard can serve the purpose of creating other power electronics/PWM projects.

P.S. : Forgot to mention that my PBP skills are a bit more rusty now so a few other Gotchas are welcome.

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

Quote:

---

Originally Posted by Dick Ivers

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

Quote:

---

Originally Posted by Sougata

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 :)

Quote:

---

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.

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

Quote:

---

Originally Posted by Darrel Taylor

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 ?

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. :eek:

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

Quote:

---

Originally Posted by Darrel Taylor

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.:watermelon:

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

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.

Quote:

---

Originally Posted by pedja089

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.

Quote:

---

Originally Posted by 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...

---

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.

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

Quote:

---

Originally Posted by 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...

---

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.

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.