Posts made by luz

Hi @Alexandr-Didenko !!!!! :-)

• V-NET is not connected on the Omega2. It is here for compatibility with the Omega1 which had different ethernet PHY logic that needed a bias voltage on the center taps of the ethernet transformers. I started with Pixelboard before the Omega2 came out...

• ETHLED_AMPEN is just a GPIO I'm using for switching the audio on and off in the Pixelboard as it is now, but I had variants w/o audio so I also connected it to the ethernet jack's LED. The idea was to have it show ethernet activity using the ledtrig-netdev LED kernel module. I tried once briefly, but it didn't work right away.

• PWM on G46: the pin mux in the MT7688 has several options of exposing the PWM outputs, not just GPIO 18 and 19. A while back I posted a annotated pinout of the Omega2 (and 2S) with all possible pin functions labelled - that helped me a lot to design Omega2(S) circuits.
  You can switch the uart1 group to pwm01 with omega2-ctrl to get PWM1 on G46.

Don't forget that the MT7688 SoC also has 4 very precise hardware PWM units built in! On the Omega2(+) though, you can only use 2 of them (PWM0 and 1) because it's lacking pins for PWM2 and 3 - on the SMT Omega2S, all 4 are available.

These PWMs would even work with standard Linux /sys/class/pwm interface, if onion had enabled them in the device tree - which hasn't happened yet despite discussing it about it a year ago.

But there is a nice tool written by @Alexey-Avdyukhin for controlling the hardware PWMs - see his forum post here.

@Alexandr-Didenko said in How to control WS281x RGB LED strip?:

@luz I/O - MCP23017 - i2c. My plans - to sell it.

Let me know when it becomes available :-)

I don't know what I do, that WS281x to work :)
Honestly!
It suddenly began to work.

:-)

I think that oscilloscope give interference.

Could be, depending on the probe. Anyway, I'm glad you have it working now!

@Alexandr-Didenko nice device! I assume your I/O are i2c or SPI based? If so, your hardware could run as a digitalSTROM gateway, just by running my vdcd on it. Any plans to open source your device? Or produce and sell it?

@Alexandr-Didenko nice device! I assume your I/O are i2c or SPI based? If so, your hardware could run as a digitalSTROM gateway, just by running my vdcd on it. Any plans to open source your device? Or produce and sell it?

BTW: how did you get the WS281x to work, finally?

@Alexandr-Didenko I have no real idea why it does not work reliably in your case (it does in mine).

To make sure the timing works ok, you can check the stats of the ledchain driver:

root@pixelboard:~# cat /dev/ledchain1 
Ready
Last update: 0 repeats, last timeout=0 nS, max irq=9484 nS
Totals: updates=99756463, overruns=0, retries=3745, errors=4, irqs=2079220056

If you have a high errors number, then something (most probably another driver) is blocking IRQs too long, causing incomplete LED chain updates. Getting some retries is normal. In my example, the number seems high (3745) but that's over a uptime of 46 days, with 99 million full chain updates, so the retry rate is 0.0038%

However, I don't see how even lots of retries/errors would cause anything else than the chain not fully updating. But not completely chaotic colors.

So I still suspect something in the hardware. The really sharp downwards spikes seen on your scope screenshots look suspicious. I can't really make sense of these, occuring only every 5th falling edge.

How do you power the LED strip? Direct fat wires from the LED strip to the PSU, for +5V and GND?

@Alexandr-Didenko
It definitely sounds like a hardware problem.

This is exactly what happens when the logic high output level of the 3.3V Omega2 is just at the minimum level for 5V WS2813 to be recognized.

For testing, it might help to lower the 5V supply a tiny bit (4.9V instead of 5V, easy to try if you have a lab power supply), because this also lowers the logic high threshold of the WS2813 chips a bit.

A logic level converter is certainly the way to go to make that reliable - but the type you chose is most certainly way too slow for the WS2813 signal. These bi-directional thingies are good for serial speeds (many offers do not properly spec, but those that do say max 28800bd). The WS281x signal is in the 1mbps range, however.

For that you want to use a unidirectional level shifter, such as the 74AHCT125 (or its single-gate version, 74AHCT1G125). I used that one successfully for my "pixelboard", see schematics, with 200 WS2813.

@CAP-33 did you connect the Omega2 via Ethernet?

Because Ethernet needs its own MAC-Adress and that used to be the WiFi-MAC (which is on the package) plus 2. But you say it's only +1, maybe this has changed with the new firmware/WiFi driver version?

