After googling quite a bit, I still have no definitive answer on how to get softwareserial working on attiny45.
I came across threads that discussed getting it working with earlier versions of Arduino IDE but nothing with the updated versions. As if it is already fixed there. After reading that the "mit" tiny library has known problems with softwareserial, I am using the "google" Google Code Archive - Long-term storage for Google Code Project Hosting. library. Also I have Arduino IDE 1.0.3
The point: so far my debugging has got me into a situation where I only get noise from serial. I read from somewhere that the attiny internal crystal is way off for using the software serial. I also upped the speed to 115200 and this actually got me more information over noise than the lower speeds. I could almost see entire words in midst the noise =D
Is it actually possible to get the software serial to work on attiny45 without an external crystal or not?
PS
I do need softwareserial as I need to make two attinys communicate (one way only actually)
I insert my current code as well, although I have tested very many different ones
// include the SoftwareSerial library so you can use its functions:
#include <SoftwareSerial.h>
#define rxPin 0
#define txPin 1
// set up a new serial port
SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin);
byte pinState = 0;
void setup() {
// define pin modes for tx, rx, led pins:
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// set the data rate for the SoftwareSerial port
mySerial.begin(115200);
}
void loop() // run over and over
{
mySerial.print("this is a lot of text for you");
delay(2000);
}
An example of information received over serial. On lower baud rates, I rarely receive any real letters.
You can "recalibrate" the internal RC oscillator to be within 1% which is plenty accurate for serial communications. You will need something to accurately measure the clock. I do see the factory calibration is pretty poor at 10% which is the absolute edge that you could get serial to work at all assuming 0 error in the system clock of the partner.
What clock speed are you using 8 Mhz or 6.4 Mhz? I might be able to help you "tweak" the library code to adjust the bit alignment for an error in the clock.
Softwareserial implementation methodology is fairly crude and it's really got some limitations (like not being able to receive when it's sending). It runs with interrupts disabled for 10 bit periods (8 bits+start and stop), causing major interference to ISR routines. Maybe Paul has AltSoftSerial working on the attiny.
afremont:
Softwareserial implementation methodology is fairly crude and it's really got some limitations (like not being able to receive when it's sending). It runs with interrupts disabled for 10 bit periods (8 bits+start and stop), causing major interference to ISR routines. Maybe Paul has AltSoftSerial working on the attiny.
To me it just seems a bad way to do it if the device on the other end of the wire is another microcontroller. Use I2C instead or invent a simple one wire protocol if you only have one pin left.
afremont:
Softwareserial implementation methodology is fairly crude and it's really got some limitations (like not being able to receive when it's sending). It runs with interrupts disabled for 10 bit periods (8 bits+start and stop), causing major interference to ISR routines. Maybe Paul has AltSoftSerial working on the attiny.
To me it just seems a bad way to do it if the device on the other end of the wire is another microcontroller. Use I2C instead or invent a simple one wire protocol if you only have one pin left.
It's a bad way to do serial comms no matter what, especially when it isn't common knowledge that this is the consequence. I'm not knocking the author, I'm just saying that these "aspects" should be clearly documented on the main page for the library. Another big issue is that at 9600 baud and slower it destroys Timer0 interrupts. With say 20% utilization (really a guess, but steady back and forth) of the link at 9600, it missed about 1/3 of the Timer0 interrupts. By that I mean that when the 1024uS Timer0 rollover occurs, 1/3 of the time the ISR never ran before the rollover occurred again causing a missed count. In the exact same comm scenario, AltSoftSerial caused no missed interrupts. It's much more efficient and ISR friendly because it uses the hardware to generate the sent bits right on time. The real problem with AltSoftSerial is that it's only one port and it dictates which pins are used. I've been thinking about seeing if I can fix up the SoftwareSerial library (in my spare time) to use interrupts in some fashion similar to the way the servo library works since you can instantiate more than one SoftwareSerial port. Anyway, I'm sure nobody cares.
Amigone:
afremont - do you have some specific instructions on how to "recalibrate" the clock?
There are three application notes on this page that describe different methods to do it. If you download the zip files and not just the datasheets, there are code examples too.
AVR053, AVR054, AVR055, AVRO57 are the app notes to do it different ways.
EDIT: I really can count, there are actually four that I found.
Seems that I cant use the USI since it is two wire, but my goal is to use wireless transmitter which can send only one.
Have to take a look at TinyISP or calibration.
Amigone:
afremont - do you have some specific instructions on how to "recalibrate" the clock?
a) Put values in the OSCCAL register until you find one that works.
b) Store that value in EEPROM
c) Copy the value from EEPROM to OSCCAL in your setup() function.
In your case you could connect to something known to work at 115200 baud and tweak OSCCAL up/down a bit until it works.
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;
Using Arduino 1.0.1 with AVR tools upgraded to: gcc version 4.3.3 (WinAVR 20100110) It is mandatory to flash a boot loader selected by the board profile to burn the fuses correctly... NO boot loader is installed.
The serial (out) initialization is pretty standard, no #include required for SoftwareSerial:
I've burned several ATtiny85's from Newark and never any issues with clock... however, I am only running 9600BAUD.
I'm am selecting the board file from David ATtiny85 @ 16MHz with internal PLL and 4.3 BOD
Ray
Serial.begin(115200);
char dir = 1;
while (1) {
OSCCAL += dir;
delay(500);
Serial.print("\nThis is SoftwareSerial with OSCCAL=");
Serial.println(OSCCAL);
if (OSCCAL == 0) dir = 1;
if (OSCCAL == 255) dir = -1;
}
Connect it to another device/terminal which is receiving at 115200 baud and let it run...
Go have a cup of tea. When you get back, look at the output and choose a good value for OSCCAL.
The authors of SoftwareSerial would be doing the world (and these forums) a huge favor if they could add a function like this to their library.
Now is a time for a bit of embarrassment. I found the cuplrit. The powersupply! I used cheap ac dc converter with YWRobot breadboard voltage stabilizer. Although I had 1000uF capacitor on breadboard and I checked the voltage with oscillator (as much as my inexperienced mind could). I changed to 7,4V lipo and voila, totally different picture. By default 115200 still gave errors, but running fungus code gave me alot of completely nice lines.
So:
WHEN HAVING PROBLEMS WIHT ATTINY-S DOUBLE CHECK YOU POWERSUPPLY!
Still I need some info. Fungus, in wich format is the OSCCAL? I get some freaky characters printed on screen, how do I interpret that? I cant copypaste that as those characters are not copied
EDIT
I put the OSCCAL into integer and got good value that way, still using the value that works with 115200 does not work with e.g. 2400. Have to debug some more
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"
#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;
}
}
Amigone:
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?
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.
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.
OK, I missed that bit.
Looks to me like the author of SoftwareSerial needs to do a bit of tweaking in his timing code...
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.
