Files
klubhaus-doorbell/libraries/FastLED/src/platforms
2026-02-12 00:45:31 -08:00
..
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00
2026-02-12 00:45:31 -08:00

FastLED Platforms Directory

Table of Contents

The src/platforms/ directory contains platform backends and integrations that FastLED targets. Each subfolder provides pin helpers, timing implementations, and controllers tailored to specific microcontrollers or host environments.

What lives here

  • adafruit Adapter that lets you use Adafruit_NeoPixel via the FastLED API
  • apollo3 Ambiq Apollo3 (SparkFun Artemis family)
  • arm ARM families (Teensy, SAMD21/SAMD51, RP2040, STM32/GIGA, nRF5x, Renesas UNO R4)
  • avr AVR (Arduino UNO, Nano Every, ATtiny/ATmega variants)
  • esp ESP8266 and ESP32 families
  • neopixelbus Adapter to drive NeoPixelBus through the FastLED API
  • posix POSIX networking helpers for host builds
  • shared Platformagnostic components (ActiveStripData, JSON UI)
  • stub Native, nohardware target used by unit tests/host builds
  • wasm WebAssembly/browser target and JS bridges
  • win Windowsspecific networking helpers

If you are targeting a desktop/browser host for demos or tests:

  • Native host tests → stub (with shared for data/UI)
  • Browser/WASM builds → wasm

Controller types in FastLED

FastLED provides two primary controller categories. Choose based on your LED chipset and platform capabilities.

1) Clockless (onewire NRZ)

  • For WS2811/WS2812/WS2812B/SK6812 and similar “NeoPixel”class LEDs
  • Encodes bits as precisely timed high/low pulses (T0H/T1H/T0L/T1L)
  • Implemented with tight CPU timing loops, SysTick, or hardware assist (e.g., ESP32 RMT or I2Sparallel)
  • Available as singlelane and, on some platforms, multilane “block clockless” drivers
  • Sensitive to long interrupts; keep ISRs short during show()

Special cases:

  • ESP32 offers multiple backends for clockless output (see esp/32):
    • RMT (recommended, perchannel timing)
    • I2Sparallel (many strips with identical timing)
    • Clockless over SPI (WS2812class only)

2) SPI (clocked)

  • For chipsets with data+clock lines (APA102/DotStar, SK9822, LPD8806, WS2801)
  • Uses hardware SPI peripherals to shift pixels with explicit clocking
  • Generally tolerant of interrupts and scales to higher data rates more easily
  • Requires an SPIcapable LED chipset (not for WS2812class, except the ESP32 “clockless over SPI” path above)

Picking the right path

  • WS2812/SK6812 → Clockless controllers (ESP32: RMT or I2Sparallel for many identical strips)
  • APA102/SK9822/DotStar → SPI controllers for stability and speed
  • Prefer neopixelbus or adafruit adapters if you rely on those ecosystems but want to keep FastLEDs API RP2040 (PIO clockless) needs no special defines; use standard WS2812 addLeds call.

Backend selection cheat sheet

  • ESP32 clockless: RMT (flexible), I2Sparallel (many identical strips), or SPIWS2812 path (WS2812only)
    • See ESP32 section for detailed I2S support (ESP32Dev, ESP32S3) and RMT v4 vs v5 selection, including define examples and guidance on avoiding mixed RMT4/RMT5 usage.
  • Teensy 3.x/4.x: clockless (single or block multilane), plus OctoWS2811/SmartMatrix integrations (see arm/k20, arm/mxrt1062)
  • AVR: clockless WS2812 and SPI chipsets; small devices benefit from fewer interrupts during show()

Troubleshooting and tips

  • Firstpixel flicker or color glitches often indicate interrupt interference. Reduce background ISRs (WiFi/BLE/logging) during FastLED.show() or select a hardwareassisted backend.
  • Power and level shifting matter: WS281x typically need 5V data at sufficient current; ensure a common ground between controller and LEDs.
  • On ARM families, PROGMEM is typically disabled (FASTLED_USE_PROGMEM=0); on AVR it is enabled.
  • For very large installations, consider parallel outputs (OctoWS2811 on Teensy, I2Sparallel on ESP32) and DMAfriendly patterns.

How to implement a clockless controller

Clockless controllers generate the onewire NRZ waveforms used by WS281xclass LEDs by toggling a GPIO with precise timings. FastLEDs clockless base controllers accept three timing parameters per bit: T1, T2, T3.

T1/T2/T3 vs T0H/T0L/T1H/T1L

The timing model is:

  • At T=0: line goes high to start a bit
  • At T=T1: drop low to transmit a 0bit (T0H just ended)
  • At T=T1+T2: drop low to transmit a 1bit (T1H just ended)
  • At T=T1+T2+T3: bit cycle ends; next bit can start

