Implementation of the LedDevice interface for writing to LPD8806 led device. More...
#include <LedDeviceLpd8806.h>
Public Member Functions | |
| LedDeviceLpd8806 (const QJsonObject &deviceConfig) | |
| Constructs specific LedDevice. More... | |
| virtual bool | init (const QJsonObject &deviceConfig) |
| Sets configuration. More... | |
 Public Member Functions inherited from ProviderSpi | |
| ProviderSpi () | |
| Constructs specific LedDevice. | |
| virtual | ~ProviderSpi () |
| Destructor of the LedDevice; closes the output device if it is open. | |
| int | open () |
| Opens and configures the output device. More... | |
| Public Member Functions inherited from LedDevice | |
| LedDevice (const QJsonObject &config=QJsonObject(), QObject *parent=nullptr) | |
| virtual int | switchOff () |
| Switch the leds off (led hardware disable) | |
| virtual int | switchOn () |
| Switch the leds on (led hardware enable), used if reinitialization is required for the device implementation. | |
| virtual int | setLedValues (const std::vector< ColorRgb > &ledValues) |
| const QString & | getColorOrder () |
| Get color order of device. More... | |
| void | setActiveDevice (QString dev) |
| const QString & | getActiveDevice () |
| void | setLedCount (int ledCount) |
| int | getLedCount () |
| void | setEnable (bool enable) |
| bool | enabled () |
| int | getLatchTime () |
| bool | componentState () |
Static Public Member Functions | |
| static LedDevice * | construct (const QJsonObject &deviceConfig) |
| constructs leddevice | |
Additional Inherited Members | |
| Public Slots inherited from LedDevice | |
| virtual void | start () |
| Is called on thread start, all construction tasks and init should run here. | |
| Signals inherited from LedDevice | |
| void | enableStateChanged (bool newState) |
| Emits whenever the led device switches between on/off. More... | |
| void | visiblePriorityChanged (const quint8 &priority) |
| PIPER signal for Priority Muxer -> LedDevice. More... | |
| Protected Slots inherited from LedDevice | |
| int | rewriteLeds () |
| Write the last data to the leds again. | |
| Protected Member Functions inherited from ProviderSpi | |
| int | writeBytes (const unsigned size, const uint8_t *data) |
| Writes the given bytes/bits to the SPI-device and sleeps the latch time to ensure that the values are latched. More... | |
| Protected Attributes inherited from ProviderSpi | |
| QString | _deviceName |
| The name of the output device. | |
| int | _baudRate_Hz |
| The used baudrate of the output device. | |
| int | _fid |
| The File Identifier of the opened output device (or -1 if not opened) | |
| int | _spiMode |
| which spi clock mode do we use? (0..3) | |
| bool | _spiDataInvert |
| 1=>invert the data pattern | |
| spi_ioc_transfer | _spi |
| The transfer structure for writing to the spi-device. | |
| Protected Attributes inherited from LedDevice | |
| QJsonObject | _devConfig |
| Logger * | _log |
| The common Logger instance for all LedDevices. | |
| std::vector< uint8_t > | _ledBuffer |
| The buffer containing the packed RGB values. | |
| bool | _deviceReady |
| QString | _activeDevice |
| int | _ledCount |
| int | _ledRGBCount |
| int | _ledRGBWCount |
| QTimer | _refresh_timer |
| Timer object which makes sure that led data is written at a minimum rate e.g. More... | |
| unsigned int | _refresh_timer_interval |
| qint64 | _last_write_time |
| unsigned int | _latchTime_ms |
Detailed Description
Implementation of the LedDevice interface for writing to LPD8806 led device.
The following description is copied from 'adafruit' (github.com/adafruit/LPD8806)
Clearing up some misconceptions about how the LPD8806 drivers work:
The LPD8806 is not a FIFO shift register. The first data out controls the LED closest to the processor (unlike a typical shift register, where the first data out winds up at the furthest LED). Each LED driver 'fills up' with data and then passes through all subsequent bytes until a latch condition takes place. This is actually pretty common among LED drivers.
All color data bytes have the high bit (128) set, with the remaining seven bits containing a brightness value (0-127). A byte with the high bit clear has special meaning (explained later).
The rest gets bizarre...
The LPD8806 does not perform an in-unison latch (which would display the newly-transmitted data all at once). Rather, each individual byte (even the separate G, R, B components of each LED) is latched AS IT ARRIVES... or more accurately, as the first bit of the subsequent byte arrives and is passed through. So the strip actually refreshes at the speed the data is issued, not instantaneously (this can be observed by greatly reducing the data rate). This has implications for POV displays and light painting applications. The 'subsequent' rule also means that at least one extra byte must follow the last pixel, in order for the final blue LED to latch.
To reset the pass-through behavior and begin sending new data to the start of the strip, a number of zero bytes must be issued (remember, all color data bytes have the high bit set, thus are in the range 128 to 255, so the zero is 'special'). This should be done before each full payload of color values to the strip. Curiously, zero bytes can only travel one meter (32 LEDs) down the line before needing backup; the next meter requires an extra zero byte, and so forth. Longer strips will require progressively more zeros. *(see note below)
In the interest of efficiency, it's possible to combine the former EOD extra latch byte and the latter zero reset...the same data can do double duty, latching the last blue LED while also resetting the strip for the next payload.
So: reset byte(s) of suitable length are issued once at startup to 'prime' the strip to a known ready state. After each subsequent LED color payload, these reset byte(s) are then issued at the END of each payload, both to latch the last LED and to prep the strip for the start of the next payload (even if that data does not arrive immediately). This avoids a tiny bit of latency as the new color payload can begin issuing immediately on some signal, such as a timer or GPIO trigger.
Technically these zero byte(s) are not a latch, as the color data (save for the last byte) is already latched. It's a start-of-data marker, or an indicator to clear the thing-that's-not-a-shift-register. But for conversational consistency with other LED drivers, we'll refer to it as a 'latch' anyway.
This has been validated independently with multiple customers' hardware. Please do not report as a bug or issue pull requests for this. Fewer zeros sometimes gives the illusion of working, the first payload will correctly load and latch, but subsequent frames will drop data at the end. The data shortfall won't always be visually apparent depending on the color data loaded on the prior and subsequent frames. Tested. Confirmed. Fact.
The summary of the story is that the following needs to be writen on the spi-device: 1RRRRRRR 1GGGGGGG 1BBBBBBB 1RRRRRRR 1GGGGGGG ... ... 1GGGGGGG 1BBBBBBB 00000000 00000000 ... |------—led_1-------—| |------—led_2– -led_n-------—| |-—clear data–
The number of zeroes in the 'clear data' is (#led/32 + 1)bytes (or *8 for bits)
Constructor & Destructor Documentation
§ LedDeviceLpd8806()
| LedDeviceLpd8806::LedDeviceLpd8806 | ( | const QJsonObject & | deviceConfig | ) |
Constructs specific LedDevice.
- Parameters
-
deviceConfig json device config
Member Function Documentation
§ init()
|
virtual |
Sets configuration.
- Parameters
-
deviceConfig the json device config
- Returns
- true if success
Reimplemented from ProviderSpi.
The documentation for this class was generated from the following files:
- libsrc/leddevice/dev_spi/LedDeviceLpd8806.h
- libsrc/leddevice/dev_spi/LedDeviceLpd8806.cpp
