K40 and interrupts issue

Coding and general discussion relating to the compiler

Moderators: David Barker, Jerry Messina

Post Reply
Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

K40 and interrupts issue

Post by Jerry Messina » Sat Mar 11, 2017 11:35 pm

There's an issue with the K40 and the interrupt priority setting.
If you try and compile an ISR you'll get an 'Error(54): 'RCON' not found'

The K40 family do not have an RCON register... the IPEN bit has been moved to INTCON.5
SF appears to be hard-wired to expect IPEN as RCON.7, hence the error.

Code: Select all

device = 18F25K40

// SF assumes the interrupt priority bit IPEN is RCON.bits(7)
// for the K40 (and K42), there is no RCON register and
// IPEN has been moved to INTCON.bits(5)
dim IPEN as INTCON.bits(5)

public interrupt ISR()
    if (PIR0.1 = 0) then
        PIR0.1 = 0
    endif
end interrupt

// this kludge defines an RCON register symbol so at least things will compile
// since SF will set/clear RCON.bits(7) automatically at the start of MAIN when 
// using interrupts we locate RCON at the WREG address so it doesn't cause any harm
// you'll have to manage INTCON.IPEN manually
public system RCON as byte absolute $0FE8
asm
RCON EQU 0x0FE8
end asm

IPEN = 1        // this replicates SF startup code
enable(ISR)
It would be nice if there was an #option setting or something for this. The K42 has the same issue,
so it's likely not going to be just this one chip going forward.
Attachments
k40_intr.zip
(776 Bytes) Downloaded 174 times

bitfogav
Registered User
Registered User
Posts: 169
Joined: Sat Oct 09, 2010 1:39 pm
Location: United Kingdom

Re: K40 and interrupts issue

Post by bitfogav » Sun Mar 12, 2017 6:43 pm

Thank you Jerry for the heads up..

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: K40 and interrupts issue

Post by Jerry Messina » Mon Mar 13, 2017 1:17 pm

Something else to note on the K40 is the fact that the interrupt PIE, PIR, and IPR registers are located in bank 14 (they're usually in the access bank on most devices).

This won't be a coding issue as SF should take care of that for you, but it will slow things down in the ISR if you have multiple interrupt sources and you use code like 'if (PIE.bits(x)=1 and PIR.bits(x)=1) then' to figure out which interrupt to process.

Just something to be aware of...

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: K40 and interrupts issue

Post by SHughes_Fusion » Mon Jul 31, 2017 10:08 am

I'm just about to decide on which processor to go for on a new project. The K40 series is cheaper and more flexible than the K22 I normally use but I have read a few things which suggests Swordfish isn't immediately compatible without using klunky workarounds.

Is there any indication as to whether David is planning to fix these issues with the compiler?

If not, how much of a hassle are the workarounds to implement?

Is the K40 (and K42 going forward) worth moving to, or should I just stick with the tried and tested K22 series?

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: K40 and interrupts issue

Post by Jerry Messina » Tue Aug 01, 2017 11:29 am

I haven't done a lot with the K40, but in my testing the IPEN issue here is the only real 'gotcha' as far as SF is concerned. The other issues I've run across are either mchip documentation errors or actual device errata which aren't too hard to work around.

The worst one is the NVMREG errata that affects reading from program memory, but that has already been fixed in silicon so it might not apply to you.
Is there any indication as to whether David is planning to fix these issues with the compiler?
That one's for David.

The K42 might be a different story. I'd LOVE to see support added for the new K42-class devices, what with larger memory, vectored interrupts, PPS, DMA, CLC, etc. There are a number of others in the queue with this arrangement (the K83 family) and it'd be a shame to have chips that I couldn't use SF with. The K42 looks like it could be a nice 'goto' chip to replace the K22.

8K of ram would be a welcome change (with up to 16K in the future), and the vectored interrupts would make it much easier to keep things modular, if nothing else (plus they're faster).

Post Reply