next topic »

[on:]

HI

In the arduino0007 documentation, it only mentions those interrupts. I'm assuming that's because they provide functions in WInterrupts.c to deal with them.

I'm trying to use pin change interrupts (PCINT0) and I'm having trouble due to the interrupts being triggered all the time. In my ISR, the first thing I do is set another pin high so that I can scope out when I'm entering the ISR. My other scope probe is on the pin itself, and I'm getting interrupts even when the pin value isn't chaning. I'm using a 100 Mhz scope and looking at the finest possible time resolution, so I don't think it's a glitch, but who knows.

Anyone dealt with pin change interrupts on the arduino? am I missing something really obvious?








ISR (PCINT0_vect) {
  
   char cSREG;
   cSREG = SREG;
  
   //Serial.println(PORTB, BIN);
   digitalWrite(9, HIGH);
    
   PCICR &= ~0x01;
  
   qt_data = get_bytes(10);
  
   PCICR |= 0x01;
    
   digitalWrite(9, LOW);
  
   SREG = cSREG;
  
  
  
}

[Reply #1 on:]

I haven't used a PCINT0 myself, but I do notice in the documentation that it will trigger when any  pin on port B changes depending on the setting of PCMSK0. Perhaps you have some other pins enabled? In particular, your digitalWrite(9,HIGH) is going to trigger an interrupt if it was low before. digital9 is on port B.

[Reply #2 on:]

Hi Jim

Between now and then, I've gotten it working by using PCMSK0 very carefully, ie masking everything but the pin I'm 'listening' to. I suspect that before, indeed some digitalWrites were triggering undesired interrupts.

I've found that I need to do this, since cli() and sei() don't seem to work as expected* so I've avoided using them at all, and only using the PCICR and PCMSK0 to disable/enable interrupts. In any case, this little vacation in 'interrupt hell' has opened my eyes to some things to be very careful of in the future.

Also, my advice to any other interrupt newbies: do not even attempt to debug without a scope  

*I suspect that other wiring functions (eg Serial.print) are disabling/enabling interrupts and were the cause of some of my problems.

[Reply #3 on:]

delayMicroseconds() in 0007 will sei() at the end. In 0008 it will instead restore the calling state after its cli().
I'm not sure what all uses delayMicroseconds, but I do know SoftwareSerial uses it.

[Reply #4 on:]

very interesting. I was also using a delayMicroseconds call and getting some strange data, so I switched to delay() and there was no problem. I'm gonna go look at both of them in detail now.

[Reply #5 on:]

This would be great code to get posted in the  playground somewhere if you can spare the time for a short writeup of your working code, and or experiments.

pb