core13: An Arduino core for the Attiny13 *testers wanted*

hi!

analogWrite makes 4 KHz output frequency.

Is it possible to make it approx 10 times smaller? e.g. 400-800 Hz

Thanks!

Winnie_The_Pooh: hi!

analogWrite makes 4 KHz output frequency.

Is it possible to make it approx 10 times smaller? e.g. 400-800 Hz

Thanks!

I'm curious why? To be honest, I have never actually measured the frequency.

You could lower the microcontroller clock which would no doubt slow down the PWM rate

I'm using PWM to dim LED driver. Manual says that pwm frequency should be lower than 1000 Hz.

Lowering the clock is a little bit brute :)

May be I can play with divider here:

void analogWrite(uint8_t pin, uint8_t val){

24 if(pin == 0){ 25 TCCR0A |= (1 << COM0A1); 26 OCR0A = (val / 16) * 16;

Changing COM0A1 to COM0A2 will encrease the divider to 8. I think so :)

Any side effects?

Winnie_The_Pooh: I'm using PWM to dim LED driver. Manual says that pwm frequency should be lower than 1000 Hz.

Lowering the clock is a little bit brute :)

May be I can play with divider here:

void analogWrite(uint8_t pin, uint8_t val){

24 if(pin == 0){ 25 TCCR0A |= (1 << COM0A1); 26 OCR0A = (val / 16) * 16;

Changing COM0A1 to COM0A2 will encrease the divider to 8. I think so :)

Any side effects?

It should be okay. Just toss this

(val / 16) * 16

and make it just "val"

That was part of testing code that has since been removed. Newer versions fixed it

Hi!

Check the attiny13 manual and find out that PWM freq can be set by the last 3 bits of TCCR0B register.

Use that code in setup section:

/* 
Setting Divisor Frequency PWM on 9.6, 4.8, 1.2 MHz CPU 
  0x01 divisor is 1      37500, 18750, 4687 Hz 
  0x02 divisor is 8      4687, 2344, 586 Hz 
  0x03 divisor is 64     586, 293, 73 Hz 
  0x04 divisor is 256    146, 73, 18 Hz 
  0x05 divisor is 1024   36, 17, 5 Hz 
  */ 

 TCCR0B = TCCR0B & 0b11111000 | 0x02; // 0x02 divisor is 8   586 Hz

Measured real frequency is 555 Hz.

The question is - does this influence delay() function? Will test this in a near future :)

I believe the timer-counter is derived from the main CPU clock via the prescaler, so changing the timer-counter prescaler should not affect the main clock.

Since the delay functions are based on counting clock cycles, they should remain tied to F_CPU. (So long as F_CPU is defined correctly in your boards.txt file and you’ve burned the fuses accordingly.)

However, the millis and micros functions are based on counting timer-counter overflows, and this will be affected by changing the prescaler.

Also note that there are two PWM modes, fast and phase correct. The core files set fast mode by default. If you switch to phase-correct [TCCR0A = _BV(WGM00);] the frequency is halved. (Actually 256/510.)

Actual output frequencies will not be exactly as listed in the ATtiny13a manual. 10% slower is not uncommon. If you need an exact frequency output, you’ll need an external clock.

kosine: However, the millis and micros functions are based on counting timer-counter overflows, and this will be affected by changing the prescaler.

Also note that there are two PWM modes, fast and phase correct. The core files set fast mode by default. If you switch to phase-correct [TCCR0A = _BV(WGM00);] the frequency is halved. (Actually 256/510.)

Actual output frequencies will not be exactly as listed in the ATtiny13a manual. 10% slower is not uncommon. If you need an exact frequency output, you'll need an external clock.

Check out what I did to improve delayMicroseconds() It is a hybrid of your code and my original code (your code bombed at low clock speeds)

Its a little bigger but it is the most accurate I could make it over a wide range of clock speeds and delay lengths.

I noticed the update to wiring.c in your latest v20, but haven't had chance to play around with it yet. Will try and find some time soon.

I've also been meaning to have a look at using CLKPR as a runtime reference instead of F_CPU during compilation. Would be nice to switch speeds on-the-fly and still retain some timing functionality, at least in ms.

With a 256 prescaler (37.5kHz) each clock cycle is 26.66us, so an ASM loop using 38 clocks would return after 1013.33us, which is close enough given the chip tolerances. Repeating the loop 256/CLKPR times would give the same 1ms regardless of operating frequency. (9 to choose from and no fuses to worry about!)

Seems fairly simple if using the internal 9.6MHz oscillator, and not much more complex with an external clock. (Adjust for that with F_CPU at compile time.)

Downside is that it's not going to work with us delays, but millis() and micros() might be possible with some work. The upside is that it would offer a lot of different PWM frequencies (20 I think) from 37.5kHz right down to 0.07Hz.

I've also been meaning to have a look at using CLKPR as a runtime reference instead of F_CPU during compilation. Would be nice to switch speeds on-the-fly and still retain some timing functionality, at least in ms.

With a 256 prescaler (37.5kHz) each clock cycle is 26.66us, so an ASM loop using 38 clocks would return after 1013.33us, which is close enough given the chip tolerances. Repeating the loop 256/CLKPR times would give the same 1ms regardless of operating frequency. (9 to choose from and no fuses to worry about!)

Seems fairly simple if using the internal 9.6MHz oscillator, and not much more complex with an external clock. (Adjust for that with F_CPU at compile time.)

Downside is that it's not going to work with us delays, but millis() and micros() might be possible with some work. The upside is that it would offer a lot of different PWM frequencies (20 I think) from 37.5kHz right down to 0.07Hz

