Makuna / NeoPixelBus

An Arduino NeoPixel support library supporting a large variety of individually addressable LEDs. Please refer to the Wiki for more details. Please use the GitHub Discussions to ask questions as the GitHub Issues feature is used for bug tracking.
GNU Lesser General Public License v3.0
1.18k stars 261 forks source link

UCS7604 & inconsistent timing output on applySettings #840

Closed exitrip closed 2 weeks ago

exitrip commented 2 weeks ago

I guess this is technically a feature request, as I'm working on adding code, but the behaviour is buggy. I developing on Ubuntu, using VSCode's PlatformIO plugin, to build WLED images for an ESP32 WROOM-32. I don't think WLED or PIO has anything to do with the output I'm seeing.

Based on chips with "applySettings" methods, I'm testing a simple extension the NeoRgbw64Feature class to include a hardcoded 8 byte header to try to bring up a custom strip of UCS7604s. Absent a real datasheet, both the drivers that work with the strip frame the data string with FFFF_FFFF_FFFF_0003h, which is probably 3 current output + 1 a mode setting, but all I want to test right now is if the chips will accept this header.

While I see consistent data output in pixel fields (pData after the 8 byte header, i.e. red is the red value, green is green value ), the 8 start bytes are oscillating back and forth between two values that have basically nothing to do with FFFF or 0003. I'll skip pictures of the LA captures for now, but is there some lower layer data mangling between applySettings() and the wire?

class NeoUCS7604Settings 
{
public:
    // NeoTm1914Settings(NeoTm1914_Mode mode = NeoTm1914_Mode_DinOnly)  :
    //     Mode(mode)
    // {
    // }

    // NeoTm1914_Mode Mode;
};

class Neo8ByteElementsUCS7604Settings : public Neo8ByteElements
{
public:
    typedef NeoUCS7604Settings SettingsObject;
    static const size_t SettingsSize = 8;

    static void applySettings([[maybe_unused]] uint8_t* pData, [[maybe_unused]] size_t sizeData, [[maybe_unused]] const SettingsObject& settings)
    {
        // settings are at the front of the data stream
        uint8_t* pSet = pData;
        // uint8_t mode = 0xff;

        // 0xFFFF, probably G max current
        *pSet++ = 0xff;
        *pSet++ = 0xff;

        // 0xFFFF, probably B max current
        *pSet++ = 0xff;
        *pSet++ = 0xff;

        // 0xFFFF, probably R max current
        *pSet++ = 0xff;
        *pSet++ = 0xff;

        // 0x0003, probably "field" mode (number of channels)
        *pSet++ = 0x00;
        *pSet++ = 0x03;
    }

    static uint8_t* pixels([[maybe_unused]] uint8_t* pData, [[maybe_unused]] size_t sizeData)
    {
        // settings are at the front of the data stream
        return pData + SettingsSize;
    }

    static const uint8_t* pixels([[maybe_unused]] const uint8_t* pData, [[maybe_unused]] size_t sizeData)
    {
        // settings are at the front of the data stream
        return pData + SettingsSize;
    }
};

// class NeoRgbTm1914Feature : public Neo3ByteElementsTm1914Settings
// ...
// class NeoRgbw64Feature : public Neo8ByteElementsNoSettings
class NeoRgbw64Feature : public Neo8ByteElementsUCS7604Settings
{
public:
...
exitrip commented 2 weeks ago

The inconsistent settings data output was related to WLED's handling of the maintainBufferConsistency flag in the Show(bool maintainBufferConsistency = true) method.

Makuna commented 2 weeks ago

https://github.com/Makuna/NeoPixelBus/issues/842