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.

Pardon my ignorance, but could you, please, point me to an example of such circuit? I am not sure I can come up with the best solution. Being a programmer rather than electronics engineer, all I can think of is throwing in an AND gate where CLK and (active-high mode) CS are inputs and the output goes to the LED strip.

Dammit, you're right! I should've checked the time scale on the crippled diagram.

But now I stumble on the next problem. I connected my APA-102 RGB LED strip to the GPIO pins 7 (CLK) and 8 (MOSI), and it appears that this connection causes some bad interference with Omega:

• At boot, about 20 of LEDs are lighting up and twinkling, showing that there is some data being sent out of SPI. Since I am not using the CS1 pin, my interpretation is that the data that is meant for SPI device 0, now is captured by the LED strip (it says here, that "..device 0 (CS0) is connected to the flash memory used by the Omega").
• Omega is working with random glitches, perhaps the communication with device 0 is being messed up.

Perhaps I am missing some simple fix here? Perhaps I should let the LED strip receive signal from MOSI only when CS1 is high?

Hmm, I just tested the python-spidev and it just gives bad output. The clock is uneven, and the data has only one instance of "1", followed with pause, and then left at HIGH for long time:

Here's the code I use for testing:

import spidev
spi = spidev.SpiDev()
spi.open(32766, 1)
to_send = [0x01, 0x02, 0x03]
spi.xfer(to_send)
spi.close()

Meanwhile, the pyOnionSpi, that appears to be based on the buggy spi-tool, at least gives me correct output:

import onionSpi
spi  = onionSpi.OnionSpi(1, 32766) # Due to the spi-tool bug, bus and device param values are swapped
spi.write([0x01, 0x02, 0x03])

So I am not sure why you are suggesting to switch to something that doesn't appear to work at all.

Ok, thanks, I will use this python module for now, and stick with Python 2.7 until you release the Python3 version.

Ok, well, I just followed the advice from the official Omega2 documentation. There is no mention of spi-tool being deprecated.

I understand you suggest to use python module instead of command-line tool, does that mean that there is no command-line tool for SPI writing and reading?

I think there's a bug in the spi-tool. I followed the instructions to set up SPI connection to my logic analyzer, and then went ahead to write some test data:

root@Omega:~# spi-tool -b 32766 -d 1 write 0x12 0x42
> SPI Write to addr 0x12: 0x42
ERROR: could not open sysfs device '/dev/spidev1.32766'

Since the device name under/dev is /dev/spidev32766.1, it appears that the spi-tool swaps the parameter values for bus and device. And, sure enough, if I do

root@Omega:~# spi-tool -b 1 -d 32766 write 0x12 0x42
> SPI Write to addr 0x12: 0x42

..then the data get sent out properly.

There was that email from Onion to the user community where users were encouraged to switch to Pyton3, because Python2.7 will be at EOL soon.

So I went ahead and installed it (instructions at https://docs.onion.io/omega2-docs/installing-and-using-python.html)

Next, I wanted to install SPI module, do to some experiments with APA-102 RGB LED strip. I found this page:
https://docs.onion.io/omega2-docs/spi-python-module.html#spi-python-module

But installing the pyOnionSpi package resulted in pulling in also the python-base package, so I figure this is a Python 2.7 module. I can't find any trace of corresponding package for Python3. Does it exist? Because if it does not, and maybe also other specialized modules for Omega are not migrated, then there is good incentive to stick with Python2.7.

I have tried to register with my real name, and failed, with two different email addresses. When I tried to register third time, I decided (random guess) to replace special non-ASCII Unicode characters ("ā") in my name with their ASCII counterparts ("a"). And that is now the only login that works. The two broken users are now useless, because when I log in, using email and password, I get "Login error" and that's it.
I have tried to reach support but no luck. I hoped there would be some way to change the full name for those broken users so that I could use them.

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.