To be honest, I don't think I would implement that in the main core distribution. Arduino doesn't implement it and I am trying to avoid bloat.

Thanks every one for the help. I was able to use the attiny13a as a RGB fader. I used the raw avr libraries from

GitHub - cpldcpu/light_ws2812: Light weight library to control WS2811/WS2812 based LEDS and LED Strings for 8-Bit AVR microcontrollers. as suggested by this forum. Next i’ll use some pot to control each color value individually. Once complete will share the details here.

I was creating ATtiny13 library install for Arduino IDE 1.6.0 ( from smeezekitty library ), just extract in sketchbook/hardware folder.
It has some new feature like change GCC Optimisation flags from IDE directly. I added -O1 flag because with new compiler in some cases can produce smaller .hex file ( must do some experimenting )

This is the boards i include ( you can change it from board.txt )

and burn Bootloader ( only use to change fuse settings, no real bootloader ) works fine from IDE.

tiny13_for_1.6.0_IDE.zip (42.6 KB)

Tanks for this share :grin: :grin: :grin:

common_ground:

Thank you very much for IDE 1.6.0 version, works out of the box, which is helpful for beginners like myself. However, a strange recurring feature for all my atmega chips - if I try to burn the bootloader first (only fuses, I know, I know), it fails with some out-of-sync or something. Uploading the blink sketch works (though the sketch produces longer blick delays). Burning the bootloader-fuses after that - works, and the uploading the blick sketch again works perfectly as expected. I encountered that while programing the atmega328 chip and thought i made a mistake somewhere. But now it repeated again with your compilation for attiny13! Am I missing something?

grigorym: However, a strange recurring feature for all my atmega chips

I'm not sure i understand you completely. This installation is only for ATtiny13 and has nothing to do with atmega mcu (they use a settings that is in a different location). Can you explain it more clearly. What programmer you use? If you use USBTinyISP then maybe flash timing is problem and here you have a solution for this: ATTiny flash timing problem

I use Arduino as ISP and USBTinyISP and it works well with both.

common_ground: I'm not sure i understand you completely. This installation is only for ATtiny13 and has nothing to do with atmega mcu (they use a settings that is in a different location). Can you explain it more clearly. What programmer you use?

  1. I am using Arduino as ISP (using Nano board). Only the wierd behaviour (having to upload sketch first, and only then setting the fuses worked) on ATtiny13 matched the one I noticed on 328, so I mentioned it here.

  2. Are you sure your configuration option "attiny13.name=Attiny13 @ 128 KHz (internal watchdog oscillator)" works as expected? In my case IDE says it is missing "upload.tool=arduino:avrdude" and ".bootloader.tool=arduino:avrdude". However, having added those I must have locked my ATtiny13, it does not respond anymore.

P.S. May I take some more time to read the whole thread? :) I definitely must not be the only one to try this 128KHz option :)

grigorym: 2. Are you sure your configuration option "attiny13.name=Attiny13 @ 128 KHz (internal watchdog oscillator)" works as expected? In my case IDE says it is missing "upload.tool=arduino:avrdude" and ".bootloader.tool=arduino:avrdude". However, having added those I must have locked my ATtiny13, it does not respond anymore.

128 KHz option was just copied from a previous settings and I did not adjust it for 1.6.x, and it can not be used with a standard Arduino as ISP , as a rookie you should avoid using internal watchdog oscillator , I'm sorry i have not been thinking, this option had to be deleted, and who knows how to use it, can easily be set manually. If you tried, it means your ATtiny13 is locked and here you have a good procedure how to unlock :reset-clock-fuse-bits on ATTiny13, i tried this procedure, works well and it's easy to use, only instead

avrdude -p attiny13 -P usb -c usbtiny -tuF

you should put

avrdude -p attiny13 -P usb -c arduino -tuF

But others fuse settings should work with Arduino as ISP without problems , i just tried them all again.

grigorym: 2. Are you sure your configuration option "attiny13.name=Attiny13 @ 128 KHz (internal watchdog oscillator)" works as expected? In my case IDE says it is missing "upload.tool=arduino:avrdude" and ".bootloader.tool=arduino:avrdude". However, having added those I must have locked my ATtiny13, it does not respond anymore.

P.S. May I take some more time to read the whole thread? :) I definitely must not be the only one to try this 128KHz option :)

I've used the 128KHz many times. The issue here is the tiny13 cpu clock is too slow for some ISP programmers SCK clock speeds.

In order to program at these very low speeds is you need an ISP programmer that will support the Bitclock rate adjustment from avrdude -B option. There are several programmers that will support this option, AVRispMKII, USBtinyISP(some versions may not work correctly), and USBASP(new firmware versions). I've even add my own 16KHz clock rate option that works with this bitclock rate adjustment.

ArduinoasISP will not work at these very slow speeds.

For avrdude -B option, you should specify at least -B50.

To program via the IDE, then you will need to change the Global defaults in the avrdude.conf file. Some where around line 335:

#
# Overall avrdude defaults; suitable for ~/.avrduderc
#
default_parallel   = "lpt1";
default_serial     = "com1";
# default_bitclock = 2.5;
default_bitclock = 50;

hiduino: ArduinoasISP will not work at these very slow speeds.

As I have no other programmer, but Arduino Nano as ArduinoISP, does that mean I technically can not repair that 128KHz issue?

grigorym: As I have no other programmer, but Arduino Nano as ArduinoISP, does that mean I technically can not repair that 128KHz issue?

Try Arduino ISP with boot-time selectable slow SPI

It may help, but I have not tested it.

common_ground: Try Arduino ISP with boot-time selectable slow SPI

Tried already, no luck. Both burning bootloader and trying to upload says: "avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature."