PortB-Change interrupt (part2)

[Eric]

Hi,

I am puzzled about the implementation of a PORTB-Change interrupt on PIC18F452.
Consider this schematic:

snap0052.jpg (59.56 KiB) Viewed 6850 times

Toggling SW1 will trigger a PORTB change on RB5, which will increment the binary count on the leds.

This is the Flowcode V4 program (based on a tutorial file from V3):

snap0057.jpg (60.01 KiB) Viewed 6851 times

My problem is this: The program seems ok in Flowcode and it simulates ok.
In real life however it doesn't work. No reaction from the led's.

If I add 1 input icon as shown in the next program, where I simply read the PORTB into a variable DUMMY, everything works fine in Flowcode AND in real life.
What is the reason behind it and is there perhaps a better way?

snap0056.jpg (63.05 KiB) Viewed 6851 times

Best regards

[Benj]

Hello

The PortB Input icon is converting the I/O pins on PortB to inputs.

Before this the I/O pins would have been defaulted to outputs on startup which is why the original program was not working correctly.

You could instead have a single dummy read of PortB right before your interrupt enable icon and this would also allow your program to run correctly.

[Eric]

Thx for the suggestion Benj.

But I tried your suggestion to have a single dummy read of PortB in the main routine right before your interrupt enable icon, but this doesn't seem to work. It only works if you insert the dummy read in the interrupt routine itself.
This is something i don't understand.
In the example program, I enable PortB-Change interrupt at the beginning of the main routine.
PORTB is, as you explained, by default configured as output, so interrupts at PortB will not work.
Therefore it seems indeed logical to configure PortB as input by an input icon BEFORE an interrupt is allowed.
However, this is ok in Flowcode but does not work in hardware. Only adding the input icon in the interrupt routine itself does the job.
This means that the interupt is enabled in the main routine ( were PortB is still configured as output ), the jump to the interrupt routine is made and only at that moment PortB is configured as input ???
I am puzzled! What do I miss?

Rgds,

[medelec35]

This is how interrupt routine is working (confirmed in simulator):

When port B interrupt is used, you do not have to set up a port B input first!

The ports default to digital i/p

Hello

The PortB Input icon is converting the I/O pins on PortB to inputs.

Before this the I/O pins would have been defaulted to outputs on startup which is why the original program was not working correctly.

You could instead have a single dummy read of PortB right before your interrupt enable icon and this would also allow your program to run correctly.

Sorry Ben, have to dissagree. I don't mind being proved wrong though .

When any port B changes from low to high, the port B interrupt macro routine is accessed, then exited.
If port B is still high then again port B interrupt macro routine is accessed.

So in your the port B interrupt macro routine, you need to determine which port B pin has gone high.

I wrote such a code for frequency measurement, which works on real hardware. I can post routine if you would like to look at it.

Your top flowcode routine should work, you will not need a dummy i/p. If does not work on your simulator, then either you have config/osc settings wrong, or there is a bug with your simulator.

[Benj]

Thinking about it, I think Medelec is right about the defaulting to an I/P on startup.

Sorry for any confusion

Not sure why the program isn't running as expected on your hardware if you remove the dummy read.

[Eric]

Thx for the replies.

Hmmmm.
I loaded the compiled Flowcode hexfile into Proteus and into my developper board ( not E-blocks but MikroElektronica )
Both had the same result: the first code didn't worked in Proteus neighter in hardware, the second code ( with the input icon ) worked on Proteus and in hardware.
So, I do think something is unclear with this Flowcode interrupt for the PIC18F452, because my experience with Proteus is that if your code works on Proteus, il will almost certainly work on hardware and vice versa. (Sorry guy's, I like flowcode but this is my experience)
Maybe someone can try this simple code on his own hardware to find out.
Attached you can find my configuration settings. Maybe there is something wrong.

Rgds,

[saschech@gmx.de]

Hallo Eric

If you compile with v3 is it the same result with proteus and your hardware ?

Regards wolfgang

Give me self a answer, it is the thame

[medelec35]

I believe the reason why it works on proteus and on real hardware when you add a dummy i/p is because of what is on page 75 of the 18F452 data sheet:

'bit 0 RBIF: RB Port Change Interrupt Flag bit
1 = At least one of the RB7:RB4 pins changed state (must be cleared in software)
0 = None of the RB7:RB4 pins have changed state
Note: A mismatch condition will continue to set this bit. Reading PORTB will end the
mismatch condition and allow the bit to be cleared.'

When I was running simulator without dummy i/p. I did notice bit 0 of INTCON register was staying at 1, and interrupt was constantly accessed only after switch Put portb 5 initially high. After then whether port B was high or low, since bit 0 was 1 and interrupt routine was permanently accessed, there was not time for port C to update with new value.

[Eric]

Hello Medelec,

Your explanation makes sense, I think you are spot on. Thanks.
I am afraid this is above the capacity of the average user ( like me ) to figure this out.

@Ben,

Does it makes sense to implement this flag-clearing issue in Flowcode so that the simulation in Flowcode will reflect the real behaviour in hardware or to add an autoclear instruction in the final C-code in case a PORTB interrupt is selected from the menu?

Rgds,
Eric