Pbp3.1.1

[Ioannis]

The K42 has builtin hardware context saving for both the high priority and low priority interrupts, which would make most of what DT-INTS does unnecessary. The list of registers it saves is pretty complete...

But not the PBP system variables I suppose, right?

These have to be saved and restored by the ISR.

Ioannis

[mpgmike]

But not the PBP system variables I suppose, right?

These have to be saved and restored by the ISR.

Ioannis

I can do a simple INCF _PBP_VAR in the ISR and then display the result on the LCD in PBP to see if it saved. I'll get to that shortly.

[tumbleweed]

These have to be saved and restored by the ISR

Right, like I said you'd have to call the SavePBP/RestorePBP routines in ReEnterPBP-18.bas/ReEnterPBP-18LP.bas like DT-INTS does to save the PBP system variables.

The rest of what DT-INTS does (and some of SavePBP) would just be repeating what the hardware has already done.

[mpgmike]

I created a couple global variables, incremented in ISR and it worked.

DispL VAR BYTE BANK0 SYSTEM
DispH VAR BYTE BANK0 SYSTEM

;Vectored ISR for Timer 1
INFSNZ DispL
INCF DispH
RETFIE 1

In the Main Loop,

DispVal.HIGHBYTE = DispH
DispVal.LOWBYTE = DispL
GOSUB Disp ;Display DispVal on LCD

Of course, this is just a snippet of the whole code, but it worked. The variable DispL was incremented in the Vectored ISR without any special context saving.

[HenrikOlsson]

Since you're using assembly in the ISR there should be no issues as far as system variables goes. But, again, it's a completely different thing if start writing PBP code in the ISR.

And just to be clear, it's got nothing to do with the variables YOU declare, it's the variables that the compiler declares and uses internally (you never see those) that's the issue and those are the variables that DT-Ints saves/restores for you when you tell it that you're going to use PBP in the ISR.

The vectored interrupt system takes away the need to save the hardware registers and the need to "manually" poll each enabled interrupts in order to determine which one it was that tripped. It does however not solve the "problem" with PBP system variable being shared between main code and ISR code.

/Henrik.

[Ioannis]

Great! this is very good.

Keep us updated please!

Ioannis

[richard]

I would be interested to :-
see how you set the interrupt vector
see how you determine the interrupt vector address
know how you partition the memory
know if pbp uses an ORG that will preserve all int vectors


and as henrik observed your example would have worked on any chip with auto context save

[mpgmike]

Vectored_INT.txt

Here is the code. I use an LCD to debug the values for DispVal. I'm using an external INT0 and TMR1 interrupts. Timer 1 overflows every 1 second. The Vector_Table_Init is mostly copy/paste from the Data Sheet. Labels T1ISR & INT0ISR are the Vectored Interrupts. The format deviates from the Data Sheet in that Address locations are denoted with "ORG 0x08C0" instead of "T1ISR CODE 0x08C0". I still don't understand why it has to use Non-Volitile Memory (NVM) for creating the Vector Addresses, but it works, and it's in the Data Sheet.