@Paul-Cousins Let's suppose the Arduino Dock 2 and its HW environment on your IoT ONE board are perfect.
So your Arduino SW - almost certainly - has some bug(s).
You should debug it instead of restart the Omega's I2C master from time to time - I think.
Well, on the THIRD micro USB cable, I finally have /dev/tty.SLAB_USBtoUART. I haven't rebooted the Mac as it turns out not to be necessary. I'm really surprised it was the cables. They work for other devices.
Thanks for your replies. Let me describe a little better what I'm trying to do.
I built a simple data logger, that I want to be smart enough to turn only attempt to transfer data to my server when it's "home". If I'm out driving in my car with it, I don't want it to be trying constantly to get to it's server. Heck, I could even turn wifi off at that point and conserve battery.
The underlying issue here has been covered many times before.
The Omega 2+ has an ill-chosen flash chip, which cannot expose its full capacity unless operated in a 4 byte mode which is incompatible with the configured expectation at boot.
There is no actual working poweroff command, and there never has been one. However, programs that reboot without putting the flash chip back in a boot compatible mode end up hanging in a tight loop at boot, giving the impression of being sort of "off".
Also note that unexpected reboots, such as triggered by a watchdog will also result in a hang, rather than a successful boot.
As the Omega 2 (non +) flash chip fits entirely in 3-byte addressing mode, it should not experience this problem.
Flash chip commands can be found in the relevant data sheets, as well as the U-Boot and Linux Kernel sources.
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:
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 ;-)
@leo-moura Omega2(+)'s hardware SPI bus has some limitations and some problems - use the forum's search function please.
I guess that 'screen' means some kind of display (LCD, OLED, etc.). I think it's much more convenient to use that 'screen' on Omega2(+) if it has serial or even I2C interface (especially for a newbie ;-).
Last thought on this for now.
Working on the assumption that something external to the build process might be interfering with it, and since this is windows you are probably running some kind of anti-virus software. If so, have you tried excluding your build path and all sub-folders from your AV software? Or temporarily disabling it and then running a build?
@Yvan-Gagnon I've mentioned this a couple times in response to other posts and do not remember if one of those posts was yours, if so, I apologize for bringing it up again, but, it is possible to gain access to all the pins by using a female header with long pins. just insert the female header into each header of the mini dock and then insert [carefully] the omega2+ into the long pin female headers. this will leave all pins exposed that you can then use various methods to attach wires from your project to the appropriate pins. granted it is a "garage style" method and care must be taken to not damage the long pin headers, however it worked for any project i saw hooked up this way at a local hackerspace.
For each and every point you listed there is a mass of documentation available.
You should be able to install openssl on the Omega2+ (from LEDE repos or directly Omega repos), which gives you the means to generate what every certificate you like. You haven't mentioned what kind of certificate you need, with what cryptographic parameters (RSA/ECC, curves, modulo length, hash algorithm, ciphersuites and key exchanges to be supported,...). Actually you don't even have to install and use openssl on the Omega2+, you can generate the keys and certificates off-site.
For web server (and uhttpd-mod-tls) documentation see
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 ;-)
Looks like your connection to Onion Community was lost, please wait while we try to reconnect.