@Pavils-Jurjans Ok, finally, got this working! The missing data problem was solved by changing the frequency to 200KHz. Apparently, the hardware SPI gets unreliable with low frequencies. Now I wonder what is the maximum frequency, as I tried 3.2MHz and it still works (For my 300 pixel APA102 RGB LED strip, I measure about 200 updates per second).
@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.
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