Detailed Description
Shared "slim bridge" legacy addLeds<ESPIChipsets ...>() controller for the SPI channel API – driver-agnostic over IChannelDriver without ever instantiating a runtime fl::Channel.
Extracted (issue #4585, meta #4580) as the SPI sibling of fl/channels/slim_bridge_controller.h (clockless). Where the clockless slim bridge owns one DATA_PIN/TIMING pair built once at construction, this owns one SpiChipsetConfig and re-resolves its driver every frame via ChannelManager::selectDriverForChannel() – mirroring Channel::resolveDynamicDriver() (fl/channels/channel.cpp.hpp) bit-for-bit. That mirroring is safe because TypedChannel<B, SpiChipsetConfig, Which>::create() always resolves Bus::AUTO to a concrete bus via detail::resolve_bus<B, Chipset> and writes that resolved bus into ChannelConfig::options.mBus before constructing the runtime Channel – so the Channel this controller replaces was never actually Bus::AUTO-dispatched at showPixels() time either. This controller resolves the same way, using kBus (the resolved bus) rather than the raw template argument B.
Colour-profile note: legacy addLeds<ESPIChipsets ...>() returns a bare CLEDController& (a Channel&, under the old TypedChannel path). Nothing in the public Channel surface (fl/channels/channel.h) exposes a setColorProfile() – profile binding is only reachable through ChannelConfig/ChannelOptions at Channel::create(cfg) time (fl/channels/options.h, fl/channels/pipeline_binding.h), and the legacy addLeds<>() overloads in FastLED.h never surface that config to the sketch. So a legacy SPI channel can never have a colour profile bound, and the tryEncodeManagedSpi() branch inside Channel::encodeAPA102() et al. (fl/channels/channel.cpp.hpp) is always a no-op on this path. This controller therefore omits the colour-managed branch entirely and calls the unmanaged PixelIterator writers directly – byte-identical to the old path's managed == false case, which is the only case the old path could ever reach here.
SpiChipset::MY9221 is never routed here: FastLED.h dispatches legacy addLeds<MY9221> to the bit-bang MY9221Controller (fl/chipsets/my9221.h), because the MY9221 clocks data on both clock edges (DDR) and cannot be carried as SPI bytes (#4636).
Definition in file slim_spi_bridge_controller.h.
#include "fl/stl/noexcept.h"#include "fl/stl/static_assert.h"#include "cpixel_ledcontroller.h"#include "fl/channels/data.h"#include "fl/channels/driver.h"#include "fl/channels/manager.h"#include "fl/channels/bus.h"#include "fl/channels/bus_traits.h"#include "fl/channels/channel_typed.h"#include "fl/channels/config.h"#include "fl/chipsets/encoders/pixel_iterator.h"#include "fl/log/log.h"
Include dependency graph for slim_spi_bridge_controller.h: This graph shows which files directly or indirectly include this file:Go to the source code of this file.
Classes | |
| class | fl::SlimSpiBridgeController< CHIPSET, RGB_ORDER, B, B_WHICH > |
Shared legacy addLeds<ESPIChipsets ...>() bridge controller over an IChannelDriver, for chipsets whose encoding never needs the colour-managed pipeline (see file-level comment). More... | |
Namespaces | |
| namespace | fl |
| Base definition for an LED controller. | |
