00:13 <re_irc> <Lachlan> James Munns: How on earth did you remove the "fixint" stuff from postcard 1.0.0?

00:13 <re_irc> <James Munns> I have no idea

00:13 <re_irc> <James Munns> bad merge or something?

00:14 <re_irc> <Lachlan> Yep, seems like it! That's great news though

00:14 <re_irc> <James Munns> the mod was totally missing from lib rs, but not the actual file lol

00:14 <re_irc> <Lachlan> Very happy about that

00:14 <re_irc> <James Munns> submit a PR when you can :D

00:14 <re_irc> <Lachlan> :)

06:51 <re_irc> <Campbell He> therealprof: Sorry for being late. I indeed in bed time 😂 (and sometimes don't notice message in martix orz)

06:51 <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)

06:51 <re_irc> I think this idea might be useful, but it needs more discussion to become practical.

09:52 <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

10:50 <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) 🤣

10:59 <re_irc> <James Munns> :D

11:00 <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.

13:09 <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?

14:02 <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

14:03 <re_irc> <chemicstry> * HALs

14:05 <re_irc> <chemicstry> Here is an example of how to do that https://github.com/eldruin/ads1x1x-rs/blob/master/src/interface.rs#L23

14:30 <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?

14:35 <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?

14:38 <re_irc> <Tim Hoeppner> Maybe I want to retry communication if I get a nack

14:46 <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.

14:50 <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? 🙂

14:51 <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

14:54 <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.

14:55 <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.

14:57 <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

14:58 <re_irc> <Tim Hoeppner> Yea I was just trying to think of an example... Don't actually want/need to do that

14:58 <re_irc> <Tim Hoeppner> Looks like someone is trying to solve this problem, there's an embedded-error crate.

15:06 <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...

15:06 <re_irc> ... can provide the functionality back to the driver, but it seems like a hack

16:01 <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: https://docs.rs/embedded-hal/1.0.0-alpha.8/embedded_hal/i2c/enum.ErrorKind.html