The example "blink without delay" is well and good, but how can this be implementet in libraries, without having to worry about it in the main code?
For instance many sensors require a certain time between calling the sensor to make a measurement and the measurement being ready for reading, some sensors require even milliseconds. Is this possible without having to use delay() in the library?
Yes, if the library has at least two methods like "StartMeasurement" and "ReadMeasurement". The former initiates the process, but returns immediately. The latter retrieves the completed measurement and returns true if it was ready. Returning false means the device had not completed the measurement.
This allows the caller to continue doing things while the device takes its sweet time. It's also nice to provide methods (or constants) for estimated time-to-complete. Sometimes a "completed" flag could be set by an interrupt from the device. If it's a pin-oriented IRQ, then the PinChange attachInterrupt could be used to set the flag that is being polled by loop.
Cheers,
/dev
Lars81:
The example "blink without delay" is well and good, but how can this be implementet in libraries, without having to worry about it in the main code?
I don't understand what you don't understand. Perhaps you can post some code to illustrate what you are thinking of doing.
The demo Several Things at a Time is an extended example of BWoD - it may help with your understanding.
...R
Robin2:
I don't understand what you don't understand.
A library does not have its own loop(), where times can be taken and compared until the delay expired.
That's why the library must offer an interface like /dev suggested, or with methods like begin(), available() and read(), as I prefer.
My begin() would start a measurement and remember the starting time.
available() would test whether the delay has expired.
read() would request the value from the sensor, assuming that available() returned true before.
DrDiettrich:
A library does not have its own loop(), where times can be taken and compared until the delay expired.
The AccelStepper library deals with this by requiring frequent calls to stepper.run()
I guess that is similar to @/dev's readMeasurement()
...R