The "Unknown" just means your router does now know the MA-M/OUI-28 40 A3 6B Cx xx xx belongs to Onion Corp.

Routers usually know some OUI's and associated names of larger companies and can display it, but apparently Onion is too young or not big enough for your router to know it :-)

@Alexandr-Didenko said in How to control WS281x RGB LED strip?:

@luz said in How to control WS281x RGB LED strip?:

opkg install --force-depends kmod-p44-ledchain*

Error.

Yeah, that's a bit confusing. opkg displays the error (which is more of a warning in this case, meaning that installation would have failed if the --force-depends option was not set) altough the operation has succeeded.

So everything's fine so far ;-)

Now for the signal disappearing after reboot: omega2-ctrl settings are not permanent, and activation of p44-ledchain via insmod isn't, either (only installation via opkg is!).

To get the ledchain ready automatically after boot, just put the omega2-ctrl and insmod lines into a startup script.

/etc/rc.local is a good place for that, unless you have your own startup script for your application, where you can put such initialisation code as well.

@Alexandr-Didenko said in How to control WS281x RGB LED strip?:

I searching in this forum and don't understand.
On the RPI I installed neopixel.
On the Omega2 neopixel don't install.

Omega2 is not a RPi ;-)

But there's a solution, see this post.

As the thread is a bit long with maybe too many details decribing the research and development of that solution, here's a quick summary:

There's a kernel driver called p44-ledchain for driving WS281x ledchains. You can install it as follows:

cd /tmp
wget http://plan44.ch/downloads/experimental/kmod-p44-ledchain_4.4.61%2B0.9-2_mipsel_24kc.ipk
opkg install --force-depends kmod-p44-ledchain*

And then activate it (this is for up to 200 WS2813 connected to PWM0):

insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain0=0,200,2

You also need to enable PWM0 output on GPIO18 pin

omega2-ctrl gpiomux set pwm0 pwm

Now you can send a string of RGB values, for example:

echo -en '\xFF\xFF\xFF\xFF\x00\x00\x00\xFF\x00\x00\x00\xFF' >/dev/ledchain0

...makes the first LED white (FFFFFF), the second red (FF0000), the third green (00FF00) and the fourth blue (0000FF). These codes are the same as for web colors.

For more info, have a look at the p44-ledchain README and read the original thread with experiences from other users

@György-Farkas That „buggy DT“ message is here already for a long time. It‘s harmless, it only indicates a mismatch between the device tree (DT, the structure that informs the linux kernel about the hardware it is running on) and what the spi driver expects. That should be investigated/fixed/cleaned up some time, but as the driver does explicitly detect the situation, it does not crash, but just outputs the warning and then works normally. At least in all the FWs where I saw this message so far.

So I doubt the crash you see has to do.with that DT bug, but is caused by something else spi related. I still might be wrong, not having fully understood what exactly is wrong in the DT (otherwise, I‘d fixed it in my LEDE/OpenWrt builds long ago and let you know ;-)

@Janus-Sanders I made a KiCad footprint for the Omega2S myself, it‘s available in my public KiCad library, among other parts.

The footprint is of the „manually solderable“ variety (pads reaching out from under the part a bit more than what would be necessary for industrial SMT soldering) - because I use it for prototyping.

The manufacturer who produces my Omega2S based device used it as a starting point for his footprint (But I have no data for that, it‘s in a commercial format anyway, probably Altium)

@Andrew-Naumenko @sonus yes, the "driver" for these simple chips does not need any code, or at least almost none. However, it must describe the chip to the ALSA/ASoC subsystem, exactly because it needs to know if sound samples sent out via i2s should be signed or unsigned (furthermore, there is big endian and little endian byte orders, and possibly other details). Then ASoC can produce the correct type of samples.

That's the theory. Looking at what we have, I'm getting confused. For one both the MAX98090 codec as well as my MAX98357A codec claim support for signed samples (SNDRV_PCM_FMTBIT_S16) in their snd_soc_dai_driver structs. So IMHO with both codecs, I'd expect the samples coming out signed, and should fit the TDA1543.

I have no idea why this is not the case. But I suspect that there might be things missing or wrong in the whole setup, because for example, aplay --dump-hw-params is supposed to list the available formats, but at least on my omega, it just hangs forever. And further up in the thread @Andrew-Naumenko said forcing U16 samples with mpg123 just crashes the Omega. Also, poking around in /proc/asound/card0 leads to many files that just return the string closed. Again, no idea if this is ok or not, but it looks a bit strange.

