Need core API to wait on GPIO

[foogod]

This is a pretty common idiom that pops up in a lot of code, and currently we have a bunch of routines scattered around various drivers that basically all do the same thing:

• Wait a certain amount of time for a GPIO line to transition to a particular state and return success or failure (additionally, maybe also return info about how long it took).

Most current implementations of this actually use sdk_os_delay_us to sleep for small intervals between sampling the GPIO line, but since sdk_os_delay_us is really just implemented as a busy-loop anyway, and it doesn't hurt anything to sample the GPIO as fast as possible, I'm thinking a better way to do this would probably just be to have a tight-loop that keeps polling the GPIO line (and checking the time for timeout) until it gets the right value instead.

As far as timeouts, etc, sdk_os_delay_us uses CCOUNT to loop until the right number of CPU ticks have occurred, but that assumes the CPU is always running at 80 MHz, which it technically isn't always (the SDK bumps it up to 160 from time to time in some of the network routines when it needs extra horsepower), and we want to make clock rate more configurable in the future anyway. If I remember correctly, there's actually a hardware register somewhere that reports the number of microseconds since boot, but I can't find it now.. If there is one (and I'm not just imagining things), that might be a better way to measure this sort of thing anyway (it might be good to expose that as an API too)..

Anyway, I may get to this eventually, but I've got so many other things on my plate at the moment I wanted to make a note of it here in case anybody else wants to give it a shot too..