Go Down

Topic: SoftwareSerial unusable on attiny45/85 (Read 11649 times) previous topic - next topic

Amigone

#15
Mar 12, 2013, 12:02 pm Last Edit: Mar 12, 2013, 02:07 pm by Amigone Reason: 1
Ok, now I am puzzled again. Software serial on baud 115200 works pretty well when I set OSCCAL to 137 or 0x89 in hex. I thought that I would fine-tune the clock to as close as possible to 8 MHz. It came out that the OSCCAL value 0x89 means a clock of 8,8 MHz a whopping 10% off, but software serial is working fine, with few errors, on 115200 baud. I am using a professional Tektronix oscilloscope used for work. Can anyone explain why it is working on that frequency and not the stock which is only 3,5% off?

NOTE
Guess I'll have to quit on this softwareserial as extremely unstable on attiny. I did get my attiny calibrated almost exactly on 8 MHz though. But serial is at all possible speeds useless. I do get some close hits in midst of noise.
For your entertainment a screenshot from oscilloscope with my final calibration. the clock is taken from PB4 when fuses are set to output the clock there.


also the code I used to "calibrate software serial"
Code: [Select]
#include <SoftwareSerial.h>

SoftwareSerial mySerial(0, 1); // RX, TX

void setup() 
{
  mySerial.begin(115200);
  mySerial.println("Hello, world?");
  //OSCCAL = 0x5A;
}

void loop() // run over and over
{
char dir = 1;
int d = 0;
while (1) {
  OSCCAL += dir;
  d = OSCCAL;
  mySerial.print("\nThis is SoftwareSerial with OSCCAL=");
  mySerial.println(d);
  delay(1000);
  mySerial.print("\nThis is SoftwareSerial with OSCCAL=");
  mySerial.println(d);
  delay(1000);
  mySerial.print("\nThis is SoftwareSerial with OSCCAL=");
  mySerial.println(d);
  delay(1000);
  mySerial.print("\nThis is SoftwareSerial with OSCCAL=");
  mySerial.println(d);
  delay(1000);
  if (OSCCAL == 0) dir = 1;
  if (OSCCAL == 255) dir = -1;
}
}

fungus


Ok, now I am puzzled again. Software serial on baud 115200 works pretty well when I set OSCCAL to 137 or 0x89 in hex. I thought that I would fine-tune the clock to as close as possible to 8 MHz. It came out that the OSCCAL value 0x89 means a clock of 8,8 MHz a whopping 10% off, but software serial is working fine, with few errors, on 115200 baud. I am using a professional Tektronix oscilloscope used for work. Can anyone explain why it is working on that frequency and not the stock which is only 3,5% off?


How did you get the clock signal out of the ATtiny?
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

Amigone


For your entertainment a screenshot from oscilloscope with my final calibration. the clock is taken from PB4 when fuses are set to output the clock there.


more about setting fuses - http://www.engbedded.com/fusecalc/

fungus


For your entertainment a screenshot from oscilloscope with my final calibration. the clock is taken from PB4 when fuses are set to output the clock there.


OK, I missed that bit.

Looks to me like the author of SoftwareSerial needs to do a bit of tweaking in his timing code...
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

afremont

Table 20-7 in the big manual shows the baud error using a 16MHz clock and Table 20-6 shows an 8MHz clock with the hardware USART.  You can see that at 115K baud, the error is the highest at 8.5% using an 8MHz clock.  I suspect the OP might be getting better thruput by intentionally running the clock slightly off frequency to compensate for the "natural" error. 

The scope seems to show a signal very close to 8MHz, not one at 8.8MHz.

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.
Experience, it's what you get when you were expecting something else.

fungus


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.

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

afremont

#21
Mar 12, 2013, 04:43 pm Last Edit: Mar 12, 2013, 04:45 pm by afremont Reason: 1


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.
Experience, it's what you get when you were expecting something else.

fungus


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.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

Amigone

To clarify,
- 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.

Will be doing my project with Manchester library.

fungus


The higher the baud rate the more accurate hits with the code posted.


That makes no sense. Low baud rate should always be more reliable.


CONCLUSION
software serial was most reliable on 115200 baud rate with off set clock.


Offset clock for 115200 baud makes sense. 8MHz isn't an exact multiple of 115200.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

binooetomo

#25
Sep 12, 2013, 07:15 am Last Edit: Sep 12, 2013, 07:24 am by binooetomo Reason: 1
Sir ...


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;
https://github.com/damellis/


Could you please tell me :  which pins is use for RX/TX ?

Sincerely



Erni

Quote
Could you please tell me :  which pins is use for RX/TX ?


If you use SoftwareSerial(), you choose the pins yourself.

There are other options:

http://www.ernstc.dk/arduino/tinycom.html

tylernt

8MHz is not an ideal speed for 115200 serial:

http://www.wormfood.net/avrbaudcalc.php

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.

binooetomo

Thankyou for your help.

I'll go SoftwareSerial path.

Sincerely
-bino-

robtillaart


You might want to check this thread - http://forum.arduino.cc/index.php?topic=138497.0 - where I derived formulas to generate the magic numbers for "any baud rate" for 8, 16 and 20 MHz Duino's

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.

Direct link to the formulas here - http://forum.arduino.cc/index.php?topic=138497.msg1058383#msg1058383 -
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Go Up