Interrupt question

Forum 2005-2010 (read only) General Frequently-Asked Questions
1

Hi,
I have a problem in a library and the author seems not to answer, so i try it here ;0)

#ifndef TEST
    // Set up timer1 for a tick every 62.50 microseconds
    // for 2000 bits per sec
    TCCR1A = 0;
    TCCR1B = _BV(WGM12) | _BV(CS10);
    // Caution: special procedures for setting 16 bit regs
    OCR1A = ocr1a;
    // Enable interrupt

#ifdef TIMSK1
    // atmega168
      TIMSK1 |= _BV(OCIE1A);
#else
    // others
   TIMSK |= _BV(OCIE1A);
#endif

This part of the library constantly keeps crashing, no matter what IDE (11,12,13,14) i use. The thing is that i have never worked with Interrups bevore and so dont know really what is done there or what to change to make it run. The next thing is that i use a 328 Atmel and so dont even know if those settings can somehow work at all with mine..
May someone give me a hint or two what to do?

2

I don't think its that code that is crashing, if you have a problem its probably in the output compare interrupt handler that will be called when the timer1 interrupts are triggered.

debugging interrupt handlers is not easy but if you post the ISR code perhaps someone can help. it will be something like:
SIGNAL(SIG_OUTPUT_COMPARE1A)

3

ok..
The thing is that i thought the code did crash there because execution is stopped when
TIMSK1 |= _BV(OCIE1A); is executed.
But i will post the ISR here:

ISR(SIG_OUTPUT_COMPARE1A)
{
    vw_rx_sample = digitalRead(vw_rx_pin);

    // Do transmitter stuff first to reduce transmitter bit jitter due 
    // to variable receiver processing
    if (vw_tx_enabled && vw_tx_sample++ == 0)
    {
        // Send next bit
      // Symbols are sent LSB first
        // Finished sending the whole message? (after waiting one bit period 
      // since the last bit)
        if (vw_tx_index >= vw_tx_len)
      {
          vw_tx_stop();
          vw_tx_msg_count++;
      }
        else
        {
          digitalWrite(vw_tx_pin, vw_tx_buf[vw_tx_index] & (1 << vw_tx_bit++));
          if (vw_tx_bit >= 6)
          {
              vw_tx_bit = 0;
                vw_tx_index++;
          }
        }
    }
    if (vw_tx_sample > 7)
      vw_tx_sample = 0;

    if (vw_rx_enabled)
      vw_pll();
}
4

One of those vw_ functions is the most likely cause. When you say crashing do you mean that the program freezes or do you mean something else is happening.

Is the hardware connected correctly – the code may be waiting for a response from the hardware that is not occurring.

Its just a guess, but I would look at the call to vw_pll. Can you try the code with vw_rx_enabled set to false so that function does not get called?

5

Alright... i have added a few Debug Serial.printlns to the ISR and not a single one comes into existence...
The execution freezes at TIMSK1 |= _BV(OCIE1A);.
It seems to me even as if the ISR is not even called...
I wish i knew what this _BV stuff is. TIMSK1 is, as far as i understand it the first interrupt (timer?) of the chip, but the other side of the equation?
Also - can this work on the 328?

edit
One more thing - When compiled i get the following message:
VirtualWire.cpp:411: warning: 'SIG_OUTPUT_COMPARE1A' appears to be a misspelled signal handler

Might that have something to do with it?

6

to fix: "warning: 'SIG_OUTPUT_COMPARE1A' ..."

change
ISR(SIG_OUTPUT_COMPARE1A)
to
SIGNAL(SIG_OUTPUT_COMPARE1A)

Then try it

7

Hm... that didnt fix it...

I get more and more the impression that it is the ISR that isnt handled right...

8

Didn't fix the compiler warning ?

comment out all the code in the handler:
SIGNAL(SIG_OUTPUT_COMPARE1A)
{
/*
everthing commented out
*/
}

If that works you know it is some code in the handler that is causing the problem

9

Alright... i have commented out everything that was inside the signal handler still the code freezes at the TIMSK code.
Also i still have the

"VirtualWire.cpp:411: warning: 'SIG_OUTPUT_COMPARE1A' appears to be a misspelled signal handler"

warning.

Thats somewhat strange... is it perhaps possible that COMPARE1A might be the wrong handler?

10

I have not looked at the virtualWire code, perhaps someone else here has.

11

The problem is you're using a 328 and the avr includes for that chip are really messed up. For some reason a lot of the defines for pins, vectors, etc. have been changed for no apparent reason.

The header for the ATmega8/168 is:
/hardware/tools/avr/avr/include/avr/iomx8.h

The header for the ATmega328 is:
/hardware/tools/avr/avr/include/avr/iom328p.h

To solve the incorrect vector name for the 328 chip, change:

ISR(SIG_OUTPUT_COMPARE1A)

to

SIGNAL(TIMER1_COMPA_vect)

in the library's VirtualWire.cpp file. Make sure to delete VirtualWire.o before you recompile. Of course this will make the code only compatible with the ATmega328.

This is the second time I've run across changed defines for the 328 breaking existing code for no good reason. The other example was PB0 - PB7 being renamed to PORTB0 - PORTB7. I'm going to make a post in the Software - Bugs & Suggestions forum so it's documented.

12

I take back the part about "Of course this will make the code only compatible with the ATmega328". The changed code will still work with the 8/168 as their definitions include both names for the same vector.

13

Wow, that did the trick - thank you :0)

But that seems to be really a stupid idea to change suc h stuff.. or is there a reason for it? I thought the 328 and 168 would be almost exactly the same except for Flash and this stuff..

14

I posted a topic in the Bugs & Suggestions forum about it.

It looks like the definitions for the 328 have simply dropped the "baggage" of the deprecated names for the most part. The problem is that this breaks a lot of existing code and I can't see any good reason to do this for the target user group of the Arduino platform.

These "changes" come from the AVR compiler development community and are not bugs in the Arduino environment. If that's the direction the AVR base is going, then the versions included with the Arduino IDE might need to be "customized" to better support the existing code base on the new chips.

15

it seems so..
By the way, is it possible to have such interrupts 'called' from a class or if it able to call class members from such a thing?

16

Thanks for everyones contributions to this discussion. I have now made the fix to the interrupt suggested above and uploaded a new version of the software to http://www.open.com.au/mikem/arduino/VirtualWire-1.3.zip

Other feedback to me at mikem@open.com.au is welcome.

17

You got a bit ahead of me. I did mean 1.3 and its there now.
Cheers.

18

Thanks Mike, I noticed the new version when I went to download the code the other day--I'm actually going to try it out one of these days! :slight_smile:

--Phil.

19

OK Phil,
let me know if you have any issues.
Cheers.

20

Actually, I did actually run into one issue when I tried it with arduino-0015.

I had to add the below undef in VirtualWire.h, otherwise I got an error:

#include <stdlib.h>
#include <wiring.h>
#undef round

Once I fixed that it worked. I had some issues with reliability but AFAICT it's because the module didn't have good connections to the breadboard it was sitting in.

I have no idea how much work you saved me by writing this code, so, thanks. :slight_smile:

--Phil.