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.
I seem to have found a solution for this issue, or at least a work around that works for me: YMMV
I've merged in the OpenWRT repo (git merge -X theirs openwrt/lede-17.01) into my OnionIoT/source repo. That built flawlessly ! :). So we're running kernel 4.4.153 now. That's nice on its own (always recommended to keep up with LTS kernel versions!).
Anyway, the SPI problem persisted. Then I removed the original Onion patch file for the spi-mt7621 module (rm ramips/patches-4.4/9999-spi-mt7621.patch) and rebuilt the image. Now we're using the unpatched mainline SPI driver. Guess what: this seems to work flawlessly! :) I'm a happy man now.
I only did some quick smoke tests, so it could be other SPI stuff breaks because of the missing patch. On the other hand, there have been some commits to the spi-mt7621 module in June, so the mainline might just be the only thing we need.
@Rogier-Lodewijks no, u don't need patch spidev, only spi-mt7621.c source file and it's in kernel yea. After this u can add cs-gpios in device tree, and spi device in node. Spi device can be spidev if u developing spi driver and u need its API. Thank you)
Thank you @Zheng-Han - a little out of my depth with that for now :( I think I must rather focus on my original issue with the i2c driver freezing up randomly when fetching data from the arduino. I need to find a way to restart the driver without having to resort to a reboot and losing data.
It seems that you would then get the maximum response from your sonar, and then shuttle the data from the arduino chip one to the omega. For around $25 (20 for the dock, and around 4-5 for the sensor) you could get this done much in the same way you have before, without having to depend on linux timing being a bit inadequate for the task.
There are almost certainly ways to make this work, but they may take some non-trivial engineering.
Understand and work around the SPI issues. They mostly have to do with simultaneous write/read operations and long transfers, both of which can usually be avoided at the cost of some efficiency
Proxy the SPI through something else, for example a fixed-function chip (FTDI, etc) or a small MCU, hanging off either the USB or one of the UARTs
See if you can use the I2S interface instead - this is normally meant to move audio data but it is not dissimilar to SPI. Many chips have offered functional blocks that did both SPI and I2S by configuring different details, which may be well within the range of what you can do with clever software
Bitbang SPI on arbitrary GPIOs. Probably slow, though you can do the actually twiddling in kernel mode