ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 260 seconds]
<re_irc> <nihal.pasham> a question on "OnceCell" api - why does it include (among other methods) a "get_mut", which provides a mutable reference to the underlying data. Wouldn't this allow users to (albeit unsafely) mutate the contents of a "OnceCell" after the initial one-time assignment?
<re_irc> <nihal.pasham> * "core::cell::OnceCell" api - why does it include (among other methods) a "get_mut", which provides a mutable reference to the underlying data. Wouldn't this allow users to (albeit unsafely) mutate the contents of a "OnceCell" after the initial one-time assignment.
thomas25 has quit [Quit: fBNC - https://bnc4free.com]
thomas25 has joined #rust-embedded
<re_irc> <GrantM11235> "get_mut" takes a "&mut self", so it is safe
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
genpaku has quit [Remote host closed the connection]
genpaku has joined #rust-embedded
causal has joined #rust-embedded
<re_irc> <wcampbell> Any examples of using https://www.adafruit.com/product/4800 in rust? I couldn't find any from the esp-rs guys
<re_irc> <James Munns> https://docs.rs/epd-waveshare/latest/epd_waveshare/ may help you with the display?
<re_irc> <wcampbell> I'm not sure these are waveshare displays? Unless you know they are
dc740 has joined #rust-embedded
<re_irc> <James Munns> I'm not sure, but often they use common displays
<re_irc> <wcampbell> Cool, I'll check it out sometime
<re_irc> <newam> The controllers are usually very similar between SPI-based epaper displays, I think they're all coming from 1 or 2 factories.
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <Leandro Marceddu> Can the .wait() of a embedded_hal::timer::CountDown only be used with a block!()? If no I'm doing something wrong
<re_irc> <ryan-summers> Depends on how you're trying to use non-blocking operations. If you want to wait for the countdown to elapsed and aren't doing anything else, you should likely be using block!()
<re_irc> <ryan-summers> Any other non-blocking frameworks would likely be async instead, such as embassy, where you'd use .await
<re_irc> <Leandro Marceddu> I just wanna check if the countdown is finished and not block the loop
<re_irc> <Leandro Marceddu> aha okay
<re_irc> <ryan-summers> Then what you're doing is fine
<re_irc> <Leandro Marceddu> So what I'm seeing is normal, okido.
<re_irc> <ryan-summers> You just need to check the result to see if the wait is complete :)
<re_irc> <ryan-summers> It's basically async for embedded before async for embedded existed. nb is slowly disappearing though
<re_irc> <Leandro Marceddu> The result of what, the .wait()?
<re_irc> <ryan-summers> Yes. It should return an "nb::Result"
<re_irc> <Leandro Marceddu> Aha! Thanks
<re_irc> <ryan-summers> Yeah, that will either be nb::Error::WouldBlock if the wait isn't done, nb::error::Other if another error happened, or Ok(T) if the wait elapsed
<re_irc> <Leandro Marceddu> Hero, thanks, I was already looking into what I might expect
<re_irc> <ryan-summers> All block!() does is keep polling until the result is Ok(T) or error::Other
<re_irc> <ryan-summers> (I think)
<re_irc> <Leandro Marceddu> I have a feeling this isn't the 100% correct way but it works:
<re_irc> <Leandro Marceddu> However once I get the 'wait over' the next iteration is 'waiting' again, which can't be happening because the start is outside of the loop {}
<re_irc> <ryan-summers> Seems like that is likely a result of the implementation details of the HAL that you're using
<re_irc> <ryan-summers> Doesn't seem super unexpected to me, although it is odd. I'd wrap it up in something that only does wait() if the countdown has not yet elapsed
<re_irc> <ryan-summers> Also, generally when unexpected errors happen, you want to panic (e.g. hardware failed, etc.). It's often that you want to "unwrap()" these at the application-level (or just panic!() directly if you don't want format bloat)
<re_irc> <ryan-summers> panics in a normal system would cause it to reset, so it can start doing what it's supposed to again :)
<re_irc> <Leandro Marceddu> I'll keep it in mind - for now I'm just experimenting. I wanna create a loop of sorts every minute. For that I need to capture when the countdown is over - do my stuff, and reset the countdown
<re_irc> <Leandro Marceddu> in the meantime not hindering the rest of the main loop {} ofc
<re_irc> <Leandro Marceddu> Sadly async breaks my head
<re_irc> <ryan-summers> Async does all of that without you having to think about it, but yeah, I haven't done embedded async yet
explore has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded