Instant Interrupts - Revisited

[Christopher4187]

I've used the DT_INTS sucessfully with an 18F4550. I had to move to an 18F87J50 but the DT_INTS would not compile. Not sure if I'm doing something wrong or if the DT_INTS was never tested with J series PIC's. When I compile, I get the following warning message:

Unable to fit variable VP_DelayCount in requested bank 0

In the "VirtualPort.bas" code, I changed this code:

VP_DelayCount  VAR WORD BANK0  ; Used for internal Delay only

to this:

VP_DelayCount  VAR WORD BANK1  ; Used for internal Delay only

and it compiled as expected. I have no clue if this will cause unexpected problems with my program or if this is the correct way to solve it but I haven't noticed any ill effects yet. Seems like this problem could be related to the SFR's but it's way above my level of knowledge.

Just thought I'd pass it along.

[Darrel Taylor]

NO! You can't just change the variable to BANK1!
That variable must be in BANK0.

Both DT_INTS-18 and VirtualPort.bas fit quite comfortably in an 18F87J50, with room to spare. Even when using PBPL.

How many variables have you declared in BANK0 in your program?
Or, what other include files are you using that may have variables placed in BANK0.

[Christopher4187]

NO! You can't just change the variable to BANK1!

Oh. The door was locked and I couldn't find the key so I just picked the lock.

How many variables have you declared in BANK0 in your program?
Or, what other include files are you using that may have variables placed in BANK0.

Good questions and ones that I wish I had answers for. I'm using HIDmaker so that's probably the root cause. Do I need to figure this problem out or is there a workaround?

[Ioannis]

I am trying to make an Interrupt on Rising Edge, PortB.0 on a 16F1827 chip.

When first POR the device, it send the message "Program started" and waits for the Interrupt.

When interrupt happens, Portb.0 is left open (it has pull-up enabled) the ISR is executed sending the message "Hey, I am sleeping!".

And then keeps on sending the message even if the PortB.0 has been restored (grounded).

Anyone sees what stupid thing I missed?

Ioannis

[Darrel Taylor]

Ioannis,

You just need to clear the IOCBF register before exiting the ISR.

IOCBF = 0

[Ioannis]

Oh, I see.

I thought this was taken care by the DT-INTS.

Thanks Darrel,
Ioannis

[Darrel Taylor]

That's what everyone else thinks too, so don't feel too bad.

However, the "Interrupt On Change" on some chips have many interrupt flags that "funnel" into a single IOCIF flag.
DT_INTS only knows about the one IOCIF flag. It has no control over the other 8 flags in the IOCBF register.

It's alot like the USB modules which have 12 interrupt flags that funnel into a single USBIF flag.
But for some reason, nobody expects DT_INTS to handle all of those automatically.
Well actually, if you add DT_HID, they are handled automatically, but that's not the point.

There are too many variations of the IOC interrupts.
Some chips have them on PORTB, some on PORTA, and some have combinatons of PORTA, PORTB and PORTC.
Its the one part of a PIC that you can pretty much assume won't work the same way as the last chip you used.

And there are too many ways you can use IOC interrupts, there's no way I could make something that would work for everybody.
It's much easier for the user to add one or two lines of code to clear the flags the way that best fits the application.