DT_INTS for K42

[mpgmike]

Would love to delete the previous version. Here is the finished one.

Attachment 8507

[tumbleweed]

I don't think that's going to work for the K42 (or the K83).

The memory layout of the SFRs is significantly different in those. The MOVFF instructions can't access the SFR banks... you need to use the new MOVFFL instruction available on those cores.

[richard]

the latest attachment is not working.

my 2 cents

looks like the auto context saving for low p interrupts needs addressing too.

if its going to fly the vectored isr capability should not be ignored .

not quite sure about the MOVFFL issue
sfrs in access bank should be ok.
the others should respond to the appropriate banksel , I think .
the few pieces of asm code example in the datasheets look fairly conventional in that reguard

[tumbleweed]

The SaveFSR and RestFSR macros along with INT_CREATE_H, INT_CREATE_L, and INT_RETURN all use MOVFF to save the context.
MOVFF can only address the first 4K of ram and the K42 is part of the new 18XV core devices that can address up to 16K of ram.

In these new devices the SFR registers have been moved into the upper banks past where the MOVFF instruction can address.
The new MOVFFL instruction has to be used in its place to address the full 14-bit ram space.

I haven't used one of these yet but the whole context saving mechanism of dt-ints may not be needed with these.
The new core includes a two-level deep context stack which saves the STATUS, WREG, BSR, FSR0/1/2, PRODL/PRODH and
PCLATH/U registers automatically for you into the shadow register memory located in bank 56.

[mpgmike]

Some of you guys blow my mind. I eagerly learn from your wealth of knowledge. In the past, modifying the DT_INTS was a simple matter of taking care of Interrupt PIE/PIR locations. At least on the MCUs I've worked with, so far so good. I will look at the data sheet and the DT_INTS-18 ASM to try to learn about what was mentioned in the previous 2 posts and see what I can learn. Thanks so much for your valuable input.

Richard, how were you able to test a PBP INCLUDE on a MCU not offered in PBP3.1? Are you already working with the new K42 using C18 or something, or did you test it in some simulation (like Proteus) package? I reference line 1, "the latest attachment is not working."

[richard]

Richard, how were you able to test a PBP INCLUDE on a MCU not offered in PBP3.1? Are you already working with the new K42 using C18 or something, or did you test it in some simulation (like Proteus) package?

sorry I have not tried these chips yet , they are unsupported by any compilers I use except xc8 which I'm avoiding
due to being fed up with mplabx machinations

I reference line 1, "the latest attachment is not working."

i'm refering to post3

Would love to delete the previous version. Here is the finished one.

that finished one is not viewable to me the attachment is faulty

[mpgmike]

DT_INTS-18_K42b.bas

Let me try again.