search

sonyhome / FAB_LED

Fast Arduino Bitbang LED library supports programmable LEDs (WS2812B, APA102...), color palettes for Arduino AVR
GNU General Public License v2.0
126 stars 16 forks source link

No support for post-2016 AVR parts (PR #35 will fix this) #36

Closed SpenceKonde closed 3 years ago

SpenceKonde commented 3 years ago

I submitted a PR several months ago which adds support for what Arduino calls the "megaavr" architecture, including the Uno Wifi Rev. 2, Nano Every, numerous third party boards, and at least one upcoming official board as well. (this covers the megaAVR 0-series, tinyAVR 0, 1, and 2-series, the current flagship 8-bit parts in the AVR DA and DB-series, as well as the upcoming AVR DD-series low-pincount parts and upcoming AVR EA series (the first full-size parts with the fancy ADC the 2-series has). Since 2016, all AVR devices released have been of this architecture, and all new AVR products for the foreseeable future will be as well. With the tinyAVR range reaching down into 2k and 4k, (and the 8-pin parts limited to 4k) there's a good deal of interest in non-buffered libraries (my adaptation of Adafruit Neopixel doesn't cut it on those parts)

Thanks to your clear comments and the similarity between modern and classic AVRs, adding support for the new architecture was straightforward, and it's been tested by the person who originally reported the issue to me. Is there any chance of getting #35 merged?

Thanks

sonyhome commented 3 years ago

Sorry about the delay!

I have not actively been working on FAB_LED and for some reason did not see the PR in my emails. It got pulled in.

I would like to revisit this library at some point to do a full cleanup and use an oscilloscope to optimize the code more but I'm just too busy with many other projects.

sonyhome commented 3 years ago

PR35 accepted.

SpenceKonde commented 3 years ago

Thanks for merging! I've updated the library compatibility page for my cores accordingly :-)

I hear you on being too busy with projects - that's where I am generally too.

If/when you revisit this: The AVRxt parts ("megaavr" in arduino parlance - which is terrible nomenclature because Atmel/Microchip uses "megaAVR" to refer to all AVR devices with ATmega in the name - so there are "megaavr" parts that aren't "megaAVR" and vise versa) should behave identically to classical AVRe/AVRe+ parts, except that: SBI and CBI take a single clock instead of 2, PUSH, CALL, RCALL (and anything else I'm forgetting that ends up pushing something onto the stack) take 1 cycle less, ST is single clock, and LDS takes 3 clocks instead of 2 - so generalizing between the two is straightforward, and you can test for them by checking __AVR_ARCH__ >= 102 (102 is 64k, 104 is 128k, and 103 is 48k or less, and you can use SBI/CBI/SBIC/SBIS on the VPORT registers to get single cycle access to the pins, writing to a bit in VPORTx.IN toggles the pin, and if/when they introduce a part with more than 56 I/O pins, it;s gonna be a shitshow like on the ATmega2560, because there won't be any space for each port to have it's own set of VPORT registers in the low I/O space) And I think that's all you'd need to know about these parts >.>

sonyhome commented 3 years ago

Haha! Thank you for the details.

I had a lot of plans for this library as I wanted to do 2D mapping of surfaces to make screens with it but my prototype code disappeared when someone spilled beer on my laptop at a party, which discouraged me and I never recoded it. Then like I said I got pulled into project after project and FAB_LED was good enough as-is for my uses to do art.

If I tackle a larger art project I'll port to ARM/ESP, etc.