ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <Lachlan> James Munns: How on earth did you remove the "fixint" stuff from postcard 1.0.0?
<re_irc> <James Munns> I have no idea
<re_irc> <James Munns> bad merge or something?
<re_irc> <Lachlan> Yep, seems like it! That's great news though
<re_irc> <James Munns> the mod was totally missing from lib rs, but not the actual file lol
<re_irc> <Lachlan> Very happy about that
<re_irc> <James Munns> submit a PR when you can :D
<re_irc> <Lachlan> :)
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
talperud has quit [Ping timeout: 246 seconds]
talperud has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 268 seconds]
fabic has quit [Ping timeout: 248 seconds]
causal has joined #rust-embedded
<re_irc> <Campbell He> therealprof: Sorry for being late. I indeed in bed time 😂 (and sometimes don't notice message in martix orz)
<re_irc> My motivation is that I want to create 1 PAC for 3 MCU (2 RISC-V and 1 Coretex-A), they share most of the peripherals except some control module. So I haven't thought deeply about the problem that multiple peripherals have the same name. (Actually I haven't thought about how to support multiple targets either)
<re_irc> I think this idea might be useful, but it needs more discussion to become practical.
gsalazar_ has joined #rust-embedded
gsalazar_ has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
<re_irc> <James Munns> Just wanted to say thanks for putting together the aw-pac Campbell He, I'm planning to work on the D1 soon, and it was awesome to see other folks working on it already :D
fabic has joined #rust-embedded
<re_irc> <Campbell He> MCU I mention above is D1-H (previously named D1), D1-S (D1 but without some peripherals) and R528 (same as D1 but ARM A7) 🤣
<re_irc> <James Munns> :D
<re_irc> <James Munns> I have a couple of the Mango Pi and Sipeed boards, hoping to port my hobby OS to it soon, once I'm done reworking the kernel a bit.
fooker has quit [Ping timeout: 248 seconds]
fooker has joined #rust-embedded
<re_irc> <Tim Hoeppner> I'm writing a device driver for a specific i2c device using the embedded hal crate and would like to bubble up or even handle the i2c errors. However, it doesn't look like embedded hal has definitions for the i2c errors. How does one handle the errors when writing device drivers in this manner?
<re_irc> <chemicstry> Errors are defined in HAL and embedded-hal traits have an associated Error type for that. Usually you just pass the error up to your library caller
<re_irc> <chemicstry> * HALs
<re_irc> <chemicstry> Here is an example of how to do that
<re_irc> <Tim Hoeppner> That makes sense but with this I can't actually handle an error in my device driver, all I can do is bubble it up?
<re_irc> <chemicstry> well you can handle the error, but you can't distinguish what error. Could you give an example of what erro exactly you want to handle in the driver?
<re_irc> <Tim Hoeppner> Maybe I want to retry communication if I get a nack
<re_irc> <Tim Hoeppner> I'm just curious really. I would have thought there would be lots of reasons to do so. Just seems odd not to define error types in embedded hal.
<re_irc> <chemicstry> This is because you can not account for all error types that HALs could have. What if I2C is tunneled over mail pigeons and the error is BadWeather? 🙂
<re_irc> <chemicstry> I guess you could add an enum with most common types and a Custom(E), but then some of the options might also get outdated/obsolete
<re_irc> <Tim Hoeppner> You could be right, hard to say exactly. Just wonder if it's one of those things that we think people are going to need all this flexibility when in reality everyone just invents the same thing over and over again.
<re_irc> <Tim Hoeppner> I'll have audit some more code and see. I'm pretty new to the embedded rust world, just trying to understand everything.
<re_irc> <chemicstry> Yeah, I think going through awesome-embedded-rust list of drivers might give you an example of how to handle retries in a driver. Although I'm not sure if handling retries in a driver is the best way to do it, unless that's how the chip is designed to work
<re_irc> <Tim Hoeppner> Yea I was just trying to think of an example... Don't actually want/need to do that
<re_irc> <Tim Hoeppner> Looks like someone is trying to solve this problem, there's an embedded-error crate.
<re_irc> <almindor> The only way to handle the errors is to know the concrete ones. That'd be probably on the PAC-HAL level of the specific MCU/core. So a driver shouldn't handle those unless it's specifically made for that MCU only. Best is to just bubble it up and let the specific user code handle it. If retry logic is really necessary you could add some sort of "error is retry" closure/callback into the driver so that the driver caller...
<re_irc> ... can provide the functionality back to the driver, but it seems like a hack
<re_irc> <jannic> In the latest 1.0.0-alpha releases, there is an ErrorKind which would allow a driver to react differently depending on the kind of error:
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
WSalmon has quit [Quit: - Chat comfortably. Anywhere.]
WSalmon has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
Darius has quit [Ping timeout: 276 seconds]
Darius has joined #rust-embedded
limpkin has quit [Ping timeout: 244 seconds]
limpkin has joined #rust-embedded