[ATTINY85]Nothing but junk appears on my serial monitor... :(

Spyrakos88: I think that the attiny i bought is crap.

The internal oscillator isn't guaranteed to be accurate. It says so in the datasheet.

Worse: It is guaranteed to vary with voltage and temperature.

Even if you set it up 'perfectly', it might work on hot days but not on cold days. If you run off batteries it will vary as the battery drains, etc.

Do a search for "software serial doesn't work" on this forum. See how many millions of messages there are. Ask yourself why.

Paul__B: I do not quite understand what the calibration process does...

Measure the time (in CPU cycles) of a single 'x' character sent at 9600 baud. If the processor is running fast, the time measured is too big. If the processor is running slow, the time measured is too small. After each character OSCCAL is adjusted to bring the measured time closer to the wall-clock time (actually, the serial converter's time but we assume it is accurate / matches a wall-clock). The end result is a tuned processor with the corresponding OSCCAL value sent to the serial terminal.

...so it may be necessary to add code to the sketch (and indeed any sketch) to implement the actual calibration.

It is. The OSCCAL value is not sticky. It has to be set at run-time. The top of setup should be this...

void setup( void )
{
  OSCCAL = 0x63;

...where 0x63 is the value from Tiny Tuner.

fungus:
Even if you set it up ‘perfectly’, it might work on hot days but not on cold days. If you run off batteries it will vary as the battery drains, etc.

I don’t think that’s correct. I recall serial communications should be reliable over the entire envelope. I’ll check later today if I remember.

[quote author=Coding Badly link=topic=221482.msg1612021#msg1612021 date=1393541145]

fungus: Even if you set it up 'perfectly', it might work on hot days but not on cold days. If you run off batteries it will vary as the battery drains, etc.

I don't think that's correct. I recall serial communications should be reliable over the entire envelope. I'll check later today if I remember.

[/quote]

That's going to depend on your baud rate. You could tune it to a particular baud rate I suppose...

The point is that SoftwareSerial is still hit/miss after many years of development.

A better solution is needed (IMHO). People only ever want SoftwareSerial to print stuff in the serial console and there has to be a better way to achieve that than SoftwareSerial (ie. try to emulate the timing of signals designed by a telephone engineer in the 1960s).

eg. signals that are based on an 8MHz frequency, or signals that measure the pulses starting at the rising edge of each bit not some time in the past...

Either that or drop the baud rate down to something that's foolproof. 1200 baud if necessary.

fungus: That's going to depend on your baud rate. You could tune it to a particular baud rate I suppose...

fungus: Either that or drop the baud rate down to something that's foolproof. 1200 baud if necessary.

This seems to be a common "urban" mythology. Since we are talking of proportional variations, the actual baudrate is irrelevant. If 10% error at 57.6 kbaud causes problems, 10% error at 1200 will cause just the same problems.

The only reason a lower baudrate will work more reliably is where there is an error caused by the divisor used to derive the baud clock from the current crystal frequency, and in that situation, it is possible to use OSCCAL to deliberately move the clock frequency to better suit the divisor.

I did an experiment with SoftwareSerial

ATtiny85V - 10 @ 8MHz
10 kOHM resistor from reset to VCC
0.1 uF from VCC to grnd

Tuned at 21 degree Celcius, and 5V (USB power)
Test sketch below:
Serial @ 9600

I started it at 21 degree and then put it in my frezer at -18 degree for half an hour.
Result: nothing - no garbled text it just continued to write flawlessly.

Then I stuck it on a room heater for another half hour at 30 degree, and it just kept on without failure

Lastly I borrowed my wife’s hairdryer,the temperature now +50 degree and still no errors.

Next step was to try to lower VCC

At 1.9V the text began to be garbled
Under 1.8V it stopped and resat
At 2V No problems at all.

So not bad, atleast it is good enough for me.
I can only guess that the problems with SoftwareSerial that is reported is because of lack of tuning.

#include <SoftwareSerial.h>

SoftwareSerial mySerial(3,4 ); //rx=3,tx=4 setup of software serial
unsigned int x=0;

void setup() {
  OSCCAL = 0x68;  
  mySerial.begin(9600);
  x=0;
}

void loop() {
  x++;

  mySerial.print("Test= ");  
  mySerial.println(x);
  delay(500);
}

Paul__B: If 10% error at 57.6 kbaud causes problems, 10% error at 1200 will cause just the same problems.

Sure ... if your serial implementation is bone-headed enough to only change the master clock frequency instead of tuning the number of "cycles-per-bit".

Changeing cycles-per-bit at 1200 baud could give you very fine tuning.

Erni: So not bad, atleast it is good enough for me.

Did you measure the difference it made? eg. Flash a LED at a fixed interval and time it.

Erni: I can only guess that the problems with SoftwareSerial that is reported is because of lack of tuning.

No, the problems with SoftwareSerial are: a) Tuning is very difficult b) It's a stupid way to solve the problem of "printing some text for debugging".

(surely you see the madness of trying to use a protocol that requires precise timing on a chip that has no precise clock source...)

Erni: Tuned at 21 degree Celcius, and 5V (USB power)

Hate to bring some real engineering practice into it but the datasheet has a whole section dedicated to internal oscillator accuracy (section 22.9 "Internal Oscillator Speed")

Variation is about 5% between 3V and 5V Vcc (eg. when powered with 3xAA batteries).

Variation is about 5% for every 20 degrees difference in temperature (a difference easily possible from summer to winter).

5% variation is enough to make it fail.

Paul__B: The only reason a lower baudrate will work more reliably is where there is an error caused by the divisor used to derive the baud clock from the current crystal frequency, and in that situation, it is possible to use OSCCAL to deliberately move the clock frequency to better suit the divisor.

And longer cables (more capacitance) where the rise-fall times are "long".

fungus: Hate to bring some real engineering practice into it...

Going to have to do the same to you @fungus.

Variation is about 5% between 3V and 5V Vcc (eg. when powered with 3xAA batteries). Variation is about 5% for every 20 degrees difference in temperature (a difference easily possible from summer to winter).

For the entire envelope I get a [u]total[/u] a variance of 5.3125%. Centered at 8 MHz, the variance is +1.5625% / -3.75%.

5% variation is enough to make it fail.

That's 1/2 bit error which a modern hardware receiver easily deals with by sampling an odd number of quanta greater than one and tweaking the clock.

A modern UART should have little to no trouble receiving data over the entire temperature / voltage range.

Erni: I did an experiment with SoftwareSerial

Thank you for doing that and reporting back the results.

Hi again. I would like to say that i want to enable serial because i want to connect a bluetooth module.

After a lot of research i found that:http://forum.arduino.cc/index.php?topic=183180.0 this guy managed to succesfully tune an attiny2313A. I will try to do what he did but i have several questions about the procedure. I cant find a step by step guide to tune this thing and this is an advance procedure.

How can i learn what is the right value for my attiny that will be compared from the tuner? Is this a fuse that i try to tune? If i tune it will post here.

Another option is to use avrdude to disable the internal oscilator and use an external 16mhz...

Spyrakos88: How can i learn what is the right value for my attiny that will be compared from the tuner?

If you were getting output here... http://forum.arduino.cc/index.php?topic=221482.msg1610819#msg1610819 ...then you already have the right value.

Is this a fuse that i try to tune?

No. It is a one byte value that [u]you[/u] assign to the OSCCAL register in setup.