Posts made by luz

@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.

@Paul-Chabot: From the datasheet you linked, these UCS1903 chips are close relatives to the WS281x family of LED chain chips.

To generate the required signal with SPI, you'd need to have a SPI interface available exclusively for the purpose (which you don't on Omega2), and you need to have tight control of the SPI to send a long uninterrupted stream of data (which usually works on Arduino&Co, but is difficult on a Linux system).

But luckily, there's hardware better suited for the task than the SPI in Omega2's MT7688 chip: the PWM unit. It's still a bit tricky to meet all timing constraints, but definitely possible. I know because I wrote a kernel driver named p44-ledchain exactly for the purpose ;-) I needed it for Omega2 based projects like this (with 200 WS2813 LEDs).

Now, the UCS1903 has slightly different timings specs than the chips already supported in p44-ledchain (WS2811, WS2812, WS2813, P9823, SK6812). Still, I think it should work with the P9823 setting. If not, just let me know and I can add another option for the UCS1903 chip to the driver.

If you want to give it a try:

Install the driver (needs --force-depends because there's no 100% kernel version match):

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*

Then load the driver and configure it for a chain of 100 P9823 (see here for detailed description of the module parameters):

insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain0=0,100,3

Now you need to configure one of the GPIO pins to provide PWM0 output (GPIO 18 or 46 have that option):

omega2-ctrl gpiomux set pwm0 pwm; # for GPIO 18
omega2-ctrl gpiomux set uart1 pwm01; # for GPIO 46

Finally you need to connect your DIN of the first UCS1903 in the chain to the PWM0 output pin of the Omega2 (GPIO 18 or 46). As the Omega2 is 3.3V and the UCS1903 is 5V powered, the high level coming from the Omega2 might not be sufficient for the UCS1903. In my experience with WS281x chips, it can work sometimes, but not reliably. So the right way to do it is adding a level shifter such as a 74AHCT1G125.

Now you can just write a string of RGB values into /dev/ledchain0 to control the LEDs, for example:

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

to make the first LED red, second green, third blue.

There's more info and details in this forum thread

To debug things, it often helps to start at the lower level. Unfortunatley, these days we're a bit prone to the "libraritis disease". Libraries are fine to get things done, but they also add complexity and layers hard to see through when something does not work.

There is no need for any library at all to test basic GPIO functions!

There's the sysfs interface to gpio, built into the kernel. It's not complicated. To test if you can actually switch on a LED connected to GPIO0, you do:

See if GPIO0 is already made available (by another piece of software) for user space control:

ls /sys/class/gpio/gpio0

If you get "No such file or directory", then it is not yet available and you need to "export" it, see next step. Otherwise, you can skip the next step.

"Export", i.e. make GPIO0 available for controlling it from user space:

echo 0 >/sys/class/gpio/export

If you get an error here, some kernel level driver already claimed that pin for something, and neither you nor any user space library will be able to control it. In that case, you need to figure out what you have installed already that might want GPIO0 for itself. On a fresh Omega2, GPIO0 is available.

If you got so far, GPIO is available for direct control.

To make it an output:

echo "out" >/sys/class/gpio/gpio0/direction

To switch the output to high level (~3.3V):

 echo 1 >/sys/class/gpio/gpio0/value

To switch it to low level (~0V):

 echo 0 >/sys/class/gpio/gpio0/value

If your LED does not turn on and off this way, then you need to debug the wiring. No library can help before that works ;-)

@cas said

Is it possible that an electrical circuit is not even being created unless an O2 is actually installed?

When you look at the minidock schematics Onion has published on github, you see that

• the CP2102 USB-to-serial chip is unconditionally powered from the MicroUSB connector's 5V. However, according to its datasheet in suspended mode (not operating) it only draws max 100µA, not noticeable by far with a charge doctor type meter. However if it is not suspended, it will consume 20-26mA. That probably happens when the micro USB is not only delivering power, but is connected to an active USB host (but I am not sure).
• the linear voltage regulator for the Omega2, the BL1117-3.3, is powered only when the power switch is on. But then, according to its datasheet, it draws a quiescent current of 4 to 8 mA (0.008A). Still too low for the charge doctor to see.
  Bottom line - as long as the CP2101 is not active, everything you see on a charge doctor type meter is what the Omega2 itself consumes.

With the proprietary driver the Omega2 ships with - sadly, yes, the AP is always on.

But with the open source mt76 driver, disabling the AP is no problem.

And note that mt76 has matured a lot since this thread started a year ago! As a true open source project, there are people working steadily to improve it. There are updates every few weeks to make it better. For my needs, mt76 has become stable enough already many months ago. And it is a much cleaner setup, using standard cfg80211. I like it way better than these sad proprietary chunks of code tied to a specific kernel version and thus blocking all other progress!

@Miguel-Miranda no, I just used a free GPIO to enable rs485 drivers from my highlevel software. That's far from optimal of course, because I have to estimate how much time my outgoing data will need and time the GPIO accordingly. But for my application (Swiss railway split-flap displays) this was good enough.

Of course, that's something that probably could be done better at the driver level. I haven't dug very deep, however I'm not sure the UART hardware could provide the needed all-data-is-sent-IRQ. The way MediaTek integrated the UARTs is a bit sad, because they did not provide a way to multiplex the native UART handshake signals to pins.

It would be nice if proper HW handshaking could be done entirely in software, though. I'm open to proposals how that could work ;-)

