Best posts made by luz

Here's an annotated Omega2 pinout which lists all possible pin functions and the actual MT7688 pin names (in boldface) as found in the datasheet. The red ones are those signals sampled by the MT7688 at reset to determine operation mode, so these must not have heavy load and/or pullup/downs.

I did that pinout for deciding which pins to use for what when designing a PCB for a Omega2 based project of mine. I hope it might be useful for others

[Update: the latest version, covering Omega2 and Omega2S, including additional info about pins with bootstrapping functions, can be downloaded here]

[Update: in case you are looking for a similarily annotated pinout for the Omega2S, look here]

@Luciano-S. It's a good thing LEDE and OpenWrt devs join forces again, sure!

However, it will not make any difference for the Omega firmware.

What would make a difference was when @Onion would finally fully open source their firmware build as promised, so that member of this community and Onion devs could join forces!

But as long as everything hinges on Onion folks finding time for it (which they don't, because they are too busy, and understandably so), progress stalls, and community enthusiasm is fading.

Onion, please allow us to help!

@Koos-du-Preez Here's an Eagle library which has Omega1 and Omega2 in it, plus a few other components such as the very affordable HLJ-6115ANL Ethernet connector with magnetics included.

I've been using this for some prototypes and had the PCBs made at oshpark.

The prototypes worked, so parts should be ok, but no guarantees…

PS: and don't ask me anything about Eagle - I've tried it only for that project, but moved to open source KiCAD since. Despite a few quirks I find KiCAD much easier to work with.

The standard WiFi driver for the MT7688 currently included in LEDE apparently neither works reliably, nor with acceptable throughput at this time (That driver is true open source work in progress, contributed by very dedicated LEDE developers in a very hostile field, so I'm not criticizing it at all - it's just not ready yet!)

Onion, for this reason, is using another (proprietary?) driver for the official Omega2 firmware, which works fine.

But using the Omega2 with a LEDE build currently means essentially having no WiFi.

That's how I happily used the Omega2 for in my projects of the last few months (always using wired Ethernet).

But now I'd like to mix the work of these months (e.g. the ledchain kernel module) with WiFi.

Easiest would be if Onion would fully publish their LEDE setup, but unfortunately all forum threads regarding this (for example here, here, here and here) and even contributing just stalled.

Now I wonder if it would be possible to somehow just extract the working wifi driver and use it with otherwise standard LEDE? Any ideas?

Three weeks ago I fixed gpio-irq to work on the Omgea2, because someone asked for it. I posted it as a pull request on github for OnionIOT.

But as I had zero feedback so far, I am wondering if creating a pull request maybe isn't the right way to bring contrubutions to the attention of the @onion @administrators. Should we notify specific persons directly? @Lazar-Demin? @Gabriel-Ongpauco? @Boken-Lin?

I mean, I'm not expecting immediate pulling, but some indication if the contribution was seen at all, and if so, whether it is welcome or not - that would be great!

BTW: just a few minutes ago, I also posted a pull request for omega2-ctrl as it was missing some useful mux configuration states.

Things are moving! Have a look at the github repo!

This does answer my original question - YES, Omega2 does use LEDE! Great! (see paragraph "the operating system")

Now I hope the LEDE fork actually used for the Omega2 will soon get available. Maybe it will be a while until Omega2 support becomes part of LEDE mainline (fully understandable, preparing and submitting patches takes time).

But please just publish Onion's LEDE fork as-is soon, including the .config. So the community can actually participate and contribute to the ongoing project.

@Luciano-S Sticking to an old kernel just to avoid kernel mismatch can't be the solution either. It all hinges on public availability of the exact same LEDE/OpenWrt tree + config which Onion uses internally for the firmware, that allows building packages against whatever kernel is used on the Omega. So again - development in the open is the key

Some background information about the reason for the "arcing" and "micro-welding" described above:

It is usually caused by inductive loads, like electromagnets, motors, transformers - pretty much anything that is based on a coil of some kind.

Coils have a surprising property - the current that flows through them cannot suddenly change. So if you have a motor running on, say, 200mA, and your relay breaks the circuit, the current needs some time to ebb, it cannot go from 200mA to zero at once.

But how is this possible with the circuit open? There's only one way - the voltage between the now open contacts will rise so high that the current can flow through the air between the contacts! High voltage can ionize air to make it conductive. In small scale this is called an electric arc, in large scale it's called lightning...

In both cases, it's very hot, and happening between relay contacts causes contact material to melt and micro-weld. Even if the relay spring is strong enough to rip the contacts apart eventually, and the relay does not stick, this ruins the contacts over time, and should be avoided.

But how?

If the circuit is DC, it's simple. You just need a so called flyback diode over the inductive load which allows the coil to discharge its energy without generating high voltage.
Note that this is also essential when driving a relay (a coil, too!) from an electronic circuit. If you forget the flyback diode, the high voltage will disturb or even destroy the electronics. See D3 and D5 on the Onion Relay Expansion schematics.

If the circuit switched by the relay is AC, a diode does not work (would short-cicuit half of the time and destroy itself). Instead, use a RC snubber, a capacitor in series with a resistor. For use with 230V AC, ~20..100nF/400V capacitor and a 100Ω/2W resistor works. The snubber consumes some energy of it's own, that's why the resistor should be a 2W type, and will produce some heat. There are also RC snubbers in a single part, like this one.

Hope this help to tame your relay circuits

As a side note: there are circuits where the high voltage caused by breaking the circuit of a coil is the desired result - ignition in combustion engines, electric cattle fences...

@DumTux said in CAN Bus: using MCP2515 with Omega2:

Is there a quick way to check if GPIO11 is released from Omega2's bootloader for general-purpose use?

If you can "export" it via the '/sys/class/gpio' interface (before loading your driver that may try to use it, and possibly block it even if not successful establishing it as IRQ), then it should be available.

However, when you are using unpatched 22.03, the /sys/class/gpio interface (deprecated by now) will have completely strange GPIO numbering: GPIO 0..31 -> 480..511, GPIO 32..63 = 448..479.
So you'd need to export GPIO 491 to get GPIO 11.

I am using a patch on top of 22.03 to bring back the gpio-base DT property which allows to revert the numbering back to what it was in 19.07. New projects should use the new gpiod interface, but this is not entirely ready yet, see my attempt to find out what the status of GPIOs in OpenWrt is.

@tony-ter-neuzen happy to hear you enjoy the freedom of making your own firmware (as I hoped you will)

i did just realize that i'm building SNAPHOT at the moment, but hopefully i'll find an easy way to step back to current stable without hours of tinkering on menuconfig again

Specifically for that, OpenWrt has a very useful mechanism called diffconfig (of course, it originates, like menuconfig, from the Linux kernel's build system). It allows to capture the changes in your .config (the one and only file make menuconfig touches) relative to the target's default configuration:

./scripts/diffconfig.sh >/my/safe/place/my_diffconfig

Now you can checkout another version of OpenWrt, and then:

cp /my/safe/place/my_diffconfig .config
make defconfig

The make defconfig expands your specific config changes in the context of the default config of the current openwrt into a full .config. The result is a config with all the subtleties that might have changed between OpenWrt versions, with your changes on top. Of course, there might be conflicts, but these are much easier to spot and solve this way.

Inspired by this mechanism (and way of thinking it implies), in my various OpenWrt based Omega2 projects, I nowadays strictly refrain from forking the OpenWrt tree, but keep all changes I need as a "diff" (consisting of diffconfig, but also a set of patches to OpenWrt I might need for one reason or another) separately.

After having done this manually for a while, I built a bash script named p44build that automates most of it. With p44build, lifting a project from an older OpenWrt version to a newer one is usually a minor task - IMHO a very important thing for OpenWrt based firmware to avoid sticking with an outdated OpenWrt too long just because upgrading a fork is a pain. p44build also allows switching between targets and projects on the same tree easily.

I think we should precisely differentiate three areas:

• There are bugs in the Mediatek MT7688, affecting SPI, I2S and I2C, see link in @György-Farkas' post above. If you blame Onion for using this chip, then please name a better one in the same price range having at least partially open specs. The MT7688 is nothing more than a slightly IoT-zed router chip. Its ethernet, USB, UART and WiFi hardware is solid, but its SPI was originally designed to connect the flash chip only, and things like PWM and I2C seem to have been added without much care. Sad, but certainly MediaTek's fault.
• There's not enough open documentation for the MT7688 to write solid drivers without a lot of try and error. As said, at least there is a publicly available datasheet (there was none for the Omega1's AR9331!), but it is little more than a list of register addresses and bits. No conceptual descriptions of any of the function blocks, very little context. So the drivers that exist in the open source LEDE stack have shortcomings just because the hardware is not documented properly. On the other hand, those developers who do have more information, are bound by NDAs so can't contribute to the open drivers, e.g. WiFi. This is the sad state of affairs around a only semi-open SoC chip.
• And then there's Onions strange way to (not) communicate all this properly to their users. It took an eternity until the LEDE build and uboot was opensourced, missing a lot of opportunity to get help from initially enthusiastic community members. And now, inexplicably, they don't respond to carefully collected information and hints like @Maximilian-Gerhardt 's excellent summary, and apparently don't update their firmware. IMHO, only that part is the real issue

Bottom line: there are compromises when building a $6 computer. You can argue Onion should have built another RPi instead for $30, but I am very happy they didn't, because once you know the limitations, the Omgea2 and Omega2S are fantastic devices to build small networked devices.

But Onion should actively communicate the pros and cons, admit problems, provide workarounds and quickly integrate work from others for the MT7688 into their firmware.

For example, this patch making hardware SPI usable by running it in half-duplex mode (full duplex is broken in MT7688 hardware).

As a side note: I am very curious to see how they will handle execution of the clock project - they'll need SPI for the display, probably I2S for sound, probably a ws2812 driver for the light bar. Sometimes developing a real application (vs. just cobbling together examples how to do cool stuff) helps improving the basics

Really, this is slowly but surely growing from a inconvenience to a real problem!

Because as it is now, you can only choose between:

• Onion firmware with working WiFi, but no way to add kernel modules and thus limiting the use of cool on-chip subsystems like PWM, PCM/i2s audio etc.
• LEDE firmware where it is easy to compile kernel modules for, but lacks all the great Onion additions and also lacks (at this time, at least) reliable WiFi because the open driver still has reliability/performance issues.

I appreciate that you folks at Onion have worked very hard getting the hardware produced and shipped!

But not opening the Onion firmware build to the LEDE-savvy members of the community actually blocks contributions to the platform!

Cool things made by community members are limited to those (relatively few) who are willing to use LEDE and accept compromises regarding WiFi and Onion environment. The regular Onion firmware users cannot profit from these efforts. Same for detail knowledge - those that can go and understand details, and also potentially fix bugs, can't help those users with the regular firmware.

So @Boken-Lin @Lazar-Demin @Gabriel-Ongpauco @James-Liu and the entire @onion team, please give this some priority!

The best reference for this is the section "pin sharing schemes" on pages 25ff of the MT7688 datasheet.

As the omega2-ctrl utility was obviously created from a corresponding utility for the Linkit Smart, not all of the pin groups actually make sense for the Omega2:

• uart2 group controls GPIO pins 20 and 21 which are not exposed on the Omega2
• refclk group controls GPIO pin 37, also not exposed on the Omega2
• groups ephy and wled are not relevant on the Omega2 either (these are for enabling ethernet LEDs and WLAN leds, all on pins not exposed).

What you could add to your nice diagram:

• pwm0 controls GPIO18
• pwm1 controls GPIO19

The spi_s group is wrong in your diagram, the pins you labelled are the spi (without _s = slave -> SPI master). However, omega2-ctrl does not offer switching these pins for good reason - SPI interface is used to connect the on-board flash chip so these cannot be switched while Linux is running.
spi_s are pins GPIO14..17, of which 14 is not exposed.

The spi_s group is especially interesting, because these pins can also be switched to carry the otherwise unavailable UART2 (on GPIO16, 17) in addition to PWM1 (15). Unfortunately, omega2-ctrl in its current version omits this option. I fixed this and a few other minor things a while ago and posted it to onion as a pull request, but so far nothing has happened

Finally - the driver is ready!

See p44-ledchain in my feed for LEDE on github.

People testing it with various LED chains welcome, my current test object is the "pixelboard" (of which you find some parts in the same feed already) with 200 WS2813 LEDs.

@Patryk-Wychowaniec said in PWM available on which dock?:

There's no PWM mechanism in Omega 2 itself so I think there's no way it is available on the mini dock or power board.

Of course there is! The MT7688 has a four channel PWM unit, 2 of them can be made available on Omega2 gpio pins 18 and 19 (using omega2-ctrl).
I use these PWM units to drive WS28xx-type LED chains.

There's even standard kernel support for these PWMs - see "Using PWMs with the sysfs interface" paragraph of this document. Problem here is that this is not enabled in the standard Omega FW build so far, and because that build is still not fully open source (to lament once again) , there's no easy way to enable it. But if you can build your own LEDE FW images, the PWMs are easy to use and very precise.

just wanted to mention - in the meantime @onion did publish omega2-ctrl - thanks

@Fred-Blais I'm preparing to use Omega2s for a home automation gateway device I have developed (one man business).
But what I've already done are fun projects, like this giant two-directional Tetris game integrated into a small lounge table (80x40cm, not final frame yet):

I did a custom "dock" PCB for it, which has a 4.5V..39V to 3.3V regulator and an Ethernet Jack on it, plus some specific components needed for the project - level shifter for driving WS2812 LED chain, RS485 interface, FTDI connector, i2c connectors for touch keys.
As you can guess, this predates the Omega2, luckily I had an Omega1 around to spend the time while waiting for the Omega2

I will publish the complete design, drawings, PCB, software on github, as soon as I find the time to sort and tidy up all the files, and to write a decent readme.

@Fred-Rauch As @fossette said, the Omega2 FW is built on LEDE. At this time, it seems the LEDE board profile for the Omega2 is not published yet. I'm regularily checking the LEDE github repo and in particular the pull requests for it, hoping Omega2 support will soon land there.

But yes, I got it (partially) working already

The LinkItSmart7688 is a very close relative to the Omega2 (same chip, MT7688), so I just used the LinkIt profile.

An important difference is that the LinkitSmart uses ttyS2 as console, while Omega2 uses ttyS0. So I had to change the tty in the "bootargs" line in the "LINKIT7688.dts" device tree file, and remove the serial0-to-uart2 alias definition.

With that, I could build an image the Omega2 bootos up ok with, and gets accessible via the Ethernet expansion! WiFi access point also worked, but I didn't get it to connect to my WiFi as a client (didn't try hard, though).

