Question: is it okay to not "sleep" on driver.get_message()

[half2me]

In the sample you use a loop:

loop {
  match driver.get_message() {
    Ok(None) => (),
    msg => println!("{:#?}", msg),
  }
}

Just out of curiosity I checked how many times it's actually matching the Ok(None) pattern, and it's up to >4000 times between messages. Is this okay? Are we wasting cycles here or is this a non-issue?

I've had cases where the usb stick freezes up, and I don't get any new messages unless I unplug and plug it back in. I'm trying to find a way to reproduce this and see if I can detect this issue in code and differentiate it from there just being no packets available to capture. This was the first thing I checked, if I could maybe count how many times its hitting this pattern.

[cujomalainey]

Yea, that is just a sample code, and outside of demo code it does not make sense indeed. Places where you can get interrupts from the underlying buses (uart, spi. usb) would be better for triggering the checks, but I have not gotten around to actually demoing such code.

Also one challenge with rust is that the model is for the driver to be own the underlying bus, so if the bus triggers an interrupt and calls out to some supporting function, unless that callback is deferred (e.g. through an event queue) you will end up calling back into the driver which causes an ownership issue. Still working on how to avoid that as I am not a rust expert yet and the embedded rust community is still iterating their designs.

[cujomalainey]

One other thing I forgot to mention is that @harrychin is looking to add a async support, this will also solve some of the headache here as you can just await a message once its complete.

[half2me]

async support would be awesome. Let me know if there is anything I can help to test. My primary use case is just using the RxScanmode to capture as much ant+ data around me as I can and save it to a file.