PBP, Assembly Interupts and variables

[Bruce]

Assuming you're actually setting bit 1 in CONTROL, this will work;

IF CONTROL.0[X] THEN ' IF CONTROL.BIT.X = 1 THEN do something.

X is the bit index pointer 0 to 7. The .0 just tells PBP it's a bit.

If your variable is in bank 0, this works fine. If it's not, or you're just
not sure, then use CHK?RP in your assembler routine to look up the
bank for the var you're using.

ASM
CHK?RP _CONTROL
bsf _CONTROL,1
ENDASM

CHK?RP is a PBP macro that just looks up the variable register bank.

[Chris Barron]

[QUOTE=Bruce]Assuming you're actually setting bit 1 in CONTROL, this will work;

IF CONTROL.0[X] THEN ' IF CONTROL.BIT.X = 1 THEN do something.

X is the bit index pointer 0 to 7. The .0 just tells PBP it's a bit.

Yes, the '.0' at the end of CONTROL.0 is how I have pointed to bit0 of register 'CONTROL' .

But the good news is that by declaring the Restore variables of system registers , WSAVE,PSAVE and SSAVE, in lower-case as wsave,ssave and psave the problem is gone............

Looked at pbppic14.lib and can see that the interupt handler in there uses the lower case version. My target chip ,16F690 has4K memory and uses the lib procedures.

So I'm happy now that that code works but now I have another problem......
In the interupt I increment a register once every 20mS

Later in the basic code I try making PORTC = TICKS (ticks is the incremented register). LED's attached to portC show the value of ticks but then it's as if the port is cleared because all led's quickly go blank, until the next time TICKS changes (I presume)

Weird...I see that PORTH is mapped to PORTC, so do I have to call PORTC with PORTH, or run the risk of the PORTH value over-riding the value I set it to ?

Learning curves are here for a reason I suppose !

[Bruce]

so do I have to call PORTC with PORTH

No just access/use PORTC as you would normally.

Can you post your code? That would make it a lot easier to isolate
what's going on when you're placing ticks on portc.

[Chris Barron]

'It's a newbie thing' , as they say.

I turned off the enthusiasm and got down to reading the documentation.

The PORTH - PORTC define is a non-issue, as you say Bruce. PORTC is referenced as PORTC in the 16F68x.inc file, correctly.

The error was that I didn't notice the section of the manual dealing with interrupts for when the target device has more than 2K of codespace - I have added my own interrupt handler stub when PBasic has added one for me already. Consequently, when my stub runs after Pbasic's stub W is actually saved as the last action of the PBasic stub, and not the last value of the runtime code. Also there may have been another error with my restoration of the context registers, but I couldn't check it - I blew away and re-wrote the assembler interrupt stub completely and now it runs just as expected.


Thanks to everyone for their suggestions.

RTFM, as they say.........

Chris