ALSA is complex, and ASoC is relatively new (and we're using kernel 4.4, while 4.18 is current), and we're probably the first few trying this with the MT7688 at all - many chances for bugs here and there. I'm no way an ASoC expert, and also don't have the time to get one anytime soon. I just tried until my MAX98357A produced sound (from hxcmodplayer), and shared the procedure (see above).

In general, my hope is that when the next OpenWrt release uses a newer kernel, we'll maybe see things working that don't work now.

As for building your own kernel modules - @Maximilian-Gerhardt has created an excellent and detailed tutorial for that, here.

@sonus: In ASoC (which is a subproject of ALSA, the Advanced Linux Sound Architecture), there are a lot of codecs (driver kernel modules) for various sound chips. The MAX98090 module obviously is made for that chip, and not others with different features.

For the Linux 4.4 kernel currently in use for LEDE 17.01 on which Onion's firmware is based, the available ASoC codecs are in the sound/soc/codecs subdirectory of the 4.4 kernel tree.

Of all these codecs, the current Onion build includes only those for WM8960 and MAX98090 (you can see that in the definition of sound-mt7620 which is in target/linux/ramips/modules.mk in Onion's LEDE source tree.)

You can see the changes @Lazar-Demin made to add the MAX98090 in his commit here (only the WM8960 was included in original LEDE 17.01)

Further up in this thread you can read about how I added the MAX98357A for my own use, and got it to work thanks to help from @sza2-sza2.

Probably, many of the other Linux 4.4 ASoC codecs would work with the MT7688's i2s hardware too, but one has to try to find out.

However, for the TDA1543, I see no SoC codec yet, neither in the 4.4 tree nor in the latest 4.17 tree...

Probably it would be doable to make a codec - have a look at max98357a.c, it consists mostly of config parameter tables, and almost no code. The hard part is probably learning to understand what these parameters mean ;-)

@Marti-MG Thanks for this information!

I made a separate mode for the WS2811 because the timing specs from the datasheet I had were definitely not compatible with those I knew working with the WS2812/13. But I had no WS2811 to test back then.

I'm not too surprised that apparently the datasheet is not correct. I saw the same for WS2813 which had the T0L time specified 300nS, which is definitely not working with real WS2813 as I found out.

The modes are actually just timing numbers in a table in the driver, see line 157 in p44-ledchain.c. So it would be simple to nudge the WS2811 entry towards the WS2813 timing until it works.

For the time being, I just added a note to the p44-ledchain README.md to also try WS2813 mode in case WS2811 does not work.

@Siddharth-Velappan Unfortunately, it is not possible to switch on phy1..4 individually. Only phy0 can be switched independently; the other 4 always are all in phy or all in GPIO mode.

The AGPIO_CFG register layout suggests that there is a separate disable bit for each phy, but that's not the case. See the note in the MT7688 datasheet on page 59 reading "When any bit of bit[20:17] is set to 1, P1 ~ P4 will be swiched to digital PADs together."

It seems to me that this is one of the small oversights in the MT7688 that probably happened when MediaTek had to "IoT-ze" a former router chip design (too) quickly. Other examples of this are the SPI not working correctly in full duplex mode and the PWM units that are not connected to DMA...

JFYI: I2S support has landed in official Omega2 FW: https://community.onion.io/post/16473

@Lazar-Demin glad to see @sza2-sza2's and my I2S experiments/patches from last July found their way into actual Omega2 firmware ;-)

@Jonathan-Zwart I have a solution to the 10.13.1 problem with m4 you've encountered (see my answer to your post in the openwrt forum and/or the question/solution in the lede forum from late 2017)

But it does not seem to be related to the OP's problem on WSL to me. From @Elliot-477569 's last post I rather conclude his original problem was a file system issue.

I still have a unresolved strange issue with make leaving out parts of the build of the mt76 wifi driver when building LEDE master on macOS 10.13.1, resulting in an image with everything working, except that the entire mac80211 infrastructure is missing. The reason behind must be a similar subtlety like in @Elliot-477569 's case on WSL, that's why I subscribed to this thread in the first place... Any ideas are welcome ;-)

@Debjyoti-Acharjee : What CP2102 driver did you install? For me, this one directly from Silicon Labs works fine on macOS 10.13 and the Omega dock.