-
Notifications
You must be signed in to change notification settings - Fork 62
Description
Just a suggestion: there are quite a few places where there's a while ..some bit condition.. {}
loop.
Sometimes it would be helpful if in debug builds these loops would time out and panic if the condition doesn't get hit in some sane amount of time, i.e. u16::MAX would be usually plenty.
I ran into a thing where RTC::new()
was trying to call enable_lse()
, which hangs forever if your devel board crystal isn't running properly for some reason. The issue is of course easy enough to find in this case, but in some other situations might save a bit of headache.
Perhaps a busywait
function that takes the condition as closure ? I.e. something like
fn busywait<F>(f: F) where
F: FnOnce() -> bool + Copy {
let mut countdown = u16::MAX;
while f() && (countdown != 0) {
countdown-=1;
};
if countdown == 0 {
panic!("timeout");
}
}
which can then be called like this
busywait( || self.rb.csr.read().lserdy().bit_is_clear() );
The backtrace when it fails points right at the source of the problem.
One could of course add #[cfg(not(debug_assertions))]
path here to eliminate the counter from release builds.
Does this sound like a good change ? If yes, I'll be happy to PR it