Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/FastLED/FastLED.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-03Underscore was missingGreg Mathews
This was causing it to not compile on the Adafruit Feather nRF52840 Express for me.
2019-08-26Should fix the build error in #873Dan Garcia
2019-08-26Fix #865 - use the atmega1284/644 definitions for atmega32 as wellDaniel Garcia
2019-08-26Defpin cleanup (#866)Daniel Garcia
* Bring fastpin_avr in line with standard defpin macros (to simplify porting document notes * checkpoint - bring all the arm and esp platforms in line w/defpin macro naming/ordering * checkpoint - update PORTING.md to include information around just adding pin definitions if needed * Kick all the pin definitions to allow for some runtime querying of ports and tweak pintest to have it provide pin definitions for platforms that have port definitions but might be missing pin specifics (e.g. not yet-supported avr platforms
2019-08-19Fix #868 for Teensy LCDaniel Garcia
2019-08-19Improvements to RMT driver (#867)Sam Guyer
* Support for ESP32 Credit to Rina Shkrabova for the first cut. * Clean up interrupt handling I think there was actually an error in the interrupt enabling/disabling, but I also cleaned it up so that it is more clear how interrupts are handled. * Better interrupt handling * Added RMT version Not fully portable yet, though. The timing numbers are hard-wired for WS2812, and the RMT channel is also hard-wired. * Fixed the timing Timing is now computed from T1, T2, amd T3 instead of being hard-wired. * Better buffer management The RMT signal is sent in 10-pixel chunks, using double-buffering to hide the latency when possible. Also: assign RMT channels sequentially. * Total rewrite using Martin's code * Better comments * Fixed the timing calculation We were not doing the conversion from ESP32 cycles to RMT cycles correctly. Now it all works! * Added Martin's changes * Removed confusing comments * Added my name! * Fixed ESP32 compile problem On ESP platforms the dev kit provides the function __cxa_pure_virtual, so there is no need to define it. * honor WAIT_TIME for chipsets that need it (for example TM1829) * Better interrupt handling Suggested by @h3ndrik : allocated the interrupt once at the initialization and then just turn it on and off. This is the strategy that the ESP32 core uses also. * Major refactoring Two major changes to the RMT driver. First, I realized that we can have only one interrupt handler attached to the RMT peripheral, so it needs to be able to handle all of the attached strips. To accomplish this, I store each ClocklessController in an array indexed by its RMT channel. The interrupt handler can then take the channel that triggered it and index into the array to get the right controller. The second major change is that I replaced all of the explicit bit twiddling of the RMT configurartion with calls to the proper functions in ESP32 core. That should make the code more stable if the core changes. * Fixed the interrupt dispatch Since the interrupt handler is global for all channels, we need to store not just the controller, but also the buffer refill function for each strip. * Added a demo This version of DemoReel100 spins off a separate task on core 0 that just performs the FastLED.show() operations. Regular code running on core 1 (the default for Arduino) signals this task to request a show(). * Avoid unnecessary timeouts Replaced a 500ms delay in the show task with MAX_DELAY. There's really no point in timing out (and crashing the program) just because the application hasn't called show. * Parallel output Reworked the code again in order to support parallel output, which is now the default mode. You can also now ask it to use the built-in RMT driver if you have other parts of your code that need the RMT peripheral. Two #defines control choices -- put either or both of these before including FastLED.h: #define FASTLED_RMT_CORE_DRIVER Uses the ESP core RMT driver. To do this, though, it allocates a big buffer to hold all of the pixel bits, so there is a memory and compute cost. #define FASTLED_RMT_SERIAL_OUTPUT Force serial output of each strip. * Documentation Describing the implementation and the compile-time switches * Removing files that should not be there * Fixed synchronization The previous checkin had bugs in the syncronization that caused problems in parallel mode when strips are different lengths. * Fixed a stupid bug Made the code bullet-proof in a few ways, but most importantly fixed a terrible integer underflow bug in the code that fills the RMT buffer. * Another major overhaul The big change in this version is the ability to support more than 8 controllers. Instead of assigning RMT channels to controllers in a fixed mapping, channels are assigned on the fly, allowing the driver to reuse channels as they become available. * Oops Didn't mean to check these in. * Fixed built-in driver mode Fixed the code so that it works with the built-in RMT driver. There's nothing special to do to enable it -- just #define FASTLED_RMT_BUILTIN_DRIVER true * Cleanup Fixing some documentation and configuration stuff * Rewrite of fastpin I've been needing to rewrite fastpin_esp32.h for the ESP32 ports and masks. This file also makes sure we don't use pins that won't work, even with clockless chips like the WS2812. * Got rid of tabs Which were making the code ugly. * Minor tweaks Added proper definitions for port() and toggle() to use the GPIO.out register. Changed the pin number test to avoid unnecessary conditions. * Allow TX and RX pins * Fixed pin access methods This should be the right set of definitions -- consistent with the other platforms. * Experimental Do not merge this code * Change pixel buffering The previous version of this code saved a copy of the PixelController every time show() is called. It appears that this causes massive memory fragmentation, eventually locking up the processor. This new version saves the pixel data is a separate buffer that is allocated only one time. * Some rearranging of the code Nothing major here. Added comments and put the functions is a better order. Added some defensive programming. * New I2S driver for ESP32 * Two updates: (1) avoid copying all the pixel data up front, and (2) use T1, T2, and T3 to encode thepulse patterns * Trying to get the timing better. * This version seems pretty solid * Yves' very cool changes to improve performance and accuracy * First attempt at merging the two drivers * Complete I2S implementation, with switch to choose it over the RMT * Removed the old header * This was added by accident * Changed the RMT driver so that it no longer needs to copy all the pixel data up front, which was slowing it down and using a lot of extra memory * Fixed a typo: make sure to load a different channel each time * Commented out all the Serial.print output * fillHalfRMTBuffer needs to be virtual in order to preserve the color channel order from the template parameters * Two mods: (1) convert CPU cycles directly to RMT cycles without going through nanoseconds; (2) improve performance of fill buffer by using a pointer into RMT memory rather than a bunch of indexes, and by inlining the getNextByte routine. * Minor cleanup * Cleaned up the conversion of CPU cycles to RMT cycles
2019-08-13Fix nRF52 race condition / hard lock (#857)Henry Gabryjelski
* Textbook example of where volatile is useful. * Use intrinsics that ensure memory barrier for sequence buffer lock. * Update wait time to ensure prior data had a chance to latch.
2019-08-13Fixes #856. (#860)Henry Gabryjelski
Initialization of pins may cause change in pin output. Fix may be to initialize th epin state in Init(), and call mWait.mark() to prevent showPixels() from sending actual LED data to the strand until any potential prior data had time to latch.
2019-08-13Merge branch 'teensy4'Daniel Garcia
2019-08-13Teensy 4 support! (#864)Daniel Garcia
* Pre-teensy4 work - with a 600Mhz clock, a 1Mhz clock was giving us a clock divider that overflowed a uint8_t - whoops... * Some tweaks to chipset definitions to help out the Teensy 4 implementation * Updating the pintest program w/Teensy 4 defs * Preliminary Teensy 4 support, including hardware SPI and clockless chipsets - no support for parallel output or DMA'd output yet - also not fully tested for all chipsets on all pins, but smoke tested with some chipsets and pin combinations and logic analyzer in the meantime * Checking in initial block clockless output - it compiles, but no testing yet, so it shouldn't be hooked up anywhere yet. * Tweak and fix parallel output - still need to hook it up to the default addLeds setup * more kicking
2019-08-13Wiring parallel clockless support for the Teensy 4 into FastLED.addLeds - ↵teensy4Daniel Garcia
updaitng parallel output example - time to merge back to master\!
2019-08-12more kickingDaniel Garcia
2019-08-12Tweak and fix parallel output - still need to hook it up to the default ↵Daniel Garcia
addLeds setup
2019-08-12Checking in initial block clockless output - it compiles, but no testing ↵Daniel Garcia
yet, so it shouldn't be hooked up anywhere yet.
2019-08-12Preliminary Teensy 4 support, including hardware SPI and clockless chipsets ↵Daniel Garcia
- no support for parallel output or DMA'd output yet - also not fully tested for all chipsets on all pins, but smoke tested with some chipsets and pin combinations and logic analyzer in the meantime
2019-08-12Pre-teensy4 work - with a 600Mhz clock, a 1Mhz clock was giving us a clock ↵Daniel Garcia
divider that overflowed a uint8_t - whoops...
2019-08-12Fix for #861 - override size in the octoWS2811 controller so that power ↵Daniel Garcia
calculations use all the leds.
2019-07-20Update due to newer gcc being more pendantic about constexpr. (#845)Henry Gabryjelski
Specifically, cannot cast integer values to pointers in a constexpr, requiring use of intptr_t in the constexpr. Callers of the constexpr may then cast it at the non-constexpr location of use. See https://stackoverflow.com/questions/10369606/constexpr-pointer-value
2019-07-03Swap #if for #elif - fix compiling w/m4 metro supportDaniel Garcia
2019-07-03Add pin mappings for Arduino Nano 33 IOT (#830)jeremy-mcgill
2019-07-03Bug fix to preserve color order information (#831)Sam Guyer
2019-07-03updated to fastpin_arm_d51.h (#834)Erin St Blaine
Added pin defs for the Adafruit Metro M4 Airlift Lite
2019-06-07warning cleanupDaniel Garcia
2019-06-07Updated ESP32 support (#789)Sam Guyer
* Support for ESP32 Credit to Rina Shkrabova for the first cut. * Clean up interrupt handling I think there was actually an error in the interrupt enabling/disabling, but I also cleaned it up so that it is more clear how interrupts are handled. * Better interrupt handling * Added RMT version Not fully portable yet, though. The timing numbers are hard-wired for WS2812, and the RMT channel is also hard-wired. * Fixed the timing Timing is now computed from T1, T2, amd T3 instead of being hard-wired. * Better buffer management The RMT signal is sent in 10-pixel chunks, using double-buffering to hide the latency when possible. Also: assign RMT channels sequentially. * Total rewrite using Martin's code * Better comments * Fixed the timing calculation We were not doing the conversion from ESP32 cycles to RMT cycles correctly. Now it all works! * Added Martin's changes * Removed confusing comments * Added my name! * Fixed ESP32 compile problem On ESP platforms the dev kit provides the function __cxa_pure_virtual, so there is no need to define it. * honor WAIT_TIME for chipsets that need it (for example TM1829) * Better interrupt handling Suggested by @h3ndrik : allocated the interrupt once at the initialization and then just turn it on and off. This is the strategy that the ESP32 core uses also. * Major refactoring Two major changes to the RMT driver. First, I realized that we can have only one interrupt handler attached to the RMT peripheral, so it needs to be able to handle all of the attached strips. To accomplish this, I store each ClocklessController in an array indexed by its RMT channel. The interrupt handler can then take the channel that triggered it and index into the array to get the right controller. The second major change is that I replaced all of the explicit bit twiddling of the RMT configurartion with calls to the proper functions in ESP32 core. That should make the code more stable if the core changes. * Fixed the interrupt dispatch Since the interrupt handler is global for all channels, we need to store not just the controller, but also the buffer refill function for each strip. * Added a demo This version of DemoReel100 spins off a separate task on core 0 that just performs the FastLED.show() operations. Regular code running on core 1 (the default for Arduino) signals this task to request a show(). * Avoid unnecessary timeouts Replaced a 500ms delay in the show task with MAX_DELAY. There's really no point in timing out (and crashing the program) just because the application hasn't called show. * Parallel output Reworked the code again in order to support parallel output, which is now the default mode. You can also now ask it to use the built-in RMT driver if you have other parts of your code that need the RMT peripheral. Two #defines control choices -- put either or both of these before including FastLED.h: #define FASTLED_RMT_CORE_DRIVER Uses the ESP core RMT driver. To do this, though, it allocates a big buffer to hold all of the pixel bits, so there is a memory and compute cost. #define FASTLED_RMT_SERIAL_OUTPUT Force serial output of each strip. * Documentation Describing the implementation and the compile-time switches * Removing files that should not be there * Fixed synchronization The previous checkin had bugs in the syncronization that caused problems in parallel mode when strips are different lengths. * Fixed a stupid bug Made the code bullet-proof in a few ways, but most importantly fixed a terrible integer underflow bug in the code that fills the RMT buffer. * Another major overhaul The big change in this version is the ability to support more than 8 controllers. Instead of assigning RMT channels to controllers in a fixed mapping, channels are assigned on the fly, allowing the driver to reuse channels as they become available. * Oops Didn't mean to check these in. * Fixed built-in driver mode Fixed the code so that it works with the built-in RMT driver. There's nothing special to do to enable it -- just #define FASTLED_RMT_BUILTIN_DRIVER true * Cleanup Fixing some documentation and configuration stuff * Rewrite of fastpin I've been needing to rewrite fastpin_esp32.h for the ESP32 ports and masks. This file also makes sure we don't use pins that won't work, even with clockless chips like the WS2812. * Got rid of tabs Which were making the code ugly. * Minor tweaks Added proper definitions for port() and toggle() to use the GPIO.out register. Changed the pin number test to avoid unnecessary conditions. * Allow TX and RX pins * Fixed pin access methods This should be the right set of definitions -- consistent with the other platforms. * Experimental Do not merge this code * Change pixel buffering The previous version of this code saved a copy of the PixelController every time show() is called. It appears that this causes massive memory fragmentation, eventually locking up the processor. This new version saves the pixel data is a separate buffer that is allocated only one time. * Some rearranging of the code Nothing major here. Added comments and put the functions is a better order. Added some defensive programming. * New I2S driver for ESP32 * Two updates: (1) avoid copying all the pixel data up front, and (2) use T1, T2, and T3 to encode thepulse patterns * Trying to get the timing better. * This version seems pretty solid * Yves' very cool changes to improve performance and accuracy * First attempt at merging the two drivers * Complete I2S implementation, with switch to choose it over the RMT * Removed the old header * This was added by accident * Changed the RMT driver so that it no longer needs to copy all the pixel data up front, which was slowing it down and using a lot of extra memory * Fixed a typo: make sure to load a different channel each time * Commented out all the Serial.print output
2019-06-07Enable support for nRF52 chipset. (#802)Henry Gabryjelski
LED strings for clockless are temporarily limited to 144 LEDs, adjustable via led_sysdefs.h #define.
2019-06-07Added in manitou48 's fixes to FastLed for ItsyBitsy M4 (SADM51 boards) (#803)devoh747
* Files fixed by manitou48 m4 feather express update I have not been able to find user manitou48 so I forked his changes and am trying to make a pull request to get it into FastLED. * delete led_sysdefs.h move led_sysdef.h to root of FastLED where it belongs. * Delete platforms.h Move platform.h to root of FastLED where it belongs. * move files to root of FastLED The led_sysdefs.h and platforms.h files belong in the root of the FastLED directory, not in platforms/arm/d51
2019-05-18Update fastpin_arm_d21 add ItsyBitsy M0 (#794)starkatt
Add support for Adafruit ItsyBitsy M0 including onboard APA102 ("Dotstar") LED
2019-05-15Removed conflicting (and unneeded) typedef of 'boolean', fixes #790Mark Kriegsman
2019-04-06Re-enable interrupts in between writing LED data for ARM M0. (#751)ademuri
* Fix breakage in NRF51 support introduced by #dba8825 * Re-enable interrupts in between writing LED data for ARM M0. This adds support for FASTLED_ALLOW_INTERRUPTS to ARM M0-based platforms (e.g. SAMD21). This fixes the clock getting off when using more than ~30 LEDs, since Arduino uses an interrupt to increment the millis clock. This uses SysTick->VAL to determine whether more than 45uSecs have elapsed while interrupts were enabled. This isn't as correct as using a dedicated timer, but it does work on all ARM M0 platforms.
2019-02-21Fix ATtiny25 compilation issue (port definitions) (#728)Hugo Woesthuis
* Fix ATtiny25 compilation issue The ATtiny25 does not have PORTA. It would give compilation errors. Also, because the ATtiny25 has a very small storage capacity, a compilation message will be presented warning the user. * Update fastpin_avr.h * Fix char type
2019-02-21stm32duino (Maple, Blue Pill, etc): compile fixKir Kolyshkin
This fixes the infamous > (...)/FastLED/platforms/arm/stm32/led_sysdefs_arm_stm32.h:4:25: > fatal error: application.h: No such file or directory issue when compiling code for Blue Pill (STM32F1xx). The above `#include <application.h>` was initially added by commit f149084 as part of the port for the particle photon boards. While it's not entirely clear where this header is coming from, it is clear that it's not there for the usual Arduino + stm32duino. So, to fix compilation for Blue Pill, while not breaking it for particle photon, let's move the include to under `#ifdef STM32F10X_MD`, the define which the original code used. Fixes: https://github.com/FastLED/FastLED/issues/741 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2019-02-17Fix #737 - don't invert the bits in what's being written out until after ↵Daniel Garcia
shifted, otherwise we end up writing out 1's for the low bits on 12-bit output devices
2019-01-27Enable SAMD51 (ARM Cortex M4) SupportLee Byron
2019-01-22Fix #725 - make sure yield gets defined for WAV boardsDaniel Garcia
2019-01-22Get rid of Dx defines in arm asm code for platforms that insist on using ↵Daniel Garcia
defines for their Dx pins
2019-01-22Get rid of Dx defines in trinket code for platforms that insist on using ↵Daniel Garcia
defines for their Dx pins
2019-01-20Fix #550 - add pin definitions for the onboard APA102 on the trinket m0Daniel Garcia
2019-01-20Make sure that everything called from the interrupt handler for ESP32 is ↵Daniel Garcia
marked with IRAM_ATTR property - should fix #676
2019-01-20Merge pull request #667 from jldesignseu/atmega328pbDaniel Garcia
added support for AVR atmega328pb
2019-01-20Merge pull request #678 from eClay/d21_iobusDaniel Garcia
Change SAMD21 fastpin to use PORT_IOBUS instead of PORT
2018-11-21Add basic support for SAMD51, used in M4 line from Adafruit (#662)Vince
* Add basic support for SAMD51, used in M4 line from Adafruit. Support is only based on Adafruit ItsyBitsy M4 Express, since it’s the only M4 board I have. * Pin verification from ItsyBitsy's variant.h + mixup between I2C and SPI
2018-11-13Change SAMD21 fastpin to use PORT_IOBUS instead of PORTGreg Mrozek
2018-10-26Fix #672 - we weren't setting LIB8_ATTINY for the ATtiny841/441 - so asm ↵Daniel Garcia
opcodes that don't exist on the tiny cores were getting used...
2018-10-16added support for atmega328pb SPI mode is not tested. Its tested with ↵jldesigns
bitbang WS2812 etc
2018-10-15Merge branch 'master' of https://github.com/FastLED/FastLEDDaniel Garcia
2018-09-20Suggest to `#define FASTLED_RMT_BUILTIN_DRIVER 1` (#654)johannesmaibaum
The documentation for FASTLED_RMT_BUILTIN_DRIVER says that you should #define FASTLED_RMT_BUILTIN_DRIVER before `#include`ing FastLED if you have custom RMT applications running. Without any non-zero value, this results in the following compile error: /path/to/Arduino/libraries/FastLED/platforms/esp/32/clockless_esp32.h: In member function 'void ClocklessController<DATA_PIN, T1, T2, T3, RGB_ORDER, XTRA0, FLIP, WAIT_TIME>::initRMT()': /path/to/Arduino/libraries/FastLED/platforms/esp/32/clockless_esp32.h:253:43: error: expected primary-expression before ')' token if (FASTLED_RMT_BUILTIN_DRIVER) { ^
2018-09-09Add ATmega644P to the pin definitions used by the ATmega1284P - fixes #598Daniel Garcia
2018-09-08add support for Hallowing! Its a samd21 but pins are rearranged quite a bit ↵Limor "Ladyada" Fried
(#650)
2018-09-01stm32duino port (Maple, Blue Pill etc.) (#568)Kirill Kolyshkin
This mostly builds on previous work for SparkCore STM32103 (Cortex M3), and patches from Evey Quirk. Unfortunately, stm32duino distribution does not include a header with definitions for CoreDebug registers and flags etc. (used in ) so they were added to a newly created cm3_regs.h from https://github.com/ARM-software/CMSIS/blob/master/CMSIS/Include/core_cm3.h [v2: changed PIN numbers to be int] Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2018-09-01only handle own rmt interrupts (#647)h3ndrik
Exit early if the interrupt is for another channel which is used by something else than FastLED. This is needed if we use FASTLED_RMT_BUILTIN_DRIVER and lower FASTLED_RMT_MAX_CHANNELS in order to free some rmt channels for something else. In this case doneOnChannel() is called for all rmt channels even if they don't belong to FastLED. So exit early in this case before the esp32 notices and reboots on its own.