@luz Thank you for detailed explanation. I probably will use soft spi because of parallel usage needs of two devices. it will be too slow but there is no other chance. I will need to make some hardware design changes.
But i couldnt understand why hardware spi count is limited in openwrt side. i know MT7688 has two hardware supported spi cs pin but it could be increased by openwrt side as adding gpios as cs with hardware spi.
Thanks again @luz
@haythem I'm not sure you need to go down the road of RTOS for multithreading on Omega2, the specifics of your design would dictate this, so you'll need to provide more specific details.
If it's a button you want to monitor, have you looked at this example:
@eblasband closing the loop here:
Omega2S Hardware Design Guide v1.1 was just published with an updated section on the WiFi antenna
Let us know if that's more clear and if there's anything else missing from the documentation that would be helpful
Thank you for such an excellent reply. It points me in the right direction. We may be doing a custom U-Boot and kernel build anyhow. I am starting to become fond of this platform. I just picked up the Omega2S a couple weeks ago for the first time and had the streaming USB UVC video working on day one over Wifi.
Hi guys. Thank you everybody so much for all these answers, it is so nice to see that the community is still really active. I come back on the problem after a few months because I would really like to use this Onion again. Now when I connect it to the USB the computer detects it but in serial connection nothing happen and the ligh on the Omega doesn't even turn on. I bought a CH341A to flash it with SPI, there is someone that knows how should I do it and which firmware should I flash? (Sorry but I've never done an SPI flash before)
@optech Depending on the higspeed mode used, the MT7688's UART may not be very precise at high baud rates. If you have a look at the MT7688 datasheet on page 157ff, you see that for 115200 there's a divisor of 14 (down from 26Mhz) for the UART clock (which is divided by 16 to get to the baud rate) when highspeed_mode=0.
So the effective baud rate you'd get is 26E6/14/16 = 116071.
I don't know what mode is used in uboot (and linux tty driver, for that matter), but I would not be suprised if it was the simple non-high-speed mode.
Apparently, FTDI chips (I only use those, because of no driver hassles for those on macOS) are a bit more tolerant than others to inprecise baud rates. So I never experienced this in my daily work (I have >1000 Omega2 based products in the field). However, for a project I had to calculate the exact sending time for a byte stream @ 9600 baud - which turned out to need adjustments exactly due to not quite precise baud rate…
@francisco-vieira I agree with @crispyoz, this sounds like a handshaking issue - my guess is in hardware.
To check on this, you can use the devmem command to read the UART0 status registers. I would start with the Line Status and Modem Status registers.
See the MT7688 datasheet for more info on the registers, and run devmem --help on the command line to see how to read the registers.
@T-NT My understanding is that the Oboo clock is a consumer device, so I'm not sure why @Onion would provide documentation on how to use the device from a technical perspective. When I remove the casing from my Blackberry KeyOne I don't expect BlackBerry to provide me with documentation on how to gain shell access to the device.
Since the Oboo utilises an Omega2S+, we can refer to the relevant documentation.