next topic »

[on:]

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" http://code.google.com/p/arduino-tiny/ 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

Code:

// 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.

Code:

ÿºÿir iv b lnt ~ú tfxt fnr ynu

[Reply #1 on:]

Is it actually possible to get the software serial to work on attiny45 without an external crystal or not?

Sure. The internal clocks have calibration.

OTOH...given the amount of google hits saying "softwareserial doesn't work" I think it's a safe bet it causes problems.

PS: I do need softwareserial as I need to make two attinys communicate (one way only actually)

"need"?

ATtinys have a built-in interface designed for talking to other ATtiny chips. Find out about "USI".

SoftwareSerial is a last resort, use it only when the other device has nothing but a serial port.

[Reply #2 on:]

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.

[Reply #3 on:]

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.

[Reply #4 on:]

http://playground.arduino.cc/Code/USIi2c - this seems to be more usable indeed, although, for a beginner like me, a bit more complex.

afremont - do you have some specific instructions on how to "recalibrate" the clock?

[Reply #5 on:]

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.  

[Reply #6 on:]

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.
http://www.atmel.com/devices/attiny45.aspx?tab=documents

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.

[Reply #7 on:]

Amigone

You could try the TinyTuner, to calibrate the internal clock

http://arduino.cc/forum/index.php/topic,8553.0.html

I know there was a lot of trouble with SoftwareSerial in earlier versions, but after version 1.01, I have not had any problems.

Maybe I am just lucky, ore maybe it is because I don't use it often, after I discovered Coding Badly's TinyISP.

http://arduino.cc/forum/index.php/topic,123388.30.html

[Reply #8 on:]

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.

[Reply #9 on:]

If you are going to use the small cheap tx/rx you get on Ebay, I would suggest you use
the manchester encoding library.

Maybe you could use VirtualWire (I don't know if that can be used with the Tiny's)

[Reply #10 on:]

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.

[Reply #11 on:]

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/

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:

Code:

  Serial.begin(9600);

and the output is standard, as shown here:

Code:

 if (Fast) {
      WPM = 25;
      Serial.print(F("Magic Morse - ATtiny85 v.10 WPM > 25"));
    } else {
      // WPM = 18;
      Serial.print(F("Magic Morse - ATtiny85 v.10 WPM < 25"));
    }

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

[Reply #12 on:]

What happens if you do this?

Code:

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.

[Reply #13 on:]

EDIT

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

[Reply #14 on:]

By default 115200 still gave errors, but running fungus code gave me alot of completely nice lines.

That code actually worked? Cool.

EDIT
I put the OSCCAL into integer and got good value that way

Yes, that would do it:

Code:

Serial.println(int(OSCCAL));