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
Im trying do to kind of the same but for a ILI9341. It's essentially the same, but changing the commands codes.
What I've been trying to overcome (without success) is the malfunctioning of the SPIs MSB. I have had a peek at your code and it's mostly similar to mine. How did you overcome this issue?
The funny thing is that for this particular display the bug doesn't matter so much -- when writing to registers, conveniently, the address of the important registers of the ILI9225 are in the range where the SPI transmitter doesn't exhibit the MSB bug. At the end of the initialization sequence though (setting the gamme curve), the bug occurs, doesn't however cause any harm. I've thought about a workaround for this, but didn't implement it yet (because it works without it it, too) -- You might be able to group register writes and such in groups of at maximum 16 bytes, and only the MSB of the first byte might be corrupted of it's from 0x40 to 0xbf. So, if the first byte isn't in that range (known good value), then the entire transmission will be bug-free. Thus you may be able to correctly write to a register between 0x40 and 0xbf be first placing a write to a lower reg (0x00-0x3f e.g.). Oh, and another hint: You can pretty much drop-in the initialization routine from here if that's where you're stuck :)
Just out of curiosity - have you tried the hardware SPI? There are issues with that, too (MT7688 hardware has a bug in full duplex transfers, and the driver needs a patch to at least support half duplex). The speed should be much better here (after all, that SPI bus is used to get data from and to the flash).
Please, by all means, if you have any resources on how to easily use the hardware SPI interface on an Omega2+ from C, preferably without having to recompile / patch the kernel or firmware from scratch, I'd like to hear it. All I found was the spio-gpio-driver kernel module and library. I'd be great if you made your own project page about that if you succeed. This and another part of this project will benefit greatly from a faster half-duplex (TX only) SPI.