SoftwareSerial with ATTiny84 using ATtiny library

Delete that line (#55) from TinyDebugKnockBang.h ...

After deleting line 55, I get this error:

D:\arduino-1.01\arduino-1.0.1-windows (1)\arduino-1.0.1\libraries\TinyDebugKnockBang/TinyDebugKnockBang.h:152: error: expected ',' or '...' before '*' token

Which core are you using?

I am using smeezekitty's core:

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

The core is missing this...

class __FlashStringHelper;
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

I suggest adding it to WProgram.h.

You may have to also add this to the top...

#include <avr/pgmspace.h>

Thanks,

I added these to the WProgram.h, which gave another error:

D:\arduino-1.01\arduino-1.0.1-windows (1)\arduino-1.0.1\libraries\TinyDebugKnockBang/TinyDebugKnockBang.h:156: error: 'DEC' was not declared in this scope

So I added #include "print.h" in the WProgram.h , and now it compiles and uploads.

When I open the serial monitor (19200 baud) and type a ! I get this error:

--- Knock-Bang fault: 15 ---

I was thinking it maybe had something to do with the clock speed which was 128kHz, so I tried at 9,6 mHz and got this error:

--- Knock-Bang fault: 11 ---
i get the correct respons from the serial monitor, when I use @,# and !

Erni:
So I added #include "print.h" in the WProgram.h , and now it compiles and uploads.

Excellent.

I was thinking it maybe had something to do with the clock speed which was 128kHz,

The minimum supported clock speed is 1 MHz. If I can remember, I'll put a check in the header file.

so I tried at 9,6 mHz and got this error:

--- Knock-Bang fault: 11 ---
i get the correct respons from the serial monitor, when I use @,# and !

fault_timeout_knock ... In the interrupt service routine, a knock was not detected within the time limit.

Other then a wire, is anything connected to MISO?

Try adding a 10K or 4.7K or 1K pullup resistor to MISO. And/or, if the wire on MISO connecting the programmer to the target is longish, try a shorter and/or fatter wire.

Bad news:

I have killed my poor little Attiny13, I think it was during fiddling with the fuses. It is totally unresponsive, I tried my USBasp and Pololu programmer but no luck.
I will report back as soon as my new chips arrive, oh so close ...

There has not been anything connected to MISO during this testing. I will try your tip with pullups.

Thank you for your help so far

Don't give up yet! Two things I've discovered about the t13...

After changing the clock choice (fuses), mine sometimes becomes unresponsive until I toggle power. Try toggling the target's power.

There is a minimum pulse time for RESET. All the processors I've used don't seem to care if the minimum is or is not met. Except the t13. If the pulse is too short, it will reset but refuse to enter programming mode. If you've changed the clock to 128 KHz, the minimum pulse maybe longer than the pulse provided by USBasp or Pololu. I know the minimum pulse is longer than the one provided by ArduinoISP. I just change TinyISP to provide the correct reset pulse for the t13 @ 128 KHz.

Bear in mind I also changed how build options are specified. If you decide to try TinyISP and need help getting it working the way it was just let me know.

Erni:
--- Knock-Bang fault: 11 ---

You are running TinyISP on what board?

Success... ! (almost)

I got a new attiny13 today and tried it with the factory settings, and a very short connection to MISO, and here is the result:

t13 test..
t13 test..
t13 test..
t13 test..
--- Knock-Bang fault: 4 ---
t13 test..
t13 test..
t13 test..
t13 test..
--- Knock-Bang fault: 13 ---
t13 test..
t13 test..

I will try with another cpu-speed setting to see if I can reduce the errors.
Also I will try your updated TinyISP

--- Knock-Bang fault: 11 ---

You are running TinyISP on what board?

I am using Arduino Uno (I think it is R2)

And another success, I was able to get my dead tiny back to live by using this HV-programmer

http://www.rickety.us/2010/03/arduino-avr-high-voltage-serial-programmer/

It seems OK now, atleast it passed the blink test

Update:

At 4,8 mHz it is a total succes, no errors at all.

It works at 4.8 MHz but not at 9.8 MHz?

It also works without errors at 9,6 mHz

It does not work at 1.2 MHz but does work at higher frequencies?

Now I am confused. According to the datasheet (if i read it correct) , the only options are 128kHz, 4,8 mHz and 9,6 mHz. I can see that the factory default is 9,6 mHz (I thought it was 128 kHz)
Another thing that is confusing is the fuse settings I am using. They are mainly copied from the thread about core 13, and I think they maybe are wrong, because I am know in the same situation as yesterday with an unresponding attiny, after I tried to "burn bootloader" 128 kHz.

This is my boards.txt

###########################################################################

attiny13int.name=Attiny13 @ 128 KHz (internal watchdog oscillator)
attiny13int.upload.using=arduino:arduinoisp
attiny13int.bootloader.low_fuses=0x7B
attiny13int.bootloader.high_fuses=0xFF
attiny13int.upload.maximum_size=1024
attiny13int.build.mcu=attiny13
attiny13int.build.f_cpu=128000
attiny13int.build.core=core13

###########################################################################

attiny13at4.name=ATtiny13 @ 4.8MHz (internal 4.8 MHz clock)
attiny13at4.upload.using=arduino:arduinoisp
attiny13at4.bootloader.low_fuses=0x69
attiny13at4.bootloader.high_fuses=0xff
attiny13at4.upload.maximum_size=1024
attiny13at4.build.mcu=attiny13
attiny13at4.build.f_cpu=600000
attiny13at4.build.core=core13
###########################################################################

attiny13at9m.name=ATtiny13 @ 9.6 Mhz
attiny13at9m.bootloader.low_fuses=0x7A
attiny13at9m.bootloader.high_fuses=0xff
attiny13at9m.upload.maximum_size=1024
attiny13at9m.build.mcu=attiny13
attiny13at9m.build.f_cpu=9600000
attiny13at9m.build.core=core13

###########################################################################

Erni:
According to the datasheet (if i read it correct) , the only options are 128kHz, 4,8 mHz and 9,6 mHz.

Divide by 8 is also an option.

I can see that the factory default is 9,6 mHz (I thought it was 128 kHz)

Divided by 8. (1.2 MHz)

They are mainly copied from the thread about core 13, and I think they maybe are wrong, because I am know in the same situation as yesterday with an unresponding attiny, after I tried to "burn bootloader" 128 kHz.

attiny13int.bootloader.low_fuses=0x7B
attiny13int.bootloader.high_fuses=0xFF

Yeah, that looks suspicious. I think mine are 0x33 and 0xFF. One moment... AVR® Fuse Calculator – The Engbedded Blog ... 0x33 and 0xFF will definitely work. 0x7B and 0xFF will also work. The differences are start-up time and EEPROM save.

Bear in mind what I wrote earlier about the RESET pulse time. The symptoms you've described exactly match the ones I had.

Bear in mind what I wrote earlier about the RESET pulse time

Oh yes, sorry I got a little overexcited because it worked (to a certain point) !
So now I use your changed TinyISP, and now I can change fuses without problems. No need for HV programmer as I thought.

Thank you Coding Badly for this update

The funny thing is that Knockbang only works at some clock frequences

0x69 0xFF 4,8mhz /div8 ok
0x79 0xff 4,8mHz Knockbbang error 15
0x7A 0xFF 9,6mHz ok
0x6A 0xFF 9,6mHz /div8 Knockbang error 11
0x6A 0xFF 9,6mHz /div8 Knockbang error 11
0x62 0xFF 9,6mHz /div8 Knockbang error 11
0x66 0xFF 9,6mHz /div8 Knockbang error 11

Erni:
So now I use your changed TinyISP, and now I can change fuses without problems. No need for HV programmer as I thought.

Excellent.

0x69 0xFF 4,8mhz /div8 ok
0x79 0xff 4,8mHz Knockbbang error 15
0x7A 0xFF 9,6mHz ok
0x6A 0xFF 9,6mHz /div8 Knockbang error 11
0x6A 0xFF 9,6mHz /div8 Knockbang error 11
0x62 0xFF 9,6mHz /div8 Knockbang error 11
0x66 0xFF 9,6mHz /div8 Knockbang error 11

Wow. Everything about that list is bizarre. Does any of the data arrive in the error 15 case?

What's the goal? Are you helping to make Knock-Bang more reliable? Or do you just need to get it working so you can move on with your project?

One thing I've noticed about this core is the timing of the delay function is unaccurate, and especially at the frequencies where KnockBang gives error messages

In the blink sketch with 1 second delay I get:

X66 0xFF -> 10 seconds
x7a 0xFF-> 1.3 seconds
x69 0xFF-> 1.5 seconds
x79 0xFF-> 0.3 seconds

I do not know how or if this affects KnockBang

Does any of the data arrive in the error 15 case?

No nothing but the error message

What's the goal? Are you helping to make Knock-Bang more reliable? Or do you just need to get it working so you can move on with your project?

I would like to help with your KnockBang, but my lack of programming skills, does that I will be more trouble than help.
Thank you for the help, I am sure that others can benefit from it also.

Erni:
One thing I've noticed about this core is the timing of the delay function is unaccurate, and especially at the frequencies where KnockBang gives error messages ... I do not know how or if this affects KnockBang

Excellent observation. If delay is wrong because the F_CPU value is wrong than Knock-Bang would most definitely not function correctly. Please post your boards.txt file with the other entries (or ensure the F_CPU entries are correct).

I would like to help with your KnockBang...

Including 128 KHz, which clock speed is your highest priority?

Other than 128 KHz, which clock speed is your highest priority?