Go Down

Topic: core13: An Arduino core for the Attiny13 *testers wanted* (Read 156835 times) previous topic - next topic

Winnie_The_Pooh

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:

Code: [Select]

/*
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 :)

kosine

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.

smeezekitty

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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

kosine

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.


smeezekitty

Quote
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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

sudhirkhamari

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

https://github.com/cpldcpu/light_ws2812 as suggested by this forum. Next i'll use some pot to control each color value individually. Once complete will share the details here.

common_ground

#321
Feb 17, 2015, 07:00 pm Last Edit: Feb 18, 2015, 12:08 am by common_ground
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.

pierrotm777


grigorym

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?

common_ground

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.

grigorym

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 :)

common_ground

#326
Mar 27, 2015, 11:02 am Last Edit: Mar 27, 2015, 04:54 pm by common_ground
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
Quote
avrdude -p attiny13 -P usb -c usbtiny -tuF
you should put
Quote
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.

hiduino

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:
Code: [Select]

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

grigorym

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?

common_ground

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.

Go Up