Whenever I've gotten the 'not in sync' error, it was related to my just missing the reset timing (or forgetting the reset entirely!). For my breadboard, and Eclipse/AVRDude, un-grounding the reset pin just before or at the same time as I click the upload button is the right timing. But also check that your PC really does see the adapter when you plug it in.
Later arduino boards are built to reset whenever a serial connection gets made, and programmatically by the bootloader. This blog article describes how it works, and even more interestingly, how to hack it onto earlier boards. It shouldn't be too hard to put it on a breadboard if you wanted to. The chip needs to have a compatible bootloader, of course (which you've already put into yours). For breadboards, I just do the reset-button / mouse-click dance.
I tried a voltmeter over GND and DI10 and while measuring it showed
0V.
That doesn't sound right.
When a UART is not transmitting any data, it stays in the idle "1" state.
I expected the wires connected to the Arduino to be so-called RS232TTL levels of +5V in the "1" state and close to GND in the "0" state.
(d)
When the UART is transmitting lots of data, a multimeter typically shows some sort of average voltage between the "1" state and the "0" state, bouncing around 2 V to 4 V.
Perhaps a power or data line got disconnected or wired up wrong?
As a side note, if I remove the pinMode(rxPin, INPUT) line then
nothing is ever received (and rf.available() is always 0).
That's very unexpected.
Most Arduino documentation says things like
"Arduino (Atmega) pins default to inputs, so they don't need to be explicitly declared as inputs with pinMode()." (a)
Some tutorials for SoftwareSerial suggest explicitly declaring the TX pins to be output.
(b)
Perhaps whatever is listening to "txPin" is picking up noise, making it do something unexpected?
Most Arduino tutorials seem to use 9600 bps for the hardware Serial uart.
(c)
rf.available() is always > 0 (and also becomes 63)
How could you possibly know that?
I'm beginning to suspect the code in your Arduino is some program other than what you posted.
What happens when you test exactly the same program, but with a known serial source?
For example,
rather than connect Arduino D10 (your SoftwareSerial rxPin) to the radio, instead connect D10 to Arduino D0 (the data you type in your PC's serial monitor), and type a few words.
What happens then?
Maybe the SoftwareSerial works fine with normal UART data,
but it can't handle the high-frequency glitches common in low-cost radio receivers.
In that case, maybe it would work better to
- (a) connect the Arduino hardware UART (D0 Rx and D1 Tx) to the radio, and the SoftwareSerial to your debugging serial monitor. Or
- (b) use more sophisticated hardware that does clock recovery, etc. like the HopeRF RFM12B as used in the JeeNode and the Moteino, or
- (c) use more sophisticated software, such as the protocol Roman Black invented and describes in "RF modules made easy" or the frequency-shift keying system developed by Tom Boyd in "Pulse train detection with an Arduino".
Some test code:
#include <SoftwareSerial.h>
#define rxPin 10
#define txPin 11
SoftwareSerial rf(rxPin, txPin);
void setup() {
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
Serial.begin(9600);
rf.begin(2400);
Serial.println("Hello, I was compiled " __DATE__ );
}
void loop() {
if( rf.available() ){
int incomingByte = rf.read();
Serial.print(incomingByte, DEC);
Serial.print(" ");
Serial.println( rf.available(), DEC);
}
}
Best Answer
Depending on the margins you have available, this might work for you. It allows the Rx signal to draw the ATTiny Rx input down to 0.6-0.7V, but does not allow current to flow back into the processor. The node "ATTiny VCC" is switched on and off with the processor. If this is 5V (rather than 3.3V) you need to size the resistor so that it doesn't cause backflow problems in the Rx circuit.
If 0.6V is too high to trigger a good LOW in the ATTiny, you might use a low-drop diode like a Schottky or a germanium.
simulate this circuit – Schematic created using CircuitLab