@brolly759 said in Queue System?:

I am working in NodeJS and started to implement a queue system. I have the que system writing to files on the tmpfs directory. Is the tmpfs directory memory resident so I dont wear out the flash?

Yes, tmpfs is in RAM, so no problem with writing a lot there.

It seems that reading from the que is slower than writing, maybe 3-4 files a second vs writing files at about 50 a second.

That is strange - I see no reason why there should be any noticeable difference between reading and writing to tmpfs.

Of course it depends on the exact access pattern - if you write in large blocks at a time but read in tiny chunks, then there will be a performance difference due to system call overhead etc.

@cas said in GPL Source Code:

I think it's a reasonable assumption that there is a private repo for the oboo clock (closed source) and all the current application and firmware development effort is taking place there and is focused on that.

Very likely, yes.

That they want to keep the oboo-specifics closed, I can understand.

But what I really think is plain stupid, even from a commercial point of view, is that they do not work in the open improving their OpenWrt/LEDE tree for the Omega2 platform.

They could serve both the oboo project and their Omega2 customers! But how they do it now alienates the Omega2 maker community, instead of involving it.

It's "wow, they build something cool and professional based on the Omega2 platform, I could do that, too" vs. "oh, they are no longer interested in the Omega2 platform they sold me and doing something entirely different".

I hoped the oboo clock would help bringing the Omega2 forward as a platform. Now it looks like the result will be the opposite :-(

Really, @onion, it's not that hard!

I can tell because I'm doing exactly this. I do commercial products based on Omega2+LEDE 17.01 for a living. And I have a number of fully open fun projects also based on the same platform (pixelboard, a LoRA gateway, a DC motor controller...).
Only a few packages related to my commercial products are not public (such as the site specific updater tool). The rest is the same for all projects, and open! Including things like a kernel driver for WS28xx LED chains or making i2s sound work to play MOD sounds...

And guess what? I'm doing it that way primarily because it is the most efficient way to get stuff done! I could not do all that if I had to worry about a separate LEDE for each project, all the back- and forth merging etc.

And OpenWrt/LEDE is a phantastic environment to do exactly that. No problem to have a public and a private feed to organize different projects. The only thing I had to do, to make my workflow really smooth, was to write a little shell script that allows to apply a diffconfig plus some tree-wide patches (e.g. this one to make SPI work) for a certain project to a virgin LEDE checkout.

This way I can make use of the enormous and continuous work that goes into OpenWrt/LEDE every day, and others can make use of my work as they see fit.

I really don't get how Onion can miss out on the benefits of a more open development.

@Lachlan-Peter In my experience, the minimum quantity for Omega2S is a tray of 50 pieces. There also seems to be a sample pack of 5 at a higher price per piece. IMHO both very reasonable offers for starting a small product.

As I already bought 500+ Omega2S by now, I can‘t really tell how restrictive Onion is in granting access to their b2b ordering site for new customers. But I would guess they will respond to a professional inquiry sent to sales@onion.io ;-)

@Chris-Ouellette in the meantime (it‘s a year later now) they have published their LEDE tree.

But yes, that does not include the proprietary WiFi driver. AFAIK it is allowed to have such a closed driver, but I totally don‘t get why they put their effort into hard to maintain and use proprietary stuff instead of helping to improve the open mt76 wifi driver! mt76 has improved a lot over the course of last year, but it could still use some refinement regarding performance and sometimes stability of connections.

Unfortunately, looking at the github repo, there seems not much going on regarding Omega2 firmware development anyway. The last commit is from September, substantial changes more than 6 months ago.

@ccs-hello actually, there is a 4-port switch and a total of 5 ethernet ports inside the MT7688. The problem is, only the pins for a single port are available on the Omega2. With the Omega2S (the SMT version), all pins are available and you could use the 4 other ethernet ports.

Maybe the pins for GPIO0 and 1 are not set to GPIO mode.
Have you checked the pin multiplexer with omega2-ctrl gpiomux get?
This lists the current function for all groups. GPIO0/1 are in the i2s groups, so this group's line should show gpio in sqare brackets. If it does not, use omega2-ctrl gpiomux set i2s gpio to switch those pins to GPIO.

@Andreas-Lundgren

Have you tried the --force-remove option with opkg remove?

@Chris-Ouellette

@Chris-Ouellette said in Omega2 current defects:

@wdu @luz

Odd that the Onion guys weren't able to get half duplex mode working.

Indeed. As @wdu points out, unreliable operation of the hardware in half-duplex would make SPI flash unreliable, which isn't the case. So I guess it must be a matter of having the right drivers.

What is the best way to get a kernel image with the SPI fix? If you could point me to the information on how you created your kernel image I would greatly appreciate it.

I always build entire OpenWrt/LEDE images tailored to my device's needs. I documented the way to build a full image (that of my TTN gateway) here. It's not entirely trivial, but should be doable with some basic Linux command line experience. However the result is a specialized image, which will boot with any Omega2 into console, but lack most of the Omega tools (no web-UI, no wifi setup tools etc.).

So you might want follow more generic LEDE build instructions from Onion's docs, and just apply the SPI-related patch before running the build.

@wdu's mods seem to be more thorough and offering nice additional features (GPIO baseds CS lines, cool!), but so far I haven't found the time to test that, and can't provide help for that. I'm sure @wdu can ;-)

Of course, the best solution would be Onion adding one or the other patch to their firmware, and actually release it!