03:04 <i509vcb[m]> wassasin pull request is here for the proposal: https://github.com/rust-embedded/embedded-hal/pull/649

03:05 <i509vcb[m]> I hacked up a "blinky using postcard over usb" example as well with the new embedded_hal_async::digital::OutputPin trait.

03:06 <i509vcb[m]> James Munns if you want to see it "hacked together in 2 hours" https://github.com/i509VCB/postcard-gpio-test/tree/master (I want to do something different here than having to declare each endpoint manually, but thats a different topic than the new traits)

03:08 <i509vcb[m]> I was curious and scope to it. With the overhead of usb transport I was getting a blink period (on then off) of 2.007 seconds (7ms overhead from USB).

03:08 <i509vcb[m]> * from USB per blink).

03:09 <i509vcb[m]> * curious and connected scope to, * from USB per blink).

03:10 <i509vcb[m]> The host in question is a Linux PC so 7ms isn't an unrealistic amount of time

11:00 <thejpster[m]> ok fine, I shaved the yak

11:00 <thejpster[m]> https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/MMIO.20structures/near/499195273

11:01 <thejpster[m]> I'm pretty sure this is exactly what core::ptr::addr_of_mut! was designed for, but opinions on general sound-ness welcome.

11:35 <dirbaio[m]> yeah that is sound afaik

11:36 <dirbaio[m]> i'm amused at your insistence of using structs for layout though :D

11:36 <dirbaio[m]> s/of/in/

11:44 <danielb[m]> <dirbaio[m]> "i'm amused at your insistence of..." <- yeah that's going to be fun to use when the registers are striped like CONF0, CONF1, CTRL0, CTRL1

13:05 <thejpster[m]> <dirbaio[m]> "i'm amused at your insistence of..." <- blame literally every SoC vendor. I'm starting with things like https://raw.githubusercontent.com/zephyrproject-rtos/hal_stm32/04ccc7798343ff51509c5d5276e3bce4375f50e6/stm32cube/stm32mp1xx/soc/stm32mp151axx_ca7.h

13:05 <thejpster[m]> (not that ship, that's just a public example I found)

13:06 <dirbaio[m]> yea but I mean, you also have the addressoffsets

13:06 <dirbaio[m]> so instead of doing `&raw mut (*self.ptr).control }` you can do `self.ptr.add(16)`

13:06 <dirbaio[m]> s/addressoffsets/address offsets/

13:14 <thejpster[m]> ST have been relatively kind here. Other vendors don't always do that.

13:14 <thejpster[m]> plus you could just write a macro to generate all the functions from a struct definition

13:14 <thejpster[m]> I don't know what syntax you'd use to derive the functions from ... a table of field names, types and offsets?

13:26 <dirbaio[m]> yaml 🙈

13:26 <dirbaio[m]> hahaha yeah I know that's not what you're looking for

13:27 <dirbaio[m]> many times PDFs only give you address offsets though

13:50 <thejpster[m]> we can perhaps agree that it's useful to give people choices

13:50 <thejpster[m]> and that people bouncing off embedded Rust because they don't want to learn YAML is a bad thing

13:51 <dirbaio[m]> lol! definitely

14:24 <thejpster[m]> s/ship/chip/

15:44 <thejpster[m]> TASKING just bought LDRA.

15:46 <JamesMunns[m]> TASKING seems to be a company that makes a tricore compiler, LDRA seems to be a company that does software validation tooling?

15:56 <thejpster[m]> Not only, but yes. Big players in the embedded space.

15:57 <thejpster[m]> https://bsky.app/profile/nyurik.bsky.social/post/3lhxhz75jts2d

16:55 <bogdan[m]> <thejpster[m]> "ok fine, I shaved the yak..." <- Does `rust fn read_data(&mut self) -> u32` _need_ `&mut`, or is it just a typo? Is it an _aliasing_ thing?

17:12 <bogdan[m]> s/rust//

17:36 <thejpster[m]> &self is probably fine for reads?

17:52 <thejpster[m]> These handles aren’t singletons - they are just unsafe to create.

17:52 <thejpster[m]> I do listen to dirbaio, sometimes! lol

17:53 <thejpster[m]> So you can race on a modify call if you make two of them, even though each has ‘exclusive’ access. Unsure if I should just make modify take & self or not.