For sure there are a lot of other details which are not exactly right in the LinkIt image for the Omega (e.g. LEDs, reset button). So this is for early experiments, but not for real use yet. We need to wait for the official platform support from Onion to appear in LEDE.

@Alex-Brooke said in USB connection without a dock:

@luz I know that it's possible to use a serial to USB converter-- my question was whether I can connect directly over USB without any extra hardware.

As said, on the hardware level you can. But it's USB host, because the Omega uses its native USB port to allow connecting extras such as the GPS extension, USB drives etc.

Your original question sounded like you wanted to get access to the linux console, and for that the answer is no, because the Omega firmware is configured to provide console access via the serial port only.

Maybe it is possible to use the Omega USB PHY in device mode, but that would require compiling or even porting kernel modules (kmod-usb-gadget), building custom firmware images etc. Nothing even in the proximity of "quickly making things work"

Just approach the problem from the other side: The Omega2 is compatible with all Onion1's docks. And the schematics of the docks and relevant expansions such as Ethernet are all available here.

So it's quite easy to see (on the second page) what's needed to use the USB Host port of an Omega (1 or 2): no active level shifters, but preferably some ESD protection diodes. And, as the original poster said, of course the USB V+ is 5V and must not be connected to 3.3V.

You can also see that the Micro USB port of the dock is not connected directly to the Omega USB pins, but to a USB-to-serial converter chip, which in turn is connected to RX0/TX0, giving access to the console.