Mapping to datasheet values:

  • T0H = T1
  • T1H = T2
  • T0L = duration T0H
  • T1L = duration T1H

Where duration is the max of the two bit periods: max(T0H + T0L, T1H + T1L).

Embedded helper script (from src/chipsets.h) to derive T1/T2/T3 from datasheet T0H/T0L/T1H/T1L:

print("Enter the values of T0H, T0L, T1H, T1L, in nanoseconds: ")
T0H = int(input("  T0H: "))
T0L = int(input("  T0L: "))
T1H = int(input("  T1H: "))
T1L = int(input("  T1L: "))

duration = max(T0H + T0L, T1H + T1L)

print("The max duration of the signal is: ", duration)

T1 = T0H
T2 = T1H
T3 = duration - T0H - T0L

print("T1: ", T1)
print("T2: ", T2)
print("T3: ", T3)

Notes:

  • Some platforms express timings in CPU cycles rather than nanoseconds; FastLED provides converters/macros to derive cycle counts.
  • See the platformspecific ClocklessController implementation for the required units and conversion helpers.

Multilane output

“Multilane” or “block clockless” controllers send several strips in parallel by transposing pixel data into perbit planes and toggling multiple pins simultaneously.

  • Benefits: High aggregate throughput; useful for matrices and large installations.
  • Constraints: All lanes must share the same timing and frame cadence; ISR windows apply across all lanes during output.

Supported in this codebase:

Typically singlelane only in this codebase:

  • AVR family
  • RP2040 (PIO driver here is singlelane)
  • nRF51/nRF52
  • STM32/GIGA (clockless singlelane in this tree)

For Teensy, also consider OctoWS2811 for DMAdriven parallel output.

How to implement a SPI controller

SPIdriven LEDs use a clocked data line plus a clock line. Implementation is generally simpler and more ISRtolerant than clockless.

Hardware SPI vs software SPI

  • Hardware SPI: Uses the MCUs SPI peripheral; best performance and CPU efficiency; works with DMA on some platforms.
  • Software SPI (bitbang): Uses GPIO toggling when a hardware SPI peripheral or pins arent available; slower and more CPUintensive but universally portable.

FastLEDs SPIOutput abstracts both; platform headers select efficient implementations where available.

Common SPI LED chipsets

  • APA102 / “DotStar” (and HD variants): Data + clock + perpixel global brightness; tolerant of interrupts. See APA102 controller definitions.
  • SK9822: Protocol compatible with APA102 with minor differences; supported.
  • WS2801, LPD8806, LPD6803, P9813, SM16716: Older or niche SPIstyle protocols; supported via specific controllers.

When choosing SPI speed, consult chipset and wiring limits (signal integrity on long runs). Long APA102 runs may require reduced clock rates.

PROGMEM

Some platforms store constant tables and palettes in flash (program) memory rather than RAM. FastLED abstracts PROGMEM usage via macros; support varies by platform.

  • AVR: Full PROGMEM support; default FASTLED_USE_PROGMEM=1. Flash is separate from RAM; use pgm_read_ accessors for reads.
  • ESP8266: PROGMEM supported; see progmem_esp8266.h. Provides FL_PROGMEM, FL_PGM_READ_*, and FL_ALIGN_PROGMEM (4byte alignment) helpers.
  • ESP32, ARM (Teensy, SAMD21/51, RP2040, STM32/GIGA, nRF): Typically treat constants as directly addressable; FastLED defaults to FASTLED_USE_PROGMEM=0 on these families to avoid unnecessary indirection.

Aligned reads for PROGMEM:

  • On platforms that require alignment (e.g., ESP8266), use 4byte alignment for multibyte table entries to avoid unaligned access traps. FastLED exposes FL_ALIGN_PROGMEM for this purpose.

Platforms without PROGMEM (or where its a noop in this codebase):

  • Most ARM families (SAMD, STM32, nRF, RP2040) and ESP32 use memorymapped flash; PROGMEM macros are disabled here via FASTLED_USE_PROGMEM=0.

Check each platforms led_sysdefs_* header for the recommended PROGMEM and interrupt policy.

Common feature defines

These are commonly available across multiple platforms. Pass them as build defines (e.g., build_flags in PlatformIO), and define them prior to including FastLED.h.

  • FASTLED_USE_PROGMEM — Control PROGMEM usage (enabled on AVR, typically disabled elsewhere)
  • FASTLED_ALLOW_INTERRUPTS — Allow interrupts during show() (platform defaults vary)
  • FASTLED_INTERRUPT_RETRY_COUNT — Global retry count when timing is disrupted
  • FASTLED_DEBUG_COUNT_FRAME_RETRIES — Enable counters/logging of frame retries due to timing issues

For platformspecific feature defines (e.g., ESP32 RMT/I2S knobs, RP2040 PIO selection, Teensy/STM32 options), see the README in that platforms directory: