The last change made to the driver was a fiber refactoring:
commit 99c69b519467e6b8704e41d7d5ee7ec713ccd478
Author: Niklas Hauser <niklas.hauser@rwth-aachen.de>
Date: Sat Aug 23 20:31:21 2025 +0200
[driver] Replace Timeout with this_fiber::sleep_for
The use of the following function was replaced by modm::Timeout::wait():
template<Bmi088Transport Transport>
void
Bmi088<Transport>::timerWait()
{
while (timer_.isArmed()) {
modm::this_fiber::yield();
}
}I could determine with the debugger that the code always got stuck here:
template<Bmi088Transport Transport>
bool
Bmi088<Transport>::setAccRange(AccRange range)
{
timer_.wait();The culprit is the definition of the wait() method:
template< class Clock, class Duration >
void
modm::GenericTimeout<Clock, Duration>::wait()
{
modm::this_fiber::poll([this]{ return execute(); });
}It is based on execute() which will only return true on its first invocation. Thus, two subsequent calls to wait() on an expired timer will block indefinitely. The same happens if the timer hasn't been started yet.
I'd change the behaviour of wait() to poll for !isArmed(). If there is something to wait for, it'll wait or otherwise just return instead of blocking forever.
@salkinium Would you be fine with that change?
The last change made to the driver was a fiber refactoring:
The use of the following function was replaced by
modm::Timeout::wait():I could determine with the debugger that the code always got stuck here:
The culprit is the definition of the
wait()method:It is based on
execute()which will only return true on its first invocation. Thus, two subsequent calls towait()on an expired timer will block indefinitely. The same happens if the timer hasn't been started yet.I'd change the behaviour of
wait()to poll for!isArmed(). If there is something to wait for, it'll wait or otherwise just return instead of blocking forever.@salkinium Would you be fine with that change?