So one way to access an Omega without any dock is using a USB-Serial cable with enough 3.3V power (>200mA), such as the FTDI TTL-232RG-VREG3V3-WE, and connect it to power and RX0/TX0.

@Alex-Brooke the Omega2 is not based on the AR9331 any more, but uses the MediaTek MT7688 (official datasheet available)

Choosing between LEDE and OpenWrt is not so much about technology (the LEDE fork hasn't divereged significantly overall), but more about communities and future activity.

The interesting stuff regarding the MT7688 chip in the Omega2 seems to happen in LEDE now. MediaTek (the maker of the MT7688) is one of the few SoC makers actually betting on open source, and thus supporting the idea of open source WiFi drivers. At least that's what I learned from this talk from last years 32C3 by Felix Fietkau, who's definitely active in LEDE working on topics relevant for Omega2's ramips/mt7688 platform.

With LEDE #1 release still ahead, I admit it might be too early for Onion to switch the Omega standard FW to it.

However, looking at the OpenWRT-Packages repo it seems we'll get the cutting egde opensource WiFi driver Felix was mentioning in his talk for the Omega2

Anyway, as soon as the Omega2 platform support (the "profile") is pushed to either tree, it will be easy to port it to the other. I'm already building my own LEDE and OpenWrt images for the Omega1 and another MT7688 target, and I'd definitely be willing to help bringing Omega2 to LEDE (if it hasn't already happened).