| View previous topic :: View next topic |
| Author |
Message |
rikotech8
Joined: 10 Dec 2011
Posts: 376
Location: Sofiq,Bulgariq
|
| int_rb problem |
 Posted: Sun Nov 04, 2012 5:21 am |
 |
|
Here is the code:
| Code: |
#include <16F87.h>
#fuses nowdt, put, hs
#use delay(clock = 4M)
#use rs232(baud=9600, xmit=PIN_a1,rcv=PIN_a2)
#INT_RB
void isr(void)
{
printf("\fThe change has been occurred");
clear_interrupt(int_rda); //clear interrupt flag to prevent reentrance
}
void main(){
enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
while (true)
{
output_toggle(pin_a0);
delay_ms(1000);
}
} |
When change is been occurred on B4-b7 program goes into a interrupt routine. The problem is that the program never goes out of this interrupt state. In other words it never goes back into a while cycle. Why this reentrance is happening? |
|
 |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sun Nov 04, 2012 5:31 am |
|
|
Rikoteck8,
God lord, did you even try to solve this problem yourself? As a test I did a forum search for "int_rb", and found several threads in the first page that gave the answer to your problem....
Your problem is very common, and has been asked/solved many times...
John |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Sun Nov 04, 2012 8:52 am |
|
|
The answer is in the CCS manual, the Microchip data sheet as well as this forum.
Mike |
|
|
rikotech8
Joined: 10 Dec 2011
Posts: 376
Location: Sofiq,Bulgariq
|
|
| Posted: Sun Nov 04, 2012 12:59 pm |
|
|
| Can you point exactly where to search into the CCS Manual. I have really searched about this problem but without result. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Nov 04, 2012 1:09 pm |
|
|
Seriously, forum search, 'INT_RB'.
I'll post one of the links from this:
<http://www.ccsinfo.com/forum/viewtopic.php?t=48907&highlight=intrb>
In the manual, Page 320 on the current manual, shows you what has to be done, but doesn't explain 'why'. You'll find it if you just search for INT_RB.
However the data sheet is the bible look for 'port B changed interrupt', and read what it says has to be done. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Nov 04, 2012 2:27 pm |
|
|
Mike is trying to confuse there, by carefully missing the data sheet bit that matters. I'll quote from a data sheet:
"Reading or writing PORTB will end the mismatch
condition and allow flag bit RABIF to be cleared. The latch
holding the last read value is not affected by a MCLR nor
Brown-out Reset. After these Resets, the RABIF flag will
continue to be set if a mismatch is present."
The point is that you can't clear this interrupt, until you read the port.
This has been covered _hundreds_ of times here.
Best Wishes |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Sun Nov 04, 2012 2:36 pm |
|
|
This is the section from the CCS manual, unfortunately it's not very explicit about the problem you've got. | Code: |
How can the RB interrupt be used to detect a button press?
The RB interrupt will happen when there is any change (input or output) on pins B4-B7. There is
only one interrupt and the PIC® does not tell you which pin changed. The programmer must
determine the change based on the previously known value of the port. Furthermore, a single
button press may cause several interrupts due to bounce in the switch. A debounce algorithm will
need to be used. The following is a simple example:
#int_rb
rb_isr() {
byte changes;
changes = last_b ^ port_b;
last_b = port_b;
if (bit_test(changes,4 )&& !bit_test(last_b,4)){
//b4 went low
}
if (bit_test(changes,5)&& !bit_test (last_b,5)){
//b5 went low
}
.
.
.
delay_ms (100); //debounce
}
The delay=ms (100) is a quick and dirty debounce. In general, you will not want to sit in an ISR for
100 MS to allow the switch to debounce. A more elegant solution is to set a timer on the first
interrupt and wait until the timer overflows. Do not process further changes on the pin.
|
The microchip manuals are much more direct!
| Code: | Four of the PORTB pins (RB7:RB4) have an
interrupt-on-change feature. Only pins configured as
inputs can cause this interrupt to occur (i.e., any
RB7:RB4 pin configured as an output is excluded from
the interrupt-on-change comparison). The input pins (of
RB7:RB4) are compared with the old value latched on
the last read of PORTB. The “mismatch” outputs of
RB7:RB4 are ORed together to generate the RB Port
Change Interrupt with flag bit, RBIF (INTCON<0>).
This interrupt can wake the device from SLEEP. The
user, in the Interrupt Service Routine, can clear the
interrupt in the following manner:
a) Any read or write of PORTB (except with the
MOVFF instruction). This will end the mismatch
condition.
b) Clear flag bit RBIF.
A mismatch condition will continue to set flag bit RBIF.
Reading PORTB will end the mismatch condition and
allow flag bit RBIF to be cleared.
The interrupt-on-change feature is recommended for
wake-up on key depression operation and operations
where PORTB is only used for the interrupt-on-change
feature. Polling of PORTB is not recommended while
using the interrupt-on-change feature. |
This one is lifted from the 18F1320 manual, it is representative of all the PICs.
Mike
Sorry Ttelmah, I was distracted whilst creating the reply, simply picked the wrong section of the manual. It's evening meal time here. |
|
|
rikotech8
Joined: 10 Dec 2011
Posts: 376
Location: Sofiq,Bulgariq
|
|
| Posted: Sun Nov 04, 2012 2:44 pm |
|
|
It was all about to sample port B inside the interrupt handler.
Thank you guys! I will remember that! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Nov 04, 2012 3:57 pm |
|
|
Fair dinkum.
If you can't get the wrong manual piece, while having a meal, I don't know what the world is coming to...
It's when you type 'sausages' as a reply to "what's the best PIC to use", that we'll know this is happening. 
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
