Using both TMRpcm and VirtualWire libs with ATmega328, despite the conflict on TIMER1

Question

I wanted to use both TMRpcm and VirtualWire with ATmega328 in an Arduino-like board I'm making, but both libraries use TIMER1. I wanted to use each lib for the following purposes:

• TMRpcm: play a WAV sound from an SD Card;
• VirtualWire: to receive commands from an RF remote control.

TMRpcm Advanced Features Wiki has a section on how to use TIMER2 instead, but I couldn't get it to work. They also say:

Notes:

1. This is usually not the best solution.

So, before I spend any more time on this, I would like to hear what you guys have to say.

So, my question is: is there a workaround to solve this conflict on the use of TIMER1, so I can use both libs in my project?

If not, what other alternatives do I have?

My circuits for reading the SD card and driving the speaker are similar to the schematic in this Instructable: Playing Wave file using Arduino. And I'm using one of those 433MHz Receiver modules for the RF part (standard, working circuit).

Both features, the RF receiver and SD card WAV playing, work correctly, when run separately (with separate sketches).

Answer 1

You could edit the VirtualWire.cpp source to use Timer2 instead of Timer1. For VirtualWire 1.18 the relevant section starts on line 512 with #else // ARDUINO.

On line 515 change (uint16_t)-1 to (uint8_t)-1 since Timer2 is only 8 bit. Then change all the TCCR1A, TCCR1B, OCR1A, TIMSK1 and OCIE1A to their Timer2 equivalent (hint: swap the 1's for 2's). Line 533 should be the last. On line 778 you also need to make a change to use TIMER2_COMPA_vect for VW_TIMER_VECTOR.

I hope that it helps.

Answer 2

the virtual wire library has been obsoleted, and you should now use the RadioHead library. In this RadioHead Library, you can edit the RH_ASK.cpp file, and uncomment the #define RH_ASK_ARDUINO_USE_TIMER2 near the top.

Answer 3

I ended up working around the issue by building a board with two ATmegas in it. One MCU handles the sound while the other handles the RF receiver, each using its own TIMER1, both communicating via I2C.

It's kind of a low tech dual core controller board. Not the most efficient solution, but it worked great for me.