07:03 <AlexandrosLiarok> What is the best way to define a shared struct between cores at shared memory and access it without causing immediate UB ?

07:04 <AlexandrosLiarok> eg embassy currently does some pretty UB stuff: https://github.com/embassy-rs/embassy/blob/7a26e117ccd5f8669548cc8c2424be4691c1c402/embassy-stm32/src/lib.rs#L323

07:41 <diondokter[m]> <AlexandrosLiarok> "eg embassy currently does some..." <- Why do you think this is UB?

07:44 <diondokter[m]> AFAIK, any combination of underlying bits should yield a valid value for the struct

07:46 <diondokter[m]> Oh, I thought it was legal to do on integers, but apparently not according to the docs

07:47 <AlexandrosLiarok> I think I have an idea on what to do about this, give me a minute. This is pretty underspecified on Rust really.

07:47 <diondokter[m]> Has this changed? Because I've thought that for the past couple of years haha

07:48 <diondokter[m]> This section is probably what we should do:

07:48 <diondokter[m]> https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#initializing-a-struct-field-by-field

07:49 <AlexandrosLiarok> There is also a chance that the Uninit will read the magic value on startup. This could happen for example on soft reset if someone used backup memory for the shared data.

07:49 <diondokter[m]> Yeah I know... I don't really know how to solve that

07:49 <AlexandrosLiarok> something like this protocol.

07:50 <diondokter[m]> Yeah, but then you're assuming the second core will always run

07:50 <diondokter[m]> Might not be the case

07:51 <AlexandrosLiarok> yea true in which case we may just want a variant that won't lock for the primary core. I don't really have a solution here just brainstorming.

10:18 <AlexandrosLiarok> diondokter: I was thinking something like this: https://rust.godbolt.org/z/PY98d9jsW

11:32 <diondokter[m]> <AlexandrosLiarok> "diondokter: I was thinking..." <- I don't think this works because with this each core would initialize the shared data

11:35 <diondokter[m]> Hmmm I see. It might work. But only if both cores are booting at the same time.

11:35 <diondokter[m]> And also, both cores initialize the shared data. But this is done none-atomically, so not sure if that's allowed.

11:39 <diondokter[m]> Maybe this can help?

11:39 <diondokter[m]> https://github.com/taiki-e/atomic-maybe-uninit

12:02 <AlexandrosLiarok> The memory model does not help with this stuff. I do think we need to handle this better but there are UB minefields everywhere.

12:03 <AlexandrosLiarok> Even as it is it should work in practice but that's famous last words.

12:03 <AlexandrosLiarok> Could stop working anytime.

12:31 <AlexandrosLiarok> This is similar to issues that arise from usage of mmap

14:37 <djdisodo[m]> i want to write a driver for i2c, is there shared async i2c interface on embedded-hal?

14:38 <djdisodo[m]> or should i use this? https://docs.embassy.dev/embassy-embedded-hal/git/default/shared_bus/asynch/i2c/index.html

14:39 <ryan-summers[m]> The docs on the embedded-hal I2C trait explain what you should do djdisodo : https://docs.rs/embedded-hal/latest/embedded_hal/i2c/index.html#for-driver-authors

14:40 <ryan-summers[m]> The tl;dr is don't do any sharing yourself. There are external crates that rust-embedded manages (embedded-hal-bus specifically does this for you)

14:45 <djdisodo[m]> <ryan-summers[m]> "The docs on the embedded-hal I2C..." <- this is not for async

14:46 <ryan-summers[m]> I believe the same principles apply to the embedded-hal-async

14:47 <ryan-summers[m]> Yeah, embedded-hal-bus specifically talks about async also being supported here: https://docs.rs/embedded-hal-bus/latest/embedded_hal_bus/#optional-cargo-features

14:48 <ryan-summers[m]> Although https://github.com/rust-embedded/embedded-hal/issues/572 may be relevant

14:48 <ryan-summers[m]> Sounds like bus sharing on async is hard because the mutex type is nonstandard. Probably best to look at what embassy does

14:50 <ryan-summers[m]> But I would imagine the same principles applie as I referenced, where sharing is handled entirely externally to the driver implementation

14:50 <ryan-summers[m]> s/applie/apply/

15:14 <djdisodo[m]> <ryan-summers[m]> "But I would imagine the same..." <- so it seems like i don't have to care when implementing driver

15:14 <djdisodo[m]> but it seems like i should use embassy-embedded-hal when i need shared i2c bus since embedded-hal-bus doesn't support it

15:15 <ryan-summers[m]> Yeah, you'd use embassy-embedded-hal once you've implemented the driver. But don't implement the driver with dependencies on embassy, or you'll block anyone that wants to use it outside of embassy as well

15:16 <djdisodo[m]> btw embassy one doesn't seem to implement embedded-hal-async traits either, only has some bounds on them

15:16 <djdisodo[m]> wonder why....

15:16 <ryan-summers[m]> Yes it does? https://docs.embassy.dev/embassy-embedded-hal/git/default/shared_bus/asynch/i2c/struct.I2cDevice.html#impl-I2c-for-I2cDevice%3C'_,+M,+BUS%3E

15:17 <djdisodo[m]> nah it does

15:17 <djdisodo[m]> nice

16:01 <ryan-summers[m]> For anyone interested, I did some interesting stuff with C/Rust/bindgen stuff and embedded sensors and it ended up making life pretty easy for me, even though the firmware was in C. Wrote up a quick blog about it: https://blog.forged.dev/rust-for-c-projects/

16:05 <ryan-summers[m]> s/stuff//

16:09 <ryan-summers[m]> 100% open to constructive feedback on the post by the way, would like to do more interesting embedded blogging in the future :)