afremont:
I believe that SoftwareSerial runs into the same accuracy issues because of the granularity of the timer being used. At 115K bits are 8.68 uS in width. At 125nS per instruction (8MHz clock), delay loops just can't hit that nail right on the head since that is 69.4 clock cycles per bit. If it stretched alternating bit delay loops by one cycle length on every other bit being received, it would do better.
Does a 16MHz clock solve this?
Maybe the OP could run his ATtiny at 16Mhz using the internal PLL.
afremont:
I believe that SoftwareSerial runs into the same accuracy issues because of the granularity of the timer being used. At 115K bits are 8.68 uS in width. At 125nS per instruction (8MHz clock), delay loops just can't hit that nail right on the head since that is 69.4 clock cycles per bit. If it stretched alternating bit delay loops by one cycle length on every other bit being received, it would do better.
Does a 16MHz clock solve this?
Maybe the OP could run his ATtiny at 16Mhz using the internal PLL.
I think it will make it less of a problem, but he will probably have the best results by just tweaking OSCCAL unless he cares about the clock accuracy for some other reason. If you look at the tables in the manual, 115k has about the worst error percentage unless you use oddball crystal values tailored for serial communications. I know that's talking about the hardware USARTs, but the same problems affect SoftwareSerial.
The whole problem is "standard" BAUD rates. I guess that's what you get when you let the phone company decide that multiples of 300 would be a good idea.
afremont:
I think it will make it less of a problem, but he will probably have the best results by just tweaking OSCCAL unless he cares about the clock accuracy for some other reason. If you look at the tables in the manual, 115k has about the worst error percentage unless you use oddball crystal values tailored for serial communications. I know that's talking about the hardware USARTs, but the same problems affect SoftwareSerial.
The whole problem is "standard" BAUD rates. I guess that's what you get when you let the phone company decide that multiples of 300 would be a good idea.
I can see how SoftwareSerial is difficult to do. I don't think I'd attempt it, newbies expect stuff to work perfectly so it must be depressing to watch the complaints.
I think the OP should pick a lower baud rate (19200?), select a value for OSCCAL that works and stick with it.
The picture shows the clock after I had tweaked it to be as close to 8 MHz as possible. Softwareserial didn't work on any baud rate reliably on that frequency.
Softwareserial on baud rate 115200 worked best around 8,8MHz
The stock for my particular Attiny 45 was ~8,287 MHz 3,5% off - no functional software serial was possible with that frequency.
I tried the same sketch I posted here with lower baud rates with almost no success at all. The higher the baud rate the more accurate hits with the code posted.
CONCLUSION
software serial was most reliable on 115200 baud rate with off set clock.
mrburnette:
I have not often used serial with the ATtiny85, but I did in one project and it was very stable using the library from David; damellis (David A. Mellis) · GitHub
Could you please tell me : which pins is use for RX/TX ?
For 115200, good clock rates are 7.3728MHz or 9.2160MHz. And the closer you get to either of them, the better off you are. Looks like the midpoint (worst possible) clock rate is 8.2944MHz.
These formulas allow you to tweak the communication by setting the baud rate slightly higher /lower e.g.18900 iso 19200 -
In the thread someone used the formulas to communicate on 7800 baud succesfully.
What's more, I did some tests wrt reliability and saw that for a 16Mhz UNO SWserial was OK up to 70K baud max. Above that failures appeared.