07:26 <re_irc> <@a2ron:matrix.org> Hi, where can I find a i2c sensor driver example is embedded-hal-async based?

07:29 <re_irc> <@juliand:fehler-in-der-matrix.de> https://crates.io/crates/embedded-hal-async/reverse_dependencies these crates depend on embedded-hal-async, so you might find some drivers there that use i2c

07:30 <re_irc> <@juliand:fehler-in-der-matrix.de> https://github.com/diondokter/lis3dh-rs-async this has an i2c variant

11:27 <re_irc> <@yruama_lairba:matrix.org> : you wrote stm32-hal2 ? I just wanted user experience general experience about it. Since my initial question, I looked the doc more in details, For example, this crate seems closer to hardware in general, for example, you can directly configure prescaler for clock, something i'd like to have in other stm23-hal. However, some stuff doesn't play with owning/borrowing semantic and feels weird when you are accustomed to...

11:27 <re_irc> ... other hal. For example Pin are spawned from nowhere and Clock can be configured anywhere by creating a Clock object.

11:42 <re_irc> <@larunite:matrix.org> : In fairness, the owning and borrowing semantics don't always play super well with embedded. We're talking about devices with hardware mapped peripherals, bit banding, DMA, all sorts of stuff. Trying to make the ownership semantics of Rust map onto that is a fine idea and gets you some very cool APIs, but it can also be very limiting.

11:42 <re_irc> I think it's good to have an alternative that doesn't aim to fully match those two things, and instead operates more like embedded C but with a lot of the benefits rust brings in the software domain.

12:05 <re_irc> <@yruama_lairba:matrix.org> George, i'm not sure, but I think the way those stuff have been implemented are unsound because some function actually unsafe

12:06 <re_irc> <@larunite:matrix.org> Yeah probably. But that's the tradeoff.

12:07 <re_irc> <@yruama_lairba:matrix.org> no, that's wrong

12:08 <re_irc> <@larunite:matrix.org> Okay

12:10 <re_irc> <@yruama_lairba:matrix.org> a function that can trigger undefined behaviour must be declared unsafe. Sometimes, this can be difficult as API designer to determine what is safe or not

12:15 <re_irc> <@larunite:matrix.org> Generally, yes. But that gets waaaaaaaay more intricate in embedded where you have a bunch of peripherals that can directly mess with memory, and have very detailed requirements on how they might be initialised.

12:15 <re_irc> For example I might have a part configured to trigger a DMA access every time I see a rising edge on a pin, which writes directly into the enable register of a SPI peripheral to trigger an external SPI read, which itself gets DMA'd directly into memory. Proving that that is all correctly configured and memory safe at compile time, in the type system, is going to be astoundingly hard.

12:15 <re_irc> So the main stm32 hal generally only offers a subset of what the hardware can do, that it can prove is safe. But if you want to push that further and further, proving it all at compile time ties you in knots.

12:23 <re_irc> <@yruama_lairba:matrix.org> writing the enable register of a spi device with a dma ? seems weird, this use case is too specific to appear in general purpose HAL :p

12:24 <re_irc> <@larunite:matrix.org> It's actually fairly common. An external device might signal it is ready to send you data by raising a flag pin, which should trigger you to do a read. If that's a high speed peripheral that has data every microsecond, you need DMA to do it

12:25 <re_irc> <@yruama_lairba:matrix.org> And i'm okay to have unsafe stuff in HAL, I agree there is many case where having "safe" interface in sense of rust is too hard to design

12:30 <re_irc> <@larunite:matrix.org> Keep in mind that the main STM32 hal doesn't just aim to provide a _safe_ API, but also a _correct_ API

12:31 <re_irc> <@larunite:matrix.org> So you can't have things misconfigured

12:31 <re_irc> <@larunite:matrix.org> And that's very hard

12:31 <re_irc> <@larunite:matrix.org> Also keep in mind I'm just some guy and I don't design or maintain either of these hals 🌠

