DT_INTS for K42

[mpgmike]

I know it is a bit premature, but here is the custom tailored DT_INTS for the new PIC18FXXK42.
8506

[mpgmike]

I just realized I didn't finish the job. Kindly disregard the above attachment. There was no way of testing it (of course). Will have corrected version posted soon.

[mpgmike]

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

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]

8512

Let me try again.

[dtbarber]

I am trying to use DT_INTS FOR K42 with a PIC18F27K42. I am familiar with using DT_INTS-18. Works perfectly with other PICs. However, I am receiving several errors when compiling with DT_INTS FOR K42. My PBP version is PBPX3.1.34. MPLABX is V5.30. The PBP test code simply configures comparator 1 and lights indicator LEDs to indicate if the voltage is above or below the reference voltage, and when the Comparator interrupt flag has been set or cleared. The test code works without the inclusion of DT_INTS-18K42b.

However, I receive several compile errors when I add the following code to generate an interrupt on comparator 1:

;------------------ DT Instant Interrupts ------------------------
wsave1 var byte $A0 system ;location for W if in bank0
wsave2 var byte $120 system ;location for W if in bank0
wsave3 var byte $1A0 system ;location for W if in bank0

INCLUDE "DT_INTS-18_K42b.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ; Include if using PBP interrupts


ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler C1_INT, _CMP_1, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
INT_ENABLE C1_INT ; Comparator 1 interrupt
ENDASM

The interrupt handler is a simple counter. It serves no purpose other than testing.

;------------------[CMP1 - interrupt handler]------------------------
CMP_1: ;Comparator triggered
Ticks1 = Ticks1 + 1 ;Increment counter
@ INT_RETURN




When compiled, I receive three error messages "Found label after Column 1. (Save FSR)". Also the error messages: Illegal Nesting (ENDM); Expected (END); Expected (ENDM).

Based on my read of the #Defines in DT_INTS-18_K42b.bas, and the PIC18F27K42 datasheet Summary of Registers for Interrupts, I think DT_INTS-18_K42b.bas should work with this PIC.


Any suggestions for solving the problem will be appreciated.

Dan

[tumbleweed]

The DT_INTS-18_K42b.bas file from post #9 won't work.

[dtbarber]

The DT_INTS-18_K42b.bas file from post #9 won't work.

Thanks for the response. Do you know if the problem is with the DT_INTS-18_K2b file not being mapped properly to the PIC18F27K42 interrupt register, or is it that the PIC18F27K42 will not work with DT's Instant Interrupts? If it is a matter of correcting errors, I found the "How to make custom DT's Instant Interrupts" and can try an make the necessary edits.

[tumbleweed]

It's more than just a simple interrupt register issue. The asm instructions are wrong for the K42.

See posts #4 and #6.

[dtbarber]

Looks like crafting a working DT's Instant Interrupts for the PIC18F27K42 is well beyond my skill set. It may be time for me to learn to write ISRs using assembly language. In addition to the PBP3 reference manual discussion of Assembly Interrupts for PIC 18 Devices, can anyone suggest a good reference for someone who is not familiar with assembly language coding?

[mpgmike]

Although a bit dated, my first recommendation is "Applying PIC18 Microcontrollers", by Barry B. Brey; Copyright 2008 by Pearson Education. ISBN-13: 978-0-13-088546-3.

Another recommendation is "PIC Microcontrollers; An Introduction to Microelectronics", by Martin Bates; Copyright 2011 by Martin Bates. ISBN: 978-0-08-096911-4.

[dtbarber]

Thanks for the suggested references.

[tumbleweed]

Same problem in asm, so if you can figure out how an isr works you can do it in pbp as well

[mpgmike]

Conventional wisdom states that ISRs should do only minimalistic functions. Never call a subroutine from an interrupt handler. Never use PAUSE type statements. In short, turn something on or off, or set a flag you can poll and service in your main loop. With that said, most ISRs can be crafted in ASM with only basic BSF/BCF and perhaps MOVLW/MOVF type commands. Leave the heavy lifting for a subroutine you write in PBP.

[dtbarber]

