VirtualWire on a Tiny84

Projects Networking, Protocols, and Devices
1

Hello everybody. My first time posting here -- hoping I can get some help (would be much appreciated).

I've read a score of discussions concerning tiny85s and virtualwire--and it mostly makes sense--but mostly addresses stuff from an older version of VirtualWire, or doesn't pertain to the tiny84.

It's the usual case (but with a tiny84, and revision 1.9 of virtualwire). It's a two-way setup; a remote Arduino transmits a request for info from a second Arduino--it sends it. Pretty straight forward, and it works okay. By 'okay' I mean the logic and protocol work great, but to keep the TX/RX-error rate down at the distance I need (~10m), I run the setup at 600bps. 600bps is fine, since I'm sending a tiny message every second-or-so, but it's probably a bad omen.

The real problem comes in when I migrate the code to a tiny84. I'm using it instead of the tiny85 because it's going to collect some data and switch some relays at some point. Anyway, I'm certain that the tiny84 programs correctly, and that I've got the whole translation mapping between Arduino Dn designations and tiny85 pins (did a bunch of testing to verify the I/O of each pin).

Here's the rub. As soon as the sketch calls vw_setup( 600 );, the whole thing goes straight to hell. Specifically, this line of code in virtualwire.cpp: TIMSK1 |= _BV(OCIE1A);.

Here's the code:

#include	<VirtualWire.h>

// #define	DigitalRXIn		0		// 0 = ATtiny84A pwm		pin 2
// #define	DigitalTXOut		1		// 1 = ATtiny84A non-pwm	pin 3
#define		DigitalRXIn		3		// 3 = ATtiny84A pwm		pin 6
#define		DigitalTXOut		6		// 6 = ATtiny84A non-pwm	pin 9
#define		DigitalPTT		2		// 2 = ATtiny84A pwm		pin 5

#define		DigitalLEDyOut		8		// 8 = ATtiny84A		pin 11
#define		DigitalLEDgOut		9		// 9 = ATtiny84A		pin 12

void setup()
{
	vw_set_rx_pin( DigitalRXIn );			// Define RX pin to vw
	vw_set_tx_pin( DigitalTXOut );			// Define TX pin to vw
	vw_set_ptt_pin( DigitalPTT );			// just to avoid pin conflicts
	vw_setup( 600 );				// Initialise ISR with b/sec

	pinMode( DigitalLEDgOut, OUTPUT );
	pinMode( DigitalLEDyOut, OUTPUT );
}

void loop()						// ...never executes
{
	for ( int i = 0; i < F_CPU / 1000000; i++ )
	{
		digitalWrite( DigitalLEDyOut, HIGH );
		digitalWrite( DigitalLEDgOut, HIGH );
		delay ( 150 );
		digitalWrite( DigitalLEDyOut, LOW );
		digitalWrite( DigitalLEDgOut, LOW );
		delay ( 150 );
	}
	delay( 1000 );
}

Hoping somebody can provide some insight. I've been racking my brains for days. Even tried setting OSCCAL values in the range of 115 to 130 (arbitrarily). Thanks.

2

insane:
Here's the rub. As soon as the sketch calls vw_setup( 600 );, the whole thing goes straight to hell. Specifically, this line of code in virtualwire.cpp: TIMSK1 |= _BV(OCIE1A);.

What? It vanishes completely? Strange.

3

Maybe try to change it to TIMSK |= _BV(OCIE1A);.
There is a very similar problem with softserial because the attiny only have one timer.

4

duplo:
Maybe try to change it to TIMSK |= _BV(OCIE1A);.
There is a very similar problem with softserial because the attiny only have one timer.

Nope. That's a tiny85. I'm using a tiny84; two timers -- mask register are TIMSK0 (8 bit) and TIMSK1 (16 bit).

@Nick, hey mate.... is that what that means down unda? :wink:

Update: I added a 16MHz xtal. I was beginning to believe it was the internal oscillator -- had high hopes. No dice. [Nick, in American-English, that means "didn't work"]
No change except that my diags flash 16 times (as it should) instead of 8.

So... this stumps everybody? Not just me?

5

insane:
the whole thing goes straight to hell.

...

insane:
Nick, in American-English, that means "didn't work"

Ah, my sense of humour is running away with me perhaps. :slight_smile:

What I was getting at is, what does "didn't work" or "goes to hell" mean? What happened? What did you expect to happen?

No change except that my diags flash 16 times (as it should) instead of 8.

You probably know what you are expecting more than we do. How about spelling it out?

6

Yes...I was just kidding back :wink:

Actually, at the 'hell' point, the program on the tiny84 seems to just lock up. Any LEDs that were on before stay on; any that are supposed to come on after, don't. Just locks up. Goes away -- to hell, I believe.

Yup. 8 flashes or 16 flashes is referring to the little routine I've got in loop() to give me the value of F_CPU (/1M). When I switched over to running 16MHz xtal, I tested without the calls to virtualwire -- just to verify that the tiny84 knew it was supposed to be running at 16MHz. I tried that because I suspected the 8MHz internal-oscillator configuration might be off enough to jimmy up the timing between its partner RX/TX on the Arduino sitting near by.

Here's a diagram of the setup. It's probably a little different from the I/O configuration I described. That's because I've tried a whole bunch of configurations (in desperation).

...okay, I couldn't figure how to get the image between the tags, so I just attached it.

Tiny84_TXRX.JPG
Tiny84_TXRX.JPG372×539 32.3 KB

7

Hmm.... It can't be that no one has gotten VirtualWire to work with a ATtiny84....

Anybody tried and having the same problem?

8

Just in case you come back to this topic, I have exactly the same problem and spent many hours on trying to solve it with no success. Did any one get VirtualWire to work on an ATtiny84

9

having exactly the same problem. :~ any solution yet?

10

I'm using VirtualWire 1.27 with success on a tiny84. In case the compiler is in any way connected to the issue some people experience, I'm using gcc 4.7 (the Arduino package on Debian Wheezy).

I also had issues with lockups for a start, however they turned out to be caused by me seeting vw_set_ptt_pin(-1) and vw_set_tx_pin(-1). The -1 causes the pinMode calls in vw_setup() to write to arbitrary memory addresses - not a good idea. Caused me code lockups and weird behaviour. Since VirtualWire has default pin values, and not all of them exist on the tiny84, it is crucial to call vw_set_ptt_pin(), vw_set_tx_pin(), and vw_set_rx_pin() and set them to existing pins before calling vw_setup().

For some reason 4800 baud gives very unreliable connections, even through a copper wire with no wireless modules. Maybe the issue is with my uncallibrated 8 MHz oscillator? Anyways, the 2400 baud work realiably. I didn't try any other speeds.