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)
Have you made your code open source ? Maybe someone else is able to make the changes necessary to make it work on the omega2. I am willing to try even if my knowledge in this field is quite limited.
Was it necessary to rebuild the full system to get interrupts on the Omega 1 ?
That's VERY interesting, Kit! Thanks! Your library makes a clever use of the GPIO_DSET and GPIO_DCLR registers of the SoC chipset, which by itself makes the write operation atomic.
So, to answer the OP, the Omega2 does have the bit-banding memory-map feature for GPIOs. If the fast-gpio functions are well designed, there's no reason why they shouldn't be atomic (but again, I have not seen those specific source code yet to confirm or refute their atomicity).
Make sure that the system is fully operative by using a delay as suggested by @fossette
As is mentioned in the referenced post, make sure the program you want to run at boot terminates in a timely manner and doesn't end up blocking the start up process - e.g. run it in the background