My project is starting

[Darrel Taylor]

Further explanation after my reply in the "Bug" thread.

When there was ...

LATF = LATF ^ 1

LATF is is BANK7, and since PBP thought it was in BANK0, it would have changed to BANK7 to access LATF, and at that point it knew it was in BANK7.
So then it changed back to BANK0 to access CNT, PORTA, PORTC etc.

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.

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

I'm still embarrassed though.

[mackrackit]

I'm still embarrassed though.

Why???

So
BSR = 0
at the beginning of the ISR will do what with LATF?

I thought it had something to do with being in the wrong bank, but like you said CNT was already in BANK 0.

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

How should this be done? I am getting more confused than normal.

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

[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