View previous topic :: View next topic |
Author |
Message |
tssir
Joined: 14 Feb 2016 Posts: 24
|
18F1320 not wakeup by int_rb |
Posted: Sun Feb 14, 2016 5:59 am |
|
|
Pic did not wakeup after hardware change on port b.
Here a simple program:
Code: |
#include <18F1320.h>
#fuses INTRC_IO,NOWDT,NOPROTECT,NOLVP
#use delay(clock=1000000)
#USE fast_io(A)
#USE fast_io(B)
#define IO_ONEWIRE_MOSFET PIN_A2
#define IO_3WIREBUS PIN_B0
#INT_RB
void rbHandler(void)
{
clear_interrupt(INT_RB);
}
void main(void)
{
set_tris_a(0b10010010);
set_tris_b(0b00111110);
port_b_pullups(true);
output_bit(IO_ONEWIRE_MOSFET,false);
output_bit(IO_3WIREBUS,false);
disable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
delay_us(200);
enable_interrupts(GLOBAL);
while(1)
{
sleep(SLEEP_IDLE);
// Just to show a result, when wakeup
while(1)
{
output_toggle(IO_3WIREBUS);
delay_ms(1);
}
}
}
|
INT_RB is called both time before sleep, without any changes on port b. Program stop at sleep command, with no wakeup by int_rb (but it works with int_timer0).
Compiler version is PCH 5.043.
I should miss something. Thank you for your help. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9215 Location: Greensville,Ontario
|
|
Posted: Sun Feb 14, 2016 6:09 am |
|
|
comments..
1) The ISR will automatically clear interrupts, so YOU don't have to.
2) While I don't use that PIC, every other one requires you to read the portB in order to 'clear ' the port. You should find th details in the datasheet, in the I/O ports section, subsection portB.
Jay |
|
|
tssir
Joined: 14 Feb 2016 Posts: 24
|
|
Posted: Sun Feb 14, 2016 9:37 am |
|
|
1) You are true. Compiler replace clear_interrupt by nothing.
2) I tried to read portB. Nothing changes. But your answer is a very good clue. I am trying to monitor RB1.
Datasheet claims: "The input pins (of RB7:RB4) are compared with the old value latched on the last read of PORTB.".
Then, INT_RB can only monitor RB7 to RB4. Not the whole portB.
I need to change my design.
Thank you for your help. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Sun Feb 14, 2016 9:50 am |
|
|
The point about reading the input, is you need to read it inside the ISR.
Otherwise if the interrupt triggers, the code can never leave the ISR, so will seem to never wake:
Code: |
//chip header etc. omitted to save space
#INT_RB
void rbHandler(void)
{
int8 dummy;
dummy=input_state(PIN_B4); //read just one pin - this is all
//that is needed. This avoids changing your TRIS.
}
void main(void)
{
int8 dummy;
set_tris_a(0b10010010);
port_b_pullups(true);
delay_cycles(10); //allow time for the pins to be pulled high
dummy=input_b(); //read whole port
set_tris_b(0b00111110); //now set the TRIS
output_bit(IO_ONEWIRE_MOSFET,false);
output_bit(IO_3WIREBUS,false);
clear_interrupt(INT_RB); //in case this was triggered by the pins
//being pulled high
enable_interrupts(INT_RB);
enable_interrupts(GLOBAL);
while(1)
{
sleep(SLEEP_IDLE);
delay_cycles(1); //The instruction after sleep should be a NOP
//now your display code etc..
|
|
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9215 Location: Greensville,Ontario
|
|
Posted: Sun Feb 14, 2016 10:30 am |
|
|
I _think_ he wants to see an interrupt on RB0. If so, according to the datasheet, it has it's own interrupt, 'external interrupt 0'.
I use this...
#define IO_3WIREBUS PIN_B0
as my clue.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Sun Feb 14, 2016 2:06 pm |
|
|
Except he has B0 defined as an output..... |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9215 Location: Greensville,Ontario
|
|
Posted: Sun Feb 14, 2016 2:42 pm |
|
|
well I'm confused...don't take much these dayze....
I figured something labelled IO.... was both Input and Output....
Perhaps we'll get a more descriptive program later. I understand English is hard even for a crazy Canuck like myself !
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Sun Feb 14, 2016 2:57 pm |
|
|
I think he intends to wake the chip with a trigger on either RB3 or RB4, then use RB0 for the one wire operation. If you look he is currently sending his 'test' signal out on this line, to determine if the chip has woken up, which makes sense in this case. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19477
|
|
Posted: Mon Feb 15, 2016 12:49 am |
|
|
As a general comment, the one thing missing from what I have posted, is the possibility of needing to ensure that other peripherals aren't using the pins involved. Disabling the analog port, and the ECCP. Generally for 90% of chips CCS will ensure that peripherals are disabled at boot, but there is a faint possibility that these are not (possibly depending on compiler version), so it might be worth adding the lines to disable these. |
|
|
|