I read that discussion months ago.
The last message was 5 months ago.
It's only 'issue need to be fixed', 'somebody has temporary testing fixing lib'...etc.
There is no official fix or update from Onion.
I don't think it's a solution for normal users.
@luz Thats the thing. Even if I use different GPIOs, I never can create a different bus/deviceID interface. I always get an error upon spi registration: spi_gpio_custom fails. I have that package properly installed, though.
I tried a number of solutions. Here’s what worked and what didn’t. “Worked” here means that the Omega2 booted correctly and then successfully drove the DotStar LED strip via the SPI interface using Python code linked above.
I found that I had to connect the output enable pins of the 74AHCT2G125 to ground. That surprised me, as I expected that they would have to driven by the Omega2 SPI CS1 pin, allowing the Omega2 clock and data pins to float while the Omega2 was booting. But with the OE lines soldered low, it worked, booting and then driving the LEDs via SPI.
I soldered the pins of a mini-expansion board as described in the original post above, wiring the +5V from the DotStar power supply, via the connector cable to the 5V pin of the USB A socket on the mini expansion board. It's large enough to be probed/soldered to. [Note: With this setup, power is now supplied by an external supply. Do not connect to a laptop using either USB port.]
I sent this question to Onion tech support, but received only a note that it would be forwarded to technical staff.
it looks like the Omega2 headers are labeled "A" and "B" and numbered left to right. Diagram here
It is probably possible, but SPI on the MT7688 has enough quirks, along with the current state of the software stack, that it may be quite a challenge to tackle this in a pioneering way, unless someone has already gotten your display or a conceptually simpler one working.
An idea you could consider would be using an Arduino (or bare ATmega or some even cheaper MCU) to act as a serial-to-SPI bridge, such that you could just write data out the serial port and the Arduino would turn that into commands for the display. Wasteful of hardware perhaps, but if it transforms the project into a more familiar one it could be beneficial. Note that in doing it that way you also abstract out the Omega entirely - you can probably run your program on your development machine itself displaying through the Arduino while you work out the details, and only bother with cross compiling and installing it on the Omega module occasionally as a check. You also end up able to replace the Omega module with whatever platform seems interesting next year.
So, thanks for pointing me in the right direction !
I now can drive my led strip ... but only the first 16 values !
If I do :
values =  * 16 # 16 or any lower number
values = 255
values = 0
I can see the led flashing.
But if instead of 16, I use a bigger number, I get :
onion-spi:: Trasferring 0x00, 17 bytes
ERROR: SPI transfer failed
and the led doesn't blink anymore (I have way more than enough rgb leds, and they all work, so it shouldn't be a problem from this side). Also, I only switch one ON at a time, not to draw too much current.
So I told myself that maybe the Omega wasn't able to send more than 16 bytes, so I tried to directly send values to the pixels using their addresses, but this method doesn't work as expected (as I expected, at least). I get :
spi.writeBytes(5, [255, 0, 0])
# does the same as this :
spi.write([5, 255, 0, 0])
# instead of being roughly an equivalent to this :
spi.write([0, 0, 0, 0, 0, 255, 0, 0]) # or more exactly that wouldn't set previous values to 0
Am I missing something about SPI in general, or is there something about Omega's implementation? Adafruit's implementation for SPI doesn't contain any writeByte() equivalent, only a write(), so I can't really compare the way the bits are assigned...
@igotit-anything Use the SPI functions to read, and use the Ethernet socket functions to send. You have lots of details to clarify, for example the use of a TCP or UDP port. Plus, at that rate, WiFi may become a bottleneck... Perhaps you should consider the use of an Ethernet cable instead.
Unlike uart to wifi, it may be needed that low level C coding shoud be taken.
My application should be wireless TCP socket between two omega2 modules. The one is a station with tcp server and the other is an access point with tcp socket client.The distance between two modules is under 10meters.
I can not find the information about real maximum throughput using omega2.
Just I guess that the 10Mbps throughput can be achieved via omega2's 802.11n wifi.
@yaseen-almanna From reading the data sheet for the MAX11665, it looks like it should be possible to access it using SPI. While I am not highly familiar with SPI usage on the Omega, doing a quick search shows that there are available opkg packages. It may be worth looking at the following packages:
Additionally, for ADC, it may be worth looking at I2C based ADCs. I have successfully used the following that uses I2C connected to my Omega: https://www.adafruit.com/product/1083
Though I don't actually use it myself, there is an opkg package for this:
Looks like your connection to Onion Community was lost, please wait while we try to reconnect.