Programming a ATtiny85 with a Morsecode sketch - failure

Hi folks

after working through some tutorials, I went over to try out a little project and program an ATtiny85

My goal: A LED should blink a set morse code.

I used the Morse library (Arduino Playground - Morse) and the following script.

The script compiles and shows no problems after uploading to the ATTiny.
The LED starts blinking correctly, but after a certain time starts blinking in a constant frequency.

Pin on the ATtiny85:

VCC(+) -> +5V
Pin0 (PWM, AREF, MOSI) -> LED Anode (with resistor)
(-) GND -> GND (LED Kathode)

Here is the scipt:

#include <Morse.h>

// Author Erik Linder
// Released 2011 under GNU GPLv3
// Usage: morse( <pin number>, <speed WPM>, <1=beep, 0=PTT> )
//        sendmsg( "<text-to-send>" )

Morse morse(0, 12, 0);

void setup()

void loop()
  morse.sendmsg("Ich teste meinen ATtiny mit dem Arduino");
  delay (2000);
  morse.sendmsg("eins zwei drei vier fuenf sechs sieben");
  delay (4000);

Any ideas what I did wrong?

Greetings from Germany

Did you put a 10kohm resitor from reset tp Vcc.
Also a 100nF cap from Vcc to Gnd is a good idea


I tried that but I get the same result.
I stopped the time: The blinking always starts at the same time (in this case 75 sec)

What I found out is, that if I use less characters (Like SOS or 12345), the program does run through.

Any other ideas?



im NOT a very experienced C programmer or nothing. But i recently checked that "library" you mentioned. It seems this "library" is a pretty bad example of how a library should not be. Since its broken and needs a lot of fixing first before it can be used properly.

it seems not to be working "out of the box" with Arduino IDE 1.01. Seems youll need to add

#if defined(ARDUINO) && ARDUINO >= 100
#include “Arduino.h”
#include “WProgram.h”

to it to have it compile properly in the latest IDE.

it seems it does not support the arduinos "tone()" function. As far i can tell it requires an "pwm" Pin to put out any "audio" or beeping using the default 500hz PWM at 50% duty cycle. pretty ugly if you ask me.

The "Usage" documentation that is included in the source code is outdated and does not include the complete parameter requirements.

the sendmsg() function seemed to require a pointer (?) or memory adress where it can find the string. So im not sure it can just take in a "string" like in your demo.

To me this does not look like a good choice for a morse library. At least none that is supposed to work out of the box.

Furthermore it doesn't send the right morsekode:

instead of a ( ._) it sends b (- . . ) that can be corected by change this line

  _i = ((byte) c) - 33;

to this:

  _i = ((byte) c) - 34;

But then again it sends different morsecode for d and D ... and so on
Maybe the problems you see is a memory issue, I just tried it on a UNO it kept on running for atleast 10 minutes

I haven't figured out why it is going wrong yet but it doesn't handle lower case letters correctly.
I have a workaround. Change this line at the end of Morse.cpp:


to this:


which forces it to deal only with upper case.
If you do this, you can remove all the lower case letters from the _morsetab table because it will never use them and it'll save a bit of SRAM.


hi there,

yes, i did some more experimenting too and patched that so called "library" too. also figgured that lowercase problem lately since it works with numbers and if called with a decimal value instead of a "charakter".

that toupper(*str++) patch looks nice in simple! i love it.

ill add that to my version and re-submit it to the developer.

but even we now managed it to work, to me this "library" is a shame. a user, especialy an arduino user is not supposed to "fix a library first" before first use.

thats up to hackers, coders and admins :slight_smile:

in my version i replaced the requirement of a PWM Pin for speaker output with the tone() function. is already send to the author.

hopefully he will add all the stuff we commited soon.


Found it.
My previous fix isn't required unless you want to save some SRAM but the problem was this line in _morsetab:

    1,   //ASCII 92 \

The backslash at the end of the line is treated as a line continuation, so the comment is continued to include (and therefore remove) the next line. This has the effect of removing one element from the table and so 'a' will be indexed into 'b', 'b' into 'c' etc.

Just change that line to:

    1,   //ASCII 92 '\'


I’ve made one change to the code. Instead of putting “toupper” in sendmsg, I have put it in send() so it will work whether you send a string or a single character. I’ve also removed the lower case chars from the table.

I’ve attached a zip of morse.cpp and morse.h with my fixes.

Pete (2.19 KB)

You are awesome. It works. Thanks a lot.
I will see if I can get a piezo beeper running.

Thanks again

Hi again,

I downloaded the corrected files from Axel Werner and played arround getting the beeper work. When uploading the script to the arduino everything works fine (beeping) but when upoading the sketch to the ATtiny85 I get the errormessage:

Expected signature for ATtiny85 is 1E 93 0B
         Double check chip, or use -F to override this

How is that?


I am not sure what went wrong there, but I can confirm that the files el_supremo suplied, works fine on my attiny85.
BTW it has morsed more than half an hour now


Expected signature for ATtiny85 is 1E 93 0B

Double check chip, or use -F to override this

How is that?

im no expert. but to me this sounds like a problem with the programmer tool itself. something like the programmer would expect a different chip to programm, say an arduino micro and found something different, to it blocks n warns.

have you tried to switch the "board type" or cpu type in your programmers app to a matching one?

best wishes

Ok, I got it to work. The solution was to unplug the piezzo beeper while uploading to the attiny85.
Thanks for all your help.

Ok, I got it to work. The solution was to unplug the piezzo beeper while uploading to the attiny85.

better dont use the UART rx/tx pins. at least while using them for programming.