1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

X86/64 Allwinner H3 and WS2801 - weird color switch every (un)even value

Discussion in 'Hardware Support' started by mirko, 19 April 2018.

  1. mirko

    mirko New Member

    Messages:
    5
    Hello,

    I got Hyperion running on my Allwinner H3 based Orange Pi board - kind of.
    It has a WS2801 RGB LED strip connected via (HW-)SPI and Hyperion is compiled with PLATFORM=x86 and is accessing the LED strip via /dev/spidev.
    Using HyperCon the colors however seemed odd to me, e.g. every time I select "red" in the HyperCon colorwheel I get green.
    I figured it might be RGB confusion (RBG, BGR, BRG, GBR, BRG, ..), however no mode fixed that.

    Then I manually set RGB to 254, 0, 0 instead of 255, 0, 0 and finally my LED strip illuminated red!
    Setting it to 253, 0, 0 however turned it green again. 252, 0, 0 red. So setting the red channel to an even number shows red, as expected, setting it to uneven numbers don't.

    I have dumps of the SPI signal captured by a logicanalyzer as well as an oscilloscope if that's of any help. As I don#t have any other idea, I suspect it being a timing issue.

    Thanks a lot!

    PS: There's no prefix nearly matching my matter.
     
    Last edited: 23 April 2018
  2. TPmodding

    TPmodding Administrator Staff Member Administrator

    Messages:
    926
    Hardware:
    RPi1/Zero, RPi2, RPi3, +Arduino, +nodeMCU/ESP8266
  3. mirko

    mirko New Member

    Messages:
    5
    I got myself a Raspberry Pi 2 model B with Raspbian on it to compare signals with what my H3 does.

    Both are compiled from source (master) and configured to access the strip via /dev/spidev.
     
    Last edited: 28 April 2018
  4. mirko

    mirko New Member

    Messages:
    5
    Here's a screenshot showing the SPI-communication.

    [​IMG]

    First two wires are CLOCK/MOSI connected to the Raspberry Pi.

    Wire 3 and 4 are CLOCK/MOSI connected to the Orange Pi One (Allwinner H3 based).

    I captured both transmissions after another and aligned both in this image for convenience.

    Obvious differences:
    1) MOSI is "high" in default state on H3, while on the RasPi it's "low".
    2) CLOCK gets pulled "high" for ~10µs shortly before transmission starts on H3.
    While those 2 points don't matter at all when complying with the SPI spec, it might be for the WS2801.

    As above mentioned differences seem to occur in HW, I guess I'm stuck here.
     
  5. mirko

    mirko New Member

    Messages:
    5
    Apparently I'm not the first noticing that HIGH right before transmission on the SCK line.

    https://github.com/nRF24/RF24/issues/257
    http://linux-sunxi.narkive.com/zL32...-dip-in-sclk-right-when-slave-select-goes-low

    I adapted the hint in the last answer to the sun6i_spi driver and got rid of it. Now things are working smoothly.

    Code:
    diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
    index 8533f4edd00a..6a14589cce32 100644
    --- a/drivers/spi/spi-sun6i.c
    +++ b/drivers/spi/spi-sun6i.c
    @@ -304,6 +304,9 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
            sun6i_spi_write(sspi, SUN6I_CLK_CTL_REG, reg);
    +       /* Finally enable the bus - doing so before might raise SCK to HIGH */
    +       sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG) | SUN6I_GBL_CTL_BUS_ENABLE);
    +
            /* Setup the transfer now... */
            if (sspi->tx_buf)
                    tx_len = tfr->len;
    @@ -411,7 +414,7 @@ static int sun6i_spi_runtime_resume(struct device *dev)
            }
            sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG,
    -                       SUN6I_GBL_CTL_BUS_ENABLE | SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
    +                       SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
            return 0;
    
     
  6. penfold42

    penfold42 Moderator Developer

    Messages:
    742
    Hardware:
    RPi1/Zero, RPi2, RPi3, 32/64bit, +Arduino, +nodeMCU/ESP8266
    Sorry I missed this but io now.

    There are 4 different common spi modes with differences in how the clock line works.
    Namely 1) is a clock pulse and low->high or high->low
    2) does the clock idle high or low when finished.

    My guess is the allwinner spi driver is broken and not settingnofnthe SoC SPI controller correctly
     
  7. penfold42

    penfold42 Moderator Developer

    Messages:
    742
    Hardware:
    RPi1/Zero, RPi2, RPi3, 32/64bit, +Arduino, +nodeMCU/ESP8266
    Just read the GitHub thread - it looked pretty horrible without that patch.

    It’s not quite the issue I described but if something has the device open, the spi clock really needs to be stable and correct. Especially for ws2801 which have no spi chip select pin
     
  8. mirko

    mirko New Member

    Messages:
    5
    I'm aware of the different modes and already picked the correct one (phase-shift, clock-polarity, ..) when I measured the logic levels.