My project is starting

[cncmachineguy]

I think PBP assumes its in BANK0 unless it does something in a different bank. Since LATF is not in BANK0, PBP will clear the BSR after executing LATF line. When I comment LATF line, sometimes the Interupt occurs during an instruction where BSR !=0, so in the interupt PBP assumes BANK0 for the BANK0 stuff.

Does this make sense? Setting BSR=0 upon entering the ISR will make sure PBP is not confused

Thank you Darrel for letting me keep some of my hair so I can pull it out on the next problem.

[cncmachineguy]

Remember that this type of ASM interrupt using PBP statements, goes against the standard rules of interrupts.

Well I am not too sure where the standard rules for interupts can be found, but in this instance, I am using PBP statements but ignoring all PBP context when entering and exiting the ISR. If I had actually written this in ASM, I MAY not have had this problem because I MIGHT have remembered to set BSR to what I needed. But at least I would NOT have thought it was a PBP issue.

At the end of the day, it is really my lack of understanding how PBP thinks. Now that I realize PBP assumes BANK0 all the time (maybe I even read that in the manual), I see why this is broke and why it is my fault as the programmer.

[cncmachineguy]

When the LATF statement was commented, it thought it was still in BANK0, and didn't try to change the bank, not knowing what bank it was really in at the start of the interrupt.

How did Protus make this work???

[mackrackit]

 BSR = 0  'IN BANK 0
 LATF = LATF ^ 32    'NOW IN BANK 7
 CNT =CNT+1   'NOW WHAT???

If I am just being thick headed let me know...

[cncmachineguy]

when PBP sees the LATF line, it switches to bank 7. when its done it automaticlly switches back to BANK 0. This way PBP can know it is always in BANK 0. So when it sees PIR1.1=0, this is a BANK 0 thing, it assumes it is in BANK 0 so it doesn't reset BSR. Now sometimes when my ISR is called, I was already in BANK 5. If the LATF line is in, PBP switches to 7, then back to 0 when done with LATF. When I rem LATF and enter the ISR in BANK 5, PBP doesn't know. So then everything that is supposed to happen in BANK 0 can't.

Adding BSR=0 as the first line in my ISR will ensure PBP won't be confused. Because the chip I am using does auto context save and restore, I don't need to worry about destroying the BSR in my ISR.

[mackrackit]

I get it now..
LAT was/is doing the same thing as BSR , as far as the BANKs are concerned.
Thanks!!!!
now it is time for a nap..

[cncmachineguy]

now it is time for a nap..

I thought sleep was for sissies?

[cncmachineguy]

I get it now..
LAT was/is doing the same thing as BSR , as far as the BANKs are concerned.

For the sake of clarity, LAT was not really doing the same thing as BSR. What it was doing was causing PBP to change banks to BANK7, therefore PBP also changed banks back to BANK0 when the LAT was done. With it remed, PBP assumed it was still in BANK0. SO when I entered the ISR with a different bank set, PBP didn't know. I gather from Darrels help in my "bug" thread, He tends to the BSR=0 in his DT_INT routine to avoid just such issues.

BTW, the only reason I can change BSR inside my ISR is because 16F1xxx automatically saves BSR upon entering an interupt. So BSR will change back when I return. Otherwise I would have needed to save the BSR to a temp, then restore it before leaving ISR.

Next up on the list of games is multiple interupts and checking who fired.
This is great fun!!!

[Darrel Taylor]

How did Protus make this work???

Because I was concentrating on the interrupts, and not simulating your entire program.
So it never ended up in other banks like your program.

Oh well.
Sorry for the confusion.

[cncmachineguy]

Whew, thanks again Darrel. I was really having second thoughts for a min. Now my brain is all re-aligned for whatever tomorrow brings