12:42 <re_irc> <@yruama_lairba:matrix.org> George , i thinks you can't have things misconfigured by just using safe API, but guideline may vary slighty across stm32-HAL

13:06 <re_irc> <@larunite:matrix.org> I'm not sure what you mean by that

13:06 <re_irc> <@larunite:matrix.org> but a safe API could certainly allow misconfiguration and still be memory safe

13:06 <re_irc> <@larunite:matrix.org> it is a design choice to try and prevent it

13:11 <re_irc> <@yruama_lairba:matrix.org> rust safety is about undefined behavior, and in many situation, misconfigured peripheral deosn't have a defined behavior.

13:12 <re_irc> <@larunite:matrix.org> That is a colloquial meaning of undefined behaviour

13:13 <re_irc> <@larunite:matrix.org> When rust talks about avoiding UB, it's talking about avoiding UB _in the compiler_

13:13 <re_irc> <@larunite:matrix.org> in order to preserve memory safety

13:17 <re_irc> <@larunite:matrix.org> For example you can look at the standard libary BTreeMap implementation

13:17 <re_irc> <@larunite:matrix.org> it says if your Ord implementation is incorrect, then the behaviour of the collection is not guaranteed to be correct. But it is still safe

13:17 <re_irc> <@larunite:matrix.org> And doesn't contain undefined behaviour, in the compiler sense

13:24 <re_irc> <@yruama_lairba:matrix.org> sometimes, determine what is safe or not is really a hard task...

13:28 <re_irc> <@yruama_lairba:matrix.org> anyway, most of the time, APIs are considered better when they prevent bad usage, and this is not only true for rust

13:29 <re_irc> <@larunite:matrix.org> Thats certainly true. And Rust APIs manage to be a LOT better than C APIs :D

13:33 <re_irc> <@yruama_lairba:matrix.org> But are sometimes a Nightmare for API designers XD

15:36 <re_irc> <@romancardenas:matrix.org> Hi! I've been working on generic peripherals for RISC-V targets. I'm currently working on a ACLINT/CLINT peripheral, and followed 's advice regarding using pointer maths instead of register blocks. I'd be grateful if you could take a look to my current proposal and provide me feedback to improve it: https://github.com/rust-embedded/riscv/pull/135

15:36 <re_irc> Thanks in advance!

15:45 <re_irc> <@firefrommoonlight:matrix.org> : This is a good description of my reasoning. I kept the owned semantics when it makes sense, but ditched it or provided workarounds when it got in the way

15:46 <re_irc> <@firefrommoonlight:matrix.org> Priority is easy-to-use API suitable for practical uses

15:47 <re_irc> <@larunite:matrix.org> In embedded, you have to do dirty and shameful things pretty often to get the results you need

15:47 <re_irc> <@larunite:matrix.org> But I feel a little bit better if I just have to dip into that stuff occasionally, and use lovely safe rustiness the rest of the time :D

15:49 <re_irc> <@firefrommoonlight:matrix.org> Re marking things unsafe: Also subjective. I did that for the DMA API since you have to be careful about that re lifetime of the buffers you pass it

15:50 <re_irc> <@firefrommoonlight:matrix.org> Probably the sharpest edge exposed

15:50 <re_irc> <@firefrommoonlight:matrix.org> The GPIO is an interesting example because on STM32, the register-block distinction that is traditionally associated with ownership is on _port_ level, while, _pin_ level abstractions are more useful. You'll find that other APIs that require stricter ownership there don't use the ownership strictly under thd hood

15:51 <re_irc> <@larunite:matrix.org> Also GPIO has bit banding :P

15:51 <re_irc> <@firefrommoonlight:matrix.org> true

15:51 <re_irc> <@larunite:matrix.org> Built-in aliasing

16:27 <re_irc> <@gptechinno:matrix.org> Can someone point me to a embedded-hal driver for a i2c device that implement both blocking and async API based on a feature. I am getting some trouble doing so. I did an blocking driver for emc2101 chip. I have an async git branch of it, and I would like to merge both implementation in one driver.