Thanks for the additional comments. At this point, all I want is to understand how to write two ISR for a PIC18F27K42 in which upon an overflow interrupt from Timer3 or Timer1, the appropriate ISR increments a counter, clears the interrupt flag, and returns back to the executing PBP subroutine. The PBP routine uses one overflow count to compute a time period . The other overflow count is used to timeout the subroutine . The application is a tachometer that measures RPM from 0 to 12K. My code works with a PIC18F26K22 and DT_INTS-18. I have tried polling the interrupt flags within the PBP subroutine, but at low RPMs and clocking the PIC at 64MHz the results are erratic.

Yes, I could just keep using an 18F26K22, but why not learn something new?

[richard]

the k42 series smt module in gated counter mode would be an ideal thing for a tacho and probably a simpler set of interrupts to manage.great lets go.
its at this time you realize that pbp has no support for any pic hardware modules that did not exist at least 15 years ago, the last time pbp had a new command the space shuttles still flew.
so if you want to take advantage of the newer pic's powerful built in stuff you need to learn a whole lot of asm
stuff to prop it up. sadly pbp has become a real programming cul de sac. I put my time and effort into a better method mplabx and C and the wonderful MCC [microchip code configurator]. The real beauty of C is its cross platform compatibility, it opens up a whole new world.


but why not learn something new?
that's my new

[Ioannis]

Cannot disagree with you Richard... But either I am too old or C is too twisted that I have hard time doing useful things with it... Sadly.

Ioannis

[mpgmike]

I agree with Richard in that I also have learned to work with C in MPLABX, but I was able to use PBP command structures to use newer functions that don't have PBP commands. I didn't need to resort to ASM.

As for clearing an Interrupt Flag and incrementing a variable, it would look something like this in ASM:


BANKSEL PIR1 ;or whatever holds the TIMERx IF
BCF PIR1,1 ;or whatever bit holds the TIMERxIF. Note use of a comma versus period
BANKSEL RPM ;or whatever your variable is called
INCF RPM ;increment your variable by 1
RETFIE

The above does not take into account Context Saving, nor does it take into account your RPM variable is probably at least 16 bits. However, the skeletal structure is about all you need for an ASM Interrupt Service Handler.

[dtbarber]

Thanks for the framework for implementing an ISR in PBP.

I concur with the comments regarding moving to C and using Microchip's IDE. I have started down that path on numerous occasions, but overcoming the inertia of being able to use PBP to easily do what I wanted was too great of a barrier for me. While it can be laborious to use PBP to implement some of the newer PIC peripherals, it can be done. For me, PBP's problem is that the language does not effectively deal with interrupts. As a friend of mine says "You do not fix a problem. You eliminate it." Given that it appears that PBP has reached its maturity, it is time for me to eliminate my problem an learn C. Painful.

[sayzer]

I have also been using c for long time so far; I have been able to convert some Arduino libraries, too.
The thing is, as mentioned earlier, moving from one compiler to another in c is much easier using the same code.

However, dealing with the registers manually is not as easy as PBP;

PBP is in my heart;

[mpgmike]

Microchip has online training that covers ANSI C, MPLABX, MCC, a long list of useful projects, and more:

http://microchipdeveloper.com/training-self:start

I have learned much from their training. I highly recommend it for those wishing to dabble in the mystical realm of MPLABX.

[Ioannis]

Are there any updates regarding the K42 devices and DT-INTS ?

Ioannis

[tumbleweed]

If you're feeling adventurous you could try the attached.

It's a modified version of the DT_INTS-18_K42b.bas code from post #9 with the context save stuff removed (now done in hdw) and the MOVFF instructions replaced with MOVFFL, which is required in the K42 and K83 since the SFR's are outside the 2K boundary for the MOVFF instruction.

It's completely untested...

[Ioannis]

Thank you tumbleweed.

Will give it a try,
Ioannis

[tumbleweed]

Keep us posted on if it works.


...required in the K42 and K83 since the SFR's are outside the 2K boundary for the MOVFF instruction.
That should have read '4K boundary'

[Ioannis]

Sure I will,

Ioannis