CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Using #int_RB and false trips

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
rovtech



Joined: 24 Sep 2006
Posts: 262

View user's profile Send private message AIM Address

Using #int_RB and false trips
PostPosted: Sun Dec 13, 2009 3:04 pm     Reply with quote

Question: with the following code is the RB7 the ONLY interrupt that can trip?

I have an interrupt working on RB7 to shut down a PWM driving a motor if the current goes too high. It is too sensitive and even if I ground the RB7 pin (pin 28 on a PIC16F722) I still get trips at moderate motor speeds. I am driving the interrupt from an open collector comparator whose input never gets near the threshold. I suspected noise or ground problems but grounding the 10k pullup on the interrupt pin should kill it. The circuit and software work great without the interrupt addition.
Code:
// global variable
    short thr_flag = false;                   // false=OK, true=inhibit

// Interrupt routine
#int_rb
void detect_rb_change ()
    {
      output_low (PIN_B2);               // stop
      thr_flag = true;                       // set jam flag
    }

/* The main function */
void main(void)
 {

// setup interrupts
    clear_interrupt(INT_RB);
    enable_interrupts (INT_RB7);  // enable interrupt_on_change for pin B7 only
    enable_interrupts (GLOBAL);

// main loop
  while (1)                                  // endless loop
  {
  }                           // end of endless while loop
 }                            // end of main function

rovtech



Joined: 24 Sep 2006
Posts: 262

View user's profile Send private message AIM Address

PostPosted: Sun Dec 13, 2009 7:19 pm     Reply with quote

I changed the software to interrupt on RB6 which is used for a second PWM motor controller (enable_interrupts (INT_RB6);). This motor runs more reliably (different kind of motor) but is stopped, ie interrupt is tripped, by any attempt at running the first motor.

Bottom line: It seems that a change on any RB7 to RB4 causes an interrupt, even if they are not enabled. At present I have pins B5 & B4 floating which are probably tripping on noise pulses - I will check.

Can anyone explain how to use this feature. I do not believe that the CCS example EX.PBUTT.c will run with this compiler.
I want to have 3 different interrupts on B7,B6,B5 and be able to respond differently to each.

Anyone have a program that works?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Dec 13, 2009 7:50 pm     Reply with quote

Read these posts on how to clear the "mismatch" condition for Port B
interrupts:
http://www.ccsinfo.com/forum/viewtopic.php?t=37909&start=2
http://www.ccsinfo.com/forum/viewtopic.php?t=32735&start=1
http://www.ccsinfo.com/forum/viewtopic.php?t=35369
Ttelmah
Guest







PostPosted: Mon Dec 14, 2009 10:17 am     Reply with quote

On handling 3 sources, you just do this yourself:
Code:

// Interrupt routine
#int_rb
void detect_rb_change () {
     static int8 old_b;
     int8 new_b;
     int8 changes;
     new_b=input_b(); //Beware this method will only work, with
     //fixed, or fast I/O. If using standard_io, you will have to test
     //all three pins separately.
     changes=old_b ^ new_b;
     if (changes & 0b10000000) {
         //Here B7 has changed
         

    }
    if (changes & 0b01000000) {
        //B6 has changed


    }
    if (changes & 0b00100000) {
        //B5 has changed


    }
    old_b=new_b;
}


Best Wishes
rovtech



Joined: 24 Sep 2006
Posts: 262

View user's profile Send private message AIM Address

PostPosted: Mon Dec 14, 2009 3:37 pm     Reply with quote

Thanks Ttelmah, but does this method not assume the changes on the interrupt pins stay that way. What if the trigger is a short pulse?

Or do the input pins setup for interrupt change to input latches, and is this why someone else pointed out that a read is required to reset them?
I think I need to read the device data sheet (PIC16F722) to understand the relevant registers and flags.
Ttelmah
Guest







PostPosted: Mon Dec 14, 2009 4:00 pm     Reply with quote

Look in the data sheet.
The pin diagram for RB0...RB7, shows how the interrupt is triggered.
There is a latch, for each pin, but it is not readable by you. Basically, it is set to match what is present on the pin, when the port is read, and an interrupt will occur, when it does not match what is present on the pin. Hence using IOC, you _must_ read the port in the handler, or the interrupt will trigger for ever.
Reading the input, is the _only_ way to distingish which pin generated an input on change. If the signal is not going to be held for the time needed to get into the interrupt handler, then interrupt on change, _cannot_ be used if you need to know which pin interrupted.
It is a case of using the right 'tool'. If you want to detect narrow pulses, and know which one occurred, IOC, is not the right tool.
Remember also, that IOC, will trigger on _both_ edges. It triggers on a change, not a particular edge.
Some basic choices:
1) Use a PC with several separate normal interrupt inputs, rather than using IOC.
2) Stretch the pulse widths, using monostable multivibrators, or simple RC networks, to ensure that pulses are long enough.
3) Add your own external latch.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group