Thanks for that, it's very much appreciated. Playing with my own firmware is out because I don't have the spare time :-)
I can use a micro to handle power management; an attiny should do the job. I was hoping for a solution that used discrete components though.
I'm doing a project that will be battery powered from a less than 700mAh battery for periods of about 1 hour at a time. It will be completely sealed and inaccessible so the battery will remain connected all of the time and it will be charged either with a usb cable or via an inductive circuit.
The intention was to have a single momentary push button to turn it on (if there was enough power) and it could turn itself off if the battery dropped too low or it was shutdown via the wifi gui.
That seems highly implausible, as the MT7688 isn't really designed for battery operated systems.
What you should probably do is use a microcontroller intended for ultra low power / sleep mode / wake on interrupt operation.
Have that occasionally power up the MT7688 (USB power switch, regulator with enable, etc) when it needs wifi. Make sure you either have no persistent file system state, or do an orderly shutdown each time.
Also consider if there may be another wifi solution that is a better fit for your application.
To do it right, you would need to monitor the pins with an interrupt, and have a tight ISR check whatever the highest resolution timer is, then report to something that runs more leisurely.
But it's not clear if interrupts on GPIO are really supported; system components seem to poll them, and the userspace GPIO interface you may be familiar with from the pi does not seem to work (that would probably also be too slow, but if it worked something using the same capability in kernel would be more appropriate).
A $1 practical solution would be to hang just about any microcontroller on an available serial, I2S, or SPI interface or even the USB, have that time the events, and report the timestamps more leisurely to your Linux-based software. If you use serial or USB, and advantage of this sort of approach is that you can test your whole scheme on a PC without cross compiling for the omega. Meanwhile a potential disadvantage is that while you find out when the events happened with high precision, there's delay of a millisecond or more in that information making it's way to you. So you have great records, but don't quite know about things as they happen.... which may be good or bad, depending on your application need.
@luz holy hell dude. Your explanation was amazing. I just got my 2+, and I've been struggling my butt off to simply light up a set of LEDs. I looked at the pin out diagram, and I was looking for a way to switch pins 7, 8 and 9 to GPIOs. I must admit, the documentation is quite ... lacking.
@Costas-Costas the approach chosen by Kit and now Travis won't work on standard firmware until the /dev/mem issue is fixed.
Yes, one of the many reasons that I am holding off upgrading the code to Omega2
The other main constraint (other than time availability) is that the endianess differs on the Omega1 and Omega2 and I need to check out the places where this is significant in the code (I know of at least one place)