mcnobby:
I think I went through this before trying to set frequency to 9.6mhz, bot sure why I ended up with the first entry but it seems to work fine.
As far as I know low fuse bits 0 & 1 also select internal oscillator and divider.
Is F_CPU only in there as a contant for the compiler ?
F_CPU is a constant used by avr-libc and any Arduino core.
If it is incorrect, all timing and delay functions will be wrong.
And the ADC may be set up incorrectly.
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.
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.
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?
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.
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: