Which core for ATTiny85?

I've been hacking on an ATTiny85 project with some success. started out with the project hub example that points to the damellis/attiny github project. Now I've been struggling with some inconsistency in the use of TIMER0 vs TIMER1 in some discussion here and finally realised that the SpenceKonde/ATTinyCore is different and some of the examples presumed to be using that github project for the core.

For my part I need to take over one of the timers -- and it doesn't matter which one -- and use it to drive a timer interrupt (ideally a compare match). But for debugging I want some code to use "delay()" and "millis()" from time to time, so I'd like to use the other timer for my main design.

At this point I don't really care which core I use. Overall the documentation at SpenceKonde/ATTinyCore looks better, there are more chips supported and the files are all newer. Should I be switching to this core? Are there other cores I should be aware of? Is there a preferred ATTiny85 core amongst those who use this chip commonly? Thanks.

Spense’s core did everything I needed and them some. It is, AFAIK, the only actively maintained and IDE integrated core out there for the tiny series. You’ll find him here posting as DrAzzy. Look for his prototyping boards on Tindie. Good stuff.

I have been using DrAzzy's Core (Attiny Core) quite a lot, mostly with ATtiny 85 and ATtiny2313. It works pretty well for my projects! And I am very happy that this core is actively maintained and that DrAzzy is very active in this forum (Thank you DrAzzy!).

The ATTiny x5 series has two timers. Timer 0, the standard 8 bit timer (used for millis) and timer 1 with "special" capabilities.
As much as I know timer0 is on PB1 and PB0 for output compare, timer1 is on PB4 and PB1 and with inverted outputs on PB3 and PB0.

But in reality, I did never fiddling aroud too much with the timers. Just using the core as it is. :slight_smile:

Thanks guys. I've installed SpenceKonde/ATTinyCore and given it a try. All seems well.

Spence's core has a lot more interesting options in the board menu that the damellis one. If DrAzzy is listenting, it would be useful to know which control the build and which are AVRDude fuse options. I am burning my firmware using a TL-866 and have to do all the fuses myself. So knowing what board options are shorthand for AVRDude fuse settings, versus which are build options would help. I will have to go through the board definition tables to familiarize myself.

Why bother? A $3 USBASP and a 6 pin header and wouldn’t have to bother pulling the chip and running a different program to flash your code (and fuses), all done from within the IDE.

Eesave, clock (not timer1 clock source option), and bod settings are in fuses. The rest isn't

The main point of the timer 1 clock source option, by the way (since i suspect thats the one you were wondering about) is so you can use it with tone on the timer 1 hardware pwm pins to generate higher frequency square waves. If taking over timer1, you can set the clock source to the pll in your code too if you so choose.

I'm using the attiny85 to program addressable leds and I found DrAzzy's core produced larger programs when compiled than damellis' version.

So even though the project is 4+ years old and apparently abandoned, I went with that because it freed up much needed space for additional led animations versus the newer core from DrAzzy.

I was a bit disappointed the newer core had more bloat in it apparently?

blinkydelights:
I'm using the attiny85 to program addressable leds and I found DrAzzy's core produced larger programs when compiled than damellis' version.

So even though the project is 4+ years old and apparently abandoned, I went with that because it freed up much needed space for additional led animations versus the newer core from DrAzzy.

I was a bit disappointed the newer core had more bloat in it apparently?

Did you enable LTO from the tools menu? That should shrink sketch size by 10-20% - I'm looking into why it is defaulting to disabled currently, I plan to make enabled the default (enabled won't work with 1.6.10 of the IDE and earlier, or the version of the official AVR board package that came with those versions of the IDE). The damellis core, iirc, uses LTO if the IDE supports it, because it uses almost everything from the default avr board package (I can't have mine do that because I need a different platform.txt to support the generation of assembler listings, and specification of a the avrdude.conf I supply with the core in order to support the less common ATtiny parts).

I don't think I have added anything that could be causing bloat (in fact, in a few places I've managed to save a few bytes).

If you can show me a sketch that compiles to a significantly smaller size (with LTO enabled) as compares to damellis core, I would consider that a priority bug and would investigate where the bloat was coming from and fix in the next release.

I am very interested in seeing the sketches for which this difference was large enough to be relevant when LTO is enabled.

I made some improvements to digitalWrite() and analogWrite() that should save a bit of space (46 bytes on my test sketch, took it from 798 to 752, vs 770 for damellis core). For further improvements I need to see a sketch that can reproduce the difference in compiled sketch size. These changes will be in 1.2.5 which I'm releasing tonight; this will also enable LTO by default.

1 Like

I apologize but I ended up moving to the GNU AVR toolchain as a research exercise and realized some major reductions in the compiled size on ATtiny85. I believe when I was poking around I used the defaults and it was with a simple blink sketch but it's possible I was using the Adafruit_NeoPixel library which definitely used the millis() function among several others, so that may have contributed to the difference in sketch size.

I've now switched to a different LED library, using the GNU AVR tools, and tweaking optimization, my sketch on the ATtiny85 comes to 712 bytes for a repeating rainbow cycle driving a few hundred ws2812b addressable LEDs. So I'll probably be sticking with that for this project.

It sounds like you've got some warm leads on some optimizations you can make. Thanks for the quick attention.

Thanks for getting back to me.

Yeah, I fixed the discrepancy in size of basic sketches (also made LTO enabled by default), that's in the latest board manager release. If the difference was significant, though, I think it was the LTO.

Next release will include a new tinyNeoPixel builtin library, which is integrated with the core to minimize flash use (comes in two versions, tinyNeoPixel, which implements the full Adafruit_NeoPixel functionality, and tinyNeoPixel_Static, for which you have to statically declare the array to hold the pixels, and you lose the ability to change the length at runtime and have to manually call pinMode(pin,OUTPUT), but in so doing saves yet more flash; if you can replace all pinMode calls with DDRx register writes, the _Static version of the library will not pull pinMode back in for the single call to enable, saving approx 100-some-odd bytes).

I had some trouble to install the latest ATTinyCore in Arduino 1.8.9, following the directions on the GitHub site.

Adding this URL
http://drazzy.com/package_drazzy.com_index.json
to Preferences > Additional boards managers list accomplishes nothing, despite changing the order of entries, restarting the IDE, etc. No additional boards appear in the boards list, and no error messages are emitted either. I have two other entries in that list, for the Pololu Astar boards and MiniCore, which work fine.

Problem solved by manually placing the unzipped file in the sketchbook/hardware directory as instructed.

jremington:
I had some trouble to install the latest ATTinyCore in Arduino 1.8.9, following the directions on the GitHub site.

Adding this URL
http://drazzy.com/package_drazzy.com_index.json
to Preferences > Additional boards managers list accomplishes nothing, despite changing the order of entries, restarting the IDE, etc. No additional boards appear in the boards list, and no error messages are emitted either. I have two other entries in that list, for the Pololu Astar boards and MiniCore, which work fine.

Problem solved by manually placing the unzipped file in the sketchbook/hardware directory as instructed.

Did you go to Tools -> Boards -> Board Manager and install the new board package? You need to do that - it's not sufficient to just put the URL in the preferences, you need to actually use board manager to install it (assuming you're installing through board manager). Though of course this is beside the point since you've now installed manually (you would want to remove it manually before attempting a board manager installation of the same core, if you wanted to do that).

you need to actually use board manager to install

Ahh, I did not realize that step was required, and mistakenly assumed that the IDE was smart enough to install the package automatically, once I gave it the link.

Thanks.

Cools :slight_smile:

And - be glad the IDE doesn't - you'd have a board menu 20 screens long if it did :stuck_out_tongue: