Most methods from
embedded-hal traits use
nb crate to make it possible to use these traits in non-blocking mode.
As this approach has limits, when, and at what level in abstraction stack, should I stop bothering and making methods blocking?
- Device level crate, timers — very good, calling method to wait for timer periodically is ok.
- Device level crate, setting pins high or low — seems that there's nothing to wait and these method don't return
- Device level crate, serial/i2c/spi —
muchless usable. . Even sending a single byte by calling "send" again and again with single u8 argument requires unnecessary state management at callee level.
embedded-hal's serial, spi and i2c API is blocking
- Driver level: should I even bother with
nb? I.e. if my LCD driver exposes
drawmethod that takes byte array of whole screen, it's definitely a very bad candidate for
nb; but if my driver has
get_temperature(with no arguments), should I make it nonblocking with returning
On the other hand, I can't imagine doing something with pins in nonblocking manner. When I'm doing something with pins, I don't want anything to preempt me while I wait to make a pulse of required width, especially some futures-based homemade 'green thread'. Why bother with nonblocking at all? Or it's just for long-running timers?