I see no obvious problems; software serial can be flakey (that's why I don't use the Tiny84 anymore - I switched to the pin compatible 841, which has 2 hardware uarts for virtually the same price - see sig for core, atmel's datasheet for details). I'd try to narrow things down a bit... Like - can you make transmitting work? Do you get garbage? If you get garbage, maybe it's the oscillator? The internal oscillator can be way off (look at the datasheet - i think it's +/- 10% for the '84) I've seen people recently reporting issues with SoftwareSerial on the '85, though - so there may be a problem with the library too
just been playing about with my ATtiny84 using the blink sketch if i us 1mhz all is fine but using 8 or 20mhz the output comes high and that is it, could i have a problem with my library?
I actually had my first attempt at software serial on a tiny85 just a few days ago. The only way I was able to get it to work was setting the RX & TX pins to 3 and 4 (physical pins 5 & 6), I never got any other combination of pins to work (not that there are many different combinations to try on a tiny). For the record I was only using the TX pin to feed some things back to serial monitor for troubleshooting, didn't test the RX pin at all. This was a tiny85 8mhz internal.
well I've just tried the pins you suggested when i powered up my output pin went high and didn't do any thing else.
so i don't know if its the library i am using as I've had it for a couple of years now so maybe i should download it again as their might have been some update? if so where should i find it?
I don't see how your code could do anything other than nothing. The LED being lit or not depends on the variable "i" which is never changed.
A couple of other less important notes. You don't need to set the pinMode() for the TX and RX pins; the SoftwareSerial library does that for you. Second, it's not a good idea to set the pinMode() for pin=-1. The bounds checking in the core is weak and this will result in some unknown location being written to. If you don't need the transmit function but can't afford to waste a pin then it's pretty easy to clone the SoftwareSerial library and remove what you don't need.
Are you sure you have it wired correctly?
If it were me, I'd first just verify that I was getting an interrupt when the pin changed.
You could use the SoftwareSerial library for this, assuming it's correct. And assuming you have something connected to it that actually changes. For a simple test you could just take the bare wire and go from ground to Vcc.
#include <SoftwareSerial.h>
const int rx=6;
const int tx=-1; // not used and hopefully not a problem
SoftwareSerial mySerial(rx,tx);
const int ledPin = 0;
void setup()
{
mySerial.begin(9600);
pinMode(ledPin, OUTPUT);
}
void loop()
{
if (mySerial.available()) {
mySerial.read();
digitalWrite(ledPin, HIGH);
} else
digitalWrite(ledPin, LOW);
delay(100); // human visibility
}
jboyton:
Are you sure you have it wired correctly?
If it were me, I'd first just verify that I was getting an interrupt when the pin changed.
You could use the SoftwareSerial library for this, assuming it's correct. And assuming you have something connected to it that actually changes. For a simple test you could just take the bare wire and go from ground to Vcc.
#include <SoftwareSerial.h>
const int rx=6;
const int tx=-1; // not used and hopefully not a problem
SoftwareSerial mySerial(rx,tx);
Martin-X:
Read the serial data into a single char, then check that for a '1' or '2' to switch the LED.
Your array is named buf and it is indexed by i . You have stored the serial data in buf at position i , so compare the stored value against '1' or '2', not the index.
That should work if everything was going to plan. As the code from jboyton gave you a flashing LED, it looks like a timing issue. The only thing I can suggest is trying a different baud rate or clock frequency.
