Driving APA102 (SPI) RGB LED from Omega2+
-
I have been enjoying driving my APA102 RGB LED strip from Omega (first version), using just two wires (and GND, of course): MOSI on GPIO #18, and SCK on GPIO #6 .
Now I'd like to migrate my project to Omega2+. So, I connected the LED strips GND to Omega GND, data line to GPIO #8, anc clock line to GPIO #7 (following the pinout). First thing to notice was that Omega apparently sends some data at boot because ~30 first pixels of the LED strip are twinkling in various colors. Then, it turns out it has not booted properly, because when I attempted ssh login, I found myself in some broken shell (no banner). Rebooting with the SPI wires disconnected resulted in a corrupted boot so that finally I was forced to do factory reset.
I am surprised that such a supposedly simple thing resulted in such a challenge.
-
As far is I know the SPI bus on the external header of the Omega2 is shared with the internal NOR Flash (which is tied internally to CS0). This probably causes the 'boot-effects' you're experiencing (as the APA102 does not have a CS/SS line)
For devices without SS-line it's probably easiest to set up a software (bitbang) spi bus e.g. with the
spi-gpio-custommodule, which isn't shared with something else.
-
I wonder how that works that the APA102 steals the signal from CS0. Why one SPI device consuming MOSI data should mean that another device on that bus does not receive it?
Anyway, I think I will keep looking for a way how to ground the CLK signal that goes to APA102, when CS1 pin is active (low, or high, depending on what will the circuit look like). For example, I am thinking if letting CLS and CS1 (active-high) go in the AND gate, perhaps then the output CLK would be a good for driving the APA102.
-
@Pavils-Jurjans Ah I responded over in this thread: http://community.onion.io/topic/3189/spi-using-pyton3/9
Yeah, @Rogier-Lodewijks is correct, the SPI bus is shared with the internal flash. My best guess is that the APA102 doesn't allow the Omega to freely drive the SPI MOSI line, garbling the communication with the flash.You can either setup a software SPI bus, or build a small circuit to separate MOSI from the APA102 if CS1 is not asserted (a few more details on this in the other thread)
-
Even if the APA102 did work without gating the signal by CS1, I would still strongly recommend to use a level shifter (which also can do the gating via CS1) in between.
Because if you look at the APA102 datasheet, it specifies a minimum high level voltage of 0.7*VDD, which means 3.5V. The Omega2 as a 3.3V device can never reach that minimum.
So while directly connected APA102 might work, it's more by accident and certainly not a reliable setup. Changes in temperature for example might make it fail. (I have quite extenisve real-world experience with that, the 7000+ RGB LEDs in this platform are driven by Omega2S via 74AHCT125...)
So my recommendation would be to use a 74AHCT1G125 (single gate) or 74AHCT125 (4 gates) to solve both level shifting and signal gating problems with one cheap chip.
-
@luz Thank you, I finally solved this! Ordered bunch of 74HC125D chips, there are four gates per chip. I pass through the gate only the CLK line, assuming that any MOSI traffic will be ignored by the strip when there is no CLK. So far so good, it seems that both flash memory (device 0), and LED strip are working just fine.
