Matrix user forums

I'm experimenting with 'RB Port Change' interrupts, using a Formula Flowcode Buggy. Some of the results are not quite what I expect!

Problem 1: I have very simple program, which enables the 'RB Port Change' interrupt, with a simple interrupt service macro. My main program then simply executes a holding loop, waiting for the interrupt to be triggered.

If I press one of the two switch buttons (connected to Port B, bits 4 and 5) the interrupt is triggered as expected. However... if I hold the button down, the interrupt is continually re-triggered for as long as I hold the button down. To verify this, I have added a simple counter variable which is incremented within the interrupt macro, and the LEDs are updated with the counter value. Once back in my main program loop, the LEDs are cleared. A small delay in the interrupt macro is sufficient to allow the LEDs to clearly show an increasing binary count as the interrupt macro is repeatedly called while the button is held down.

Now, I fully expect that some switch bounce will lead to several interrupt events when I first press the button. But, once the button is held down firmly, I expect the 'state' of the relevant Port B bit to be held constant and hence, without any changes, there should be no more interrupts (until I release the button, whereupon the state changes again).

I have noticed on the Buggy that Port B, bits 6 & 7 are effectively floating. Using a different diagnostic program, I observe erratic behaviour on these bits when Port B is continually read (as a byte) then written to the LEDs. This is particularly evident when either of the switch buttons are pressed. However, a workaround to prevent these bits possibly causing my repeated interrupts is to first set them as outputs, before my main program enters the holding loop. Either way, the problem with repeated interrupts persists!

Problem 2: I enable the interrupt and specify a macro to be called. Later in my program, I disable the interrupt, and then enable it again with a different macro. This works fine in the simulator, but fails on the Buggy, with the first macro being called, rather than the second one.

And one final question... how does Flowcode handle the disabling of interrupts within the interrupt macro? The PIC (I believe) generally disables an interrupt on entering the interrupt service routine to avoid recursive interrupts, (or stack overflow?). My question is simply, within Flowcode, is there ever a need to explicitly disable an interrupt within the interrupt service macro?

Any help, answers or suggestions welcome!

1) ...if I hold the button down, the interrupt is continually re-triggered for as long as I hold the button down...

I seem to remember that you need to read from PORTB to "reset the mismatch condition" that triggers this interrupt. Try creating a "dummy" variable and reading the contents of PORTB using an "input" icon (it's probably best to use the mask feature to only read B4-7).

If this doesn't work, please send your program to us and we'll have a look.

2) ...fails on the Buggy, with the first macro being called, rather than the second one.

This is a known bug that connot be easily fixed at the moment. At workaround is to use a single macro for this interrupt, which selectively calls the appropriate macro. You should create a variable (e.g. IntRoutine) that is set to 1 or 2 whenever the interrupt is enabled. The interrupt macro can then use a decision:
if IntRoutine=1 call macro1
if IntRoutine=2 call macro2

3) ...is there ever a need to explicitly disable an interrupt within the interrupt service macro?

You are right - the PICmicro automatically disables all interrupts when an interrupt is first triggered. It automatically re-enables them when it returns from the interrupt.

Thank you Steve... that's very helpful.

Reading from Port B (from within the interrupt service macro) does indeed clear the mismatch condition.

I suppose this raises an interesting question (which you folks will no doubt have thought about in designing Flowcode) and that is, when should a relatively low level and mandatory operation (like the need to read these bits, just in order to clear the mismatch condition) be 'hidden' within the high level icon commands of Flowcode?

Of course, if you had Flowcode reading the upper four bits of Port B automatically (folllowing an RB Port change interrupt) that would assume all four bits were being used as inputs... Flowcode could check first I suppose.

My program works as expected now, with a masked read from just bits 4 & 5 of Port B, since I have bits 6 & 7 set to outputs to prevent spurious interrupts from these floating/unconnected bits.

I've noted the workaround for the other problem (different macros, same interrupt source) - I guess you'll fix this in a later version!

Many thanks - keep up the good work. My students seem to like Flowcode!

I'm glad things are ok.

I think you're right - performing an automatic read to resolve the mismatch condition would be an improvement and should have a fairly small performance hit.

Funnily enough, the coding of the interrupts has changed recently to make it more flexible, so I should be able to fix this soon (within a minor installation update).

The other problem (i.e. multiple interrupt enables need to call the same macro) requires a bigger fix, so this will need to wait until version 4.