toitlang
Could gpio.Pin.wait_for return the value of how long it waited?
Looking as best I can through the library, gpio.Pin.wait_for returns --> none whereas it could potentially return how long it waited for without breaking anything (or could be overloaded, or a separate function?)
Just might be useful for no cost
I have been looking at the implementation of the gpio.Pin.wait_for method and the sub methods it calls. They already return states and other values, so the overload would have to happen in the gpio.Pin.wait_for method itself.
To do the timing itself, the Duration.of block could be used. This could be put into the standard library, but I would argue that the method without the timing should still exist. This is because the timing will add a few unnecessary instructions if the use case doesn't need the timing aspect.
Alternatively the gpio.Pin class could be overloaded, and then the method could be overloaded in that class to implement the timing of the wait_for call.
There are fundamentally two questions here:
- should we allocate an object when doing
wait_for? - How precise do we want to be (or can we be)?
Many times, the user doesn't care for how long it took, and thus returning an object (Duration) might be unnecessary allocations for nothing. We could have a different wait_for function that returns the result, but that feels a bit weird to me.
Alternatively, we could return the microseconds it took for the pin to go high/low. That's just an integer that doesn't need allocation.
If we don't need precision, then just measuring the time in the wait_for function is easy. We can either use Duration.of or Time.monotonic_us. Both would probably work fine.
However, if we want to be more precise, then we would want to take the time when the pin goes high/low inside the C code; before context switches and similar stuff (which could take a bit of time).
Fundamentally, the question is, whether the returned duration is just something for convenience, or if it provides data that the user could otherwise not obtain at the same precision (at least not without something like the RMT peripheral).
