@jasoncoon , I just noticed that this never made it to the master branch. I got some errors when I tried the latest FastLED libraries and noticed some code is missing. After replacing fastpin_avr.h with my old version it ran just fine.

If you rebase this on master I'll accept this PR if it's still relevant

Would be great if someone could rework this and add the series 2 chips while their at it

@zackees I've resolved the conflicts in the README against the master branch, no code conflicts.

The CI checks are failing with a missing file . src/platforms/esp/32/led_strip/led_strip_rmt_dev_idf4.cpp:13:10: fatal error: esp_idf_version.h: No such file or directory.

Sorry about that, i fixed my oopsie. If you rebase it should work.

I rebased and pushed a new PR.

Feel free to copy if you'd like a contributor badge. If no response then my PR goes in tomorrow at noon.

#1717

Thank you for your stellar contribution to this library. I'll be making a build badge tomorrow to memorialize support in FastLED.

Actually i think you can just git merge master.

Thanks so much! Check out release_notes.md and feel free to issue a pull request if you thinks something should be added that people should know about your addition.

I did a shallow dive on the attiny0/1 and it looks like there are quite a lot of chips in this low cost family!

I put up a tester for attiny85, take a look
at the builder and tell me if there's another platform we should have a status badge for.

Attiny85 test results:

Surprisingly, all tests passed besides NoisyPlayground.ino. So i had to defer this test
out

All the credit goes to Dan on that small binary size.

I'll put in a compiled size test too and make sure that there aren't regressions in compiled binary size. Literally if someone includes iostream you guys are toast. And if that happens, a build badge will go red. Look for it in the compiled binary sizes section.

Hi @zackees , thanks for maintaining this repository and merging the changes. I created #1718 to acknowledge credits to the main contributor for ATtiny, @jasoncoon .

Longer story for this contribution:

• I do not have access to any attiny board. In fact, this PR was a by-product when I worked on ATmega ATMega4809 support? #858.

About the library maintanence:

• Thankful for your continuous work on the small binary size validation. Thanks for calling out the iostream issue, there are a lot more for me to learn 😃 .
• in memories of Dan's fantastic work. 🎖️

@freemovers would you able to help in validating if your reported errors resolved with the codes in master branch? Or release 3.7.8 when it's out. Thanks!

@jasoncoon , I just noticed that this never made it to the master branch. I got some errors when I tried the latest FastLED libraries and noticed some code is missing. After replacing fastpin_avr.h with my old version it ran just fine.

It compiles fine again for addressable LEDs with clock lines, thank you for that.
For the clockless version I get the error:

C:\Users\SANDER~1\AppData\Local\Temp\ccIidwAT.ltrans0.ltrans.o: In function `L_5303':
<artificial>:(.text+0xc54): undefined reference to `timer_millis'
<artificial>:(.text+0xc58): undefined reference to `timer_millis'
<artificial>:(.text+0xc5c): undefined reference to `timer_millis'
<artificial>:(.text+0xc60): undefined reference to `timer_millis'
<artificial>:(.text+0xc70): undefined reference to `timer_millis'
C:\Users\SANDER~1\AppData\Local\Temp\ccIidwAT.ltrans0.ltrans.o:<artificial>:(.text+0xc74): more undefined references to `timer_millis' follow
collect2.exe: error: ld returned 1 exit status

That issue was already there when I made the changes, but was never able to figure out where the timer_millis were defined.

I asked ai and it suggested this definition, i'm not going to use it because who knows if it actually works and is not a hallucination. But the important thing is that it looks like on some avr platforms its timer0_millis. I think this might solve your issue. Check out this suggested AI replacement and see if timer0_millis or some variation of that works for your platform.

extern "C" {
#  if defined(CORE_TEENSY) || defined(TEENSYDUINO)
extern volatile unsigned long timer0_millis_count;
#    define MS_COUNTER timer0_millis_count
#  elif defined(ATTINY_CORE)
extern volatile unsigned long millis_timer_millis;
#    define MS_COUNTER millis_timer_millis
#  elif defined(__AVR_ATtinyxy7__) || defined(__AVR_ATtinyxy6__) || defined(__AVR_ATtinyxy4__) || defined(__AVR_ATtinyxy2__)
extern volatile unsigned long timer_millis;
#    define MS_COUNTER timer_millis
#  elif defined(__AVR_ATmega4809__)
extern volatile unsigned long timer_millis;
#    define MS_COUNTER timer_millis
#  elif defined(__AVR_ATmega328P__) || defined(__AVR_ATmega168__) || defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega2560__)
extern volatile unsigned long timer0_millis;
#    define MS_COUNTER timer0_millis
#  elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega1284__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega64__) || defined(__AVR_ATmega128__)
extern volatile unsigned long timer0_millis;
#    define MS_COUNTER timer0_millis
#  else
extern volatile unsigned long timer_millis;
#    define MS_COUNTER timer_millis
#  endif
};

@freemovers just to confirm, the clockless version is having the error ? Are you able to locate the reletive examples for similar failure ? https://github.com/FASTLED/FastLED/tree/master/examples

I think the possible cause is around these few lines, the confusion between ATTINY_CORE and __AVR_ATtinyxy7__. The codes originated from the commit 7d9a8e18 on the master branch.
https://github.com/ngyl88-arduino/FastLED/blob/f8a0a16aa41684f620affc47f1788581d797ba46/src/platforms/avr/led_sysdefs_avr.h#L46-L51

Since this PR has already merged, I think you might be able to help with a new issue and/or PR .

@freemovers yeah, what's the board you are using where you are getting this error linking error against the timer? I just did a test with a generic ATmega4809 board and it worked fine.

I think it's one of the ATtiny boards, since @freemovers started PR 1061.

How about running a clockless examples on Attiny85 ?

Running or compiling? The Attiny85 has a build badge and it's compiling both clocked and clockless controllers. We don't do run tests though.

I did discover that the attiny13 board is not compiling right.

I'm testing with the ATtiny1616, using the megaTinyCore from SpenceKonde, and yes, it is the clockless version throwing that error (using the DemoReel100). I tried all different timers before, but none worked. I just don't understand where that timer is defined. My guess it is expected in FastLED defined by the core already, and the megaTinyCore might define it totally different.

FYI

I'll take a look at the ATtiny1616 board

Btw you can test any board by using the compile command at the root of the project. The arg you pass in will be the same as this

So in this case it will be

./compile ATtiny1616

And I was just using the DemoReel100 example

Btw you can test any board by using the compile command at the root of the project. The arg you pass in will be the same as this

I'm not using platform IO but Arduino instead.

Don't use arduino ide - it's the worst.

Use our build system, it's much better and dumps the build info of the thing you are trying to build:

Bad news see that MILLIS_USE_TIMERD0 in the build_info.json? I think that means there isn't a standard timer, you need to implement one for this case when you see this define

This source file gives a clue on whats going on, see comment:

https://github.com/SpenceKonde/DxCore/blob/master/megaavr/cores/dxcore/wiring.c

Ahh... looks like we have wiring.cpp in our repo so it looks like this just ins't being defined for your platform...

Nevermind, wiring.cpp is compiled out.

Yeah I'm more convinced that the attiny libs are stealing timer_millis out of the wiring.cpp file.

This one has a pretty good write up on how to define it.

https://blog.rahix.de/005-avr-hal-millis/