Do you only care if you are connected to WiFi, or do you also care if your packets can go anywhere upstream?
ie, how do you want to handle the case of being connected to a router, when the cable modem upstream of it is down?
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.
First step in debugging would probably be to explore what was ending up in the overlay.
One likely culprit is upgrading large amounts of system software (python, etc) or installing many new packages.
The other is having some ongoing task that creates log files or data objects
There are almost certainly ways to make this work, but they may take some non-trivial engineering.
Indeed, this is a bad idea.
A complex Linux system with many undocumented corners and unresolved bugs is the last thing you'd want for a flight computer. In the case of the Omega 2+ even simply compared to other boards with the MT7688 chip, there's also the issue that an error in the choice of the companion flash chip on the module means that if the MT7688 experiences an unprepared reboot (for example from a glitch, or a watchdog) without the flash chip power cycling, a disagreement of addressing mode means that it will hang and be unable to boot.
Actual flight controllers are quite simple computers. A few years ago they were typically 8-bit ATmegas or STM8's, though fortunately that era is now in the past. Today they are typically simple ARM Cortex M0, M1, or M3 parts, from the likes of STM, Gigadevices, Nuvoton, or Asia-only vendors relatively unknown in the west. These run with internal flash and ram and have the rich I/O that @ccs-hello mentioned. For these purposes they run simple main-loop style bare metal firmware, drastically simpler and more responsive than what you would get from a multithreaded architecture. If you're interested in experimenting with this the realm of tiny featherweight platforms, there are a number of published open source replacement firmwares for toys like the H8mini, CX10, etc - ironically, the smaller (and therefore twitchier) the aircraft, the faster the control system needs to be.
If you do choose to fly a system like the Omega 2+, it should be limited to optional features, for example, you might use it to log data that you'd like to have, but the loss of which would not cause the aircraft to crash.
A missing C file wouldn't typically be the result of a missing library. On a platform like this libraries (to link against) are .a files, and the error messages are from the link stage, not the compile stage.
Your error rather indicates that the build process (probably a Makefile) is pointing to a C source file called gpioRead.c that either didn't get copied to the build machine, or isn't where it is supposed to be. You should examine the Makefile, and also examine the source directory and figure out what the mismatch is.
Also note that if you move code around you can run into different platform specifics - Linux for example cares about capitalization. OSX in contrast preserves it but will match across differences (which can actually cause its own problems). And windows, well, nevermind.
The flash is not a BGA - you can clearly see all 8 contacts in the picture, and if you hold the MT7688 in reset it will stay out of the way of your programmer.
But you have to remove the shield.
Unfortunately, JTAG does not seem to be available without removing the shield either.
If you want to do low-level work you'd likely be better off with a Linkit Smart or an ACSIP module than an Omega2, in both cases where removing the shield is both less necessary, and substantially easier.
That's where the boot up sequence terminated. After a little while the O2+ LED turned off. I thought I'd bricked it.
You've perhaps run into the fact that the Linkit and Omega2 use different serial ports and baud rates for their consoles. Your boot log stopped right at the point where Linux switches from the inherited serial configuration to its own.
An odd thing about the Linkit kernel is that it decides which serial port to use based on which on-chip hardware it finds configured (and does this in a way that gets easily confused if you enabled more than one in uboot).
Best guess: it's still on the port you are connected to but now at 57600 baud.
@Arun-Kapur Suggest you take the advice of @Maximilian-Gerhardt and closely read the docs. Not explicitly stated is the UART is available as a character device in the file system. As such you can write to it and read from it in C(++) as with any other character device. IMHO, it's level of complexity, or lack thereof, does not warrant a separate library.
In actuality, correctly using the Omega's UART is a bit complex, requiring quite a bit of configuration, especially as the defaults are a bit unusually less appropriate than on many other systems.
Looks like your connection to Onion Community was lost, please wait while we try to reconnect.