16F877A External Interrupts

[mervinm]

Hi,

Does anybody know how to program and I/O pin of one of the ports of the 16F877A to be an interrupt pin, similar to the RB0 interrupt pin. I want to add 2 push button switches, each one triggering a separate macro. I can do it with RB0, but is it possible to program another pin to act as an external interrupt.

I know that RB4 to RB7 are part of a port interrupt, but my project uses those pins for another device. I cannot reallocate the device to another port, because I am running out of ports.

Cheers
Mervin

[medelec35]

You can use timer0 or Timer1 as an external interrupt to trigger a macro every time i/p goes from high to low or low to high.
I used Timer1 external interrupt as a pulse counter here:
http://www.matrixmultimedia.com/mmforum ... 06&#p23516
If your struggling to implement timer0 or timer1 as an external interrupt, then if not commercially sensitive you post your flowchart I can modify it for you

Martin

[mervinm]

Okay, I've got another problem!!!

I moved the LCD from port B (D4 to D7 connected to B4 to B7, EN to B0 and RS to B1) to port A (D4 to D7 to A0 to A3, RS to A4 and EN to A5) to free up port B, so that I could use the port B interrupts. Now the LCD has stopped working and it used to working perfectly on port B. I check the circuit a few times to verify the connections and changed the connections for the LCD on Flowcode to match the hardware configuration. All I see on the display are black squares on the first line of the LCD.

This thing is going to make me grey

Can anybody assist with this problem, pleeeeze!

[medelec35]

That sounds like either a LCD connection has not been set to correct pin, physical hardware connection or configuration setting.
Latter can be ruled out if previously working.
Posting flowcharts that exhibit the issue is always a good idea since if they look correct, problem could then be with hardware.

One thing to remember is port A4 is open drain i/p
With my lcd it works connected to port A(0 to 5)
If your LCD has same characteristics has http://www.matrixmultimedia.com/resourc ... 5-30-4.pdf
Then should be fine.
I don't believe it will require a pull-up resistor?

Martin

[mervinm]

Sorry, my fault . I checked the circuit again and the enable pin was incorrectly connected; difficult to notice on a bread board full of wires! Yes, I know it is a bad excuse!

Martin thank you for suggesting the use of the timers as external interrupts. I am going to first try to configure the port interrupt (since I now have port B available. If I have issues, I will try the timers.

Thanks
Mervin

[mervinm]

A question regarding the use of the port interrupt:

B4 to B7 form part of the port interrupt. Does this mean I can use B0 to B3 for other purposes, e.g. use them as outputs?

I want to only use 2 of the 4 B4 to B7 interrupt pins, e.g. assign push button switches to B4 and B5. Do I use a pull-up resistor on B6 and B7 to prevent false interrupts occurring on these pins?

[medelec35]

Hi. If you set the pins your not going to use as an output then interrupt for that pin should be disabled.
This will eliminate the need for any external resistors or configure for weak pull-ups

[mervinm]

Hi,

I've set up the B0 interrupt, run the simulation and when I press the interrupt switch it enters the ISR and thereafter exits as expected. When I download to the PIC and press the push button switch I wired up to B0, it enters the ISR. On exiting the ISR, it seems to re-execute the ISR; I see the same message appearing on the LCD when I enter the ISR, indicating that the ISR has been called up once again (without me touching the switch).

Do I need to reset the B0 interrupt on exiting the ISR for the first time? I checked the voltage on B0 after exiting the ISR and it is low, therefore there should be no reason why the ISR should be called up again.

Mervin

[medelec35]

Hi,
Do I need to reset the B0 interrupt on exiting the ISR for the first time?

You should not need to reset interrupt, since it's done done for you when exiting ISR macro.
Contact bounce pehaps?
Since B0 is not IOC.
If your ISR is very short, since interrupts are enabled when ISR is exited, could the switch bounce be causing to retrigger?
You could try creating a few counting loops to allow ISR to take longer to exit, to allow switch to stop contact bounce.
A better solution maybe to do a hardware debounce.
I believe software debouncing is more for non interrupt switch detection.

You have not got the LCD routine within ISR have you?

If you have then there could be corruption issues.
Best to look at the compiler messages for any corruption warnings.


Also are you using a pull down resistor to stop B0 pin from floating when switch is not activated?

Martin

[mervinm]

Hi Martin,

The ISR is quite long, so it cannot be switch debounce. I also have a 10K pulldown resistor connected to B0.

Yes, I do have the LCD code as part of the main interrupt. Should I remove it and add it to a macro called by the main interrupt routine?

Thanks
Mervin

[medelec35]

The ISR is quite long, so it cannot be switch debounce.

If access to a scope or other pulse measuring device:
You could try after removing LCD routine from interrupt is place a single output to high at the start.
Then place low output as the very last component.
The duration of ISR can then be measured.

If your flowchart is not commercially sensitive, it you post it, then I can take a look at it for you.

Yes, I do have the LCD code as part of the main interrupt. Should I remove it and add it to a macro called by the main interrupt routine?

No it is not recommended to call a macro from within an ISR.
Any interrupt macros must be allowed to exit normally at the end of the routine without undergoing any detours.

You could set a DispalyLED flag within ISR to 1.
Then in main use if DispalyLED then DispalyLED = 0: print to LCD etc.

[mervinm]

I checked the compiler log files and I am getting the following warning messages after the interrupt compile:

Serious Warning: Possible sw stack corruption, function 'FCM_Enter_On_Time' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_Clear' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

There are about 6 messages similar to the above.

How can I solve this problem, since I need to use the LCD and keypad as part of the ISR. Is there a way around this?

Mervin

[Benj]

Hi Mervin,

There is a problem with interrupts where if a macro is in use by the main when an interrupt fires that calls the same macro, some program execution corruption will occur. It wont damage anything if this happens but your program may not run as expected. This is what the warning are related to. If you are sure that the macros can never collide eg you only call the macro in main before enabling the interrupt then the warning can be ignored.

What Medelec35 is suggesting sounds good.

You could try after removing LCD routine from interrupt is place a single output to high at the start.
Then place low output as the very last component.
The duration of ISR can then be measured.

If your flowchart is not commercially sensitive, it you post it, then I can take a look at it for you.

[mervinm]

Martin / Ben, thanks for the help.

I have attached the flowcode file. The code I want to execute during the ISR is contained in the "Main_Interrupt" macro. If this can somehow be placed outside the ISR, but executes whenever the switch B0 is pressed, then my problem will be solved. Not commercially sensitive; just a school project.

Cheers
Mervin

[medelec35]

I don't want to do do much since its a school project
Interrupts should be kept as short as possible,but you have loads going on in your ISR.
I have altered flowchart to use a flag system. It may be necessary to place more

Code: Select all

If Interrupt_Triggered

decision branches within other macros as I have only place a couple within Main.

I have changed the delay of 10 seconds to a delay of 40ms within loop count of 250.

Not saying this is ideal, but its removed all the corruption warnings.
If I can think of a different way, I will let you know.

Martin

Edit. I have thought of a way this can be done.
Not exactly the way it's done in flowchart I have posted, so will change it later today.

[mervinm]

You are definitely the man ! Thanks Martin. Actually the flag method you have implemented seems to work better for my specific application, since I can control at what points in the program I want the "ISR" to execute. There are certain times I do not want the interrupt to have any effect, e.g. when the "Dispensing" macro is executing; then I do not include the test for the interrupt in that specific macro.

I would be interested to know about the other method you have thought of. Actually you do not need to send me an updated flowcode file. A general explanation of the method would be great. It might just help some poor guy having the same problem in future.

Mervin