No, you're not the only one who stumbled across this. It's 5 years later, and the Omega still has issues joining and staying joined with, a network with apostrophe's in the SSID?
We are shipping 250 end items per year to paying customers - paying a lot, I might add. Anyone know of a solution that doesn't require a custom hack job into each product that has already been shipped? Anyone from Onion listening?
@luz Thanks. 5100ns Maxretries value(default suggested for ws2812 on readme Github) by this I meant the same as you said, could not convey though.
I checked the hardware design, we dont have level-shifter emplied. I will try with level shifter and let you know here.
I appreciate your prompt attention. Thank you @crispyoz @luz .
@dixit I just noticed this post after answering the other one in the p44-ledchain thread
Hearing that you had similiar problems with the ws2812-draiveris driver as with my p44-ledchain, I can conclude that the problem is most likely not the timing, but the hardware (missing level shifter?).
Because ws2812-draiveris always meets the timing for the WS28xx - as you might have seen when porting it, it simply locks all interrupts and then bit-bangs the data.
While this is good for meeting the LED chip timing (and simple to code), locking interrupts for dozens of milliseconds is a cardinal sin in a Linux driver. On the original AR9331 CPU (Omega1), where ws2812-draiveris originates from, this was the only way to get such SmartLEDs working at all, so ws2812-draiveris is as good as it can get on that chip.
However, on the MT7688/Omega2 with its PWM units, the p44-ledchain way to do it, without locking interrupts, is the way to go. And that works easily, at least with WS2813 or WS2815, with all 4 PWMs running in parallel with 1000 LEDs each.
I spent some time implementing refclk in my platform driver, but then I found that sound/soc/ralink/ralink-i2s.c seems to have all that done already. So it seems like my ultimate solution is just to comment out everything having to do with clocks and hardcode the expected 12 MHz frequency.
I forgot about Banngood. Went with this one:
Banngood always looks a bit suspicious to me but I did order some items there about 3-4 years ago and it did arrive. So, hopefully this sensor works ok.
Two years later: Just in case anyone runs into that problem, I found a solution that work from linux userspace:
In the kernel messages (which can be viewed with the dmesg command), there is a line like:
[ 0.358842] m25p80 spi0.0: w25q128 (16384 Kbytes)
or (in newer OpenWrt versions):
[ 0.639801] spi-nor spi0.0: w25q256 (32768 Kbytes)
This is a message from the spi-nor kernel driver after detecting the actual flash chip. So it is not dependent on the flash size that is baked into the firmware image, but shows the real size of the flash chip. Both of the example lines above are from a firmware made for the Omega2. The first is run on an actual Omega2, the second shows 32M so it is a Omega2+.
The only gotcha with this is that the dmesg buffer is not infinite and will loose older lines when too many new ones arrive. This means detecting the flash chip size needs to be done shortly after startup.
So I put the following line into a startup script (e.g. /etc/rc.local) :
dmesg | sed -n -r -e '/spi0.0: .*w25q/s/.*(w25q.*\))/\1/p' > /tmp/flashchip
With this, the chip name and size is captured and can be read any time later from /tmp/flashchip to detect an Omega2(S)+ vs Omega2(S).
Finally - Solved!
@CyrilSneer I have some string sitting on my desk. Can you tell me how long it is please?
This is the same as your question, there is no specific information so it is not possible to answer your question. As a first step perhaps you can share:
What language you are using (script/C/python etc)
A sample of your code
How you are building your code
What model Omega2 are you using
What firmware version you are using
All the basics
@rahul2413 looks like you're trying to do a full-duplex SPI transaction. The Omega2 family does not support full-duplex on the hardware SPI bus.
Half-duplex transactions will work fine. More details in this FAQ post.
If you absolutely need full-duplex, you can try using a software-based SPI bus.