00:28 <bpye> My hunch is no - but can anyone think how you could parameterise https://gist.github.com/benpye/d200aaf14726b31e5062920dec0dfb6c based on MAX_INPUT/MAX_OUTPUT, so that the register clobbers would be accurate for the given in/out size? It's not super critical, but I suspect not wiping out most of my registers each time I want to use it would be

00:28 <bpye> beneficial

00:30 <bpye> Well, I guess I could use a macro to generate all 256 possible cases in a match statement and then force inlining, but it would be nice if there was a better option

00:33 <dirbaio[m]> yeah, you'll have to use macros...

00:33 <dirbaio[m]> I don't htink it's possible otherwise

00:58 <luojia65[m]> <JonathanDickinso> "Look into the transaction fns..." <- https://github.com/bouffalolab/bl_docs/blob/main/BL808_RM/en/RST/I2C.rst

01:07 <JonathanDickinso> <luojia65[m]> "https://github.com/bouffalolab/..."; <- It looks like it's just bizarre nomenclature. You want to do a regular write_read. This will explain it better: https://www.ti.com/lit/an/slva704/slva704.pdf

01:07 <luojia65[m]> Thanks! I'll check it out.

01:07 <JonathanDickinso> In other words, sub_addr is the same thing as an register in idiomatic I2C

01:59 <M9names[m]> I think you're correct in that it's strange nomenclature, but not what the meaning is.

01:59 <M9names[m]> My current understanding of this boufallo i2c controller is that you're supposed to batch together multiple messages inside the buffer, so it kinda maps to the e-h i2c transaction.

01:59 <M9names[m]> So sub address is the device address for a read or write inside the current batch of operations.

02:02 <M9names[m]> I did add an issue for it for bl602-hal, which looks to the impls in the various C SDK.

02:02 <M9names[m]> https://github.com/sipeed/bl602-hal/issues/49

04:09 <bpye> dirbaio[m] I did get it working with macros - https://gist.github.com/benpye/6f326c9baa5fa99c9b43bde19c755796 - it's kinda ugly but so long as the compiler gets rid of the nested match, which should be trivial, I guess it's fine

04:09 <bpye> I can hide it in a crate and never think of it again

13:00 <TomB[m]> Is volvo using Rust in their ECUs? this makes me believe they are a looking or have been trying it out? https://medium.com/volvo-cars-engineering/the-reality-of-autosar-and-the-way-forward-36af39ec4099

13:00 <TomB[m]> s/volvo/Volvo/

13:01 <TomB[m]> "We at volvo implement a full ECU in Rust"

13:04 <Jonathan[m]1> I'm starting a crate for ARMv7R (focus) and ARMv7A (secondary objective) for basic CPU access and runtime. I want to know if anyone:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yjyjhZpiJjOgZIlkZaytvXzf>)

13:15 <jessebraham[m]> <TomB[m]> "Is volvo using Rust in their..." <- IIRC they were using `atsamd-hal`

13:15 <jessebraham[m]> Or at the very least they were using some ATMEL (Microchip?) device with an open-source Rust HAL haha, I never actually heard them explicitly say which lib

13:41 <thejpster[m]> a question on the Zulip about "How many features is reasonable?". An MSP430 is offered up as an example: https://rust-lang.zulipchat.com/#narrow/stream/318791-t-crates-io/topic/5.20billion.20features/near/396896776

13:43 <diondokter[m]> Or embassy stm32: https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/Cargo.toml

13:43 <diondokter[m]> Embassy time too: https://github.com/embassy-rs/embassy/blob/main/embassy-time/Cargo.toml

13:44 <diondokter[m]> What do they want to set the limit to?

13:45 <thejpster[m]> Someone suggested 1000 features, as that allows the windows crate to still work. You'll have to check out the thread.

13:45 <thejpster[m]> But I think it's the size of this file that might be the issue: https://index.crates.io/em/ba/embassy-time

13:45 <diondokter[m]> Oh I see, they got a bug report about a crate with 23K features because it was slow

13:45 <thejpster[m]> (although embassy-time seems fine)

13:46 <dirbaio[m]> very lol

13:46 <thejpster[m]> https://github.com/rust-lang/crates.io/issues/7269 is the original ticket

13:50 <vollbrecht[m]> diondokter[m]: every single line in that code is a feature? 🤣

13:52 <vollbrecht[m]> * is every single

13:52 <vollbrecht[m]> * is every single line in that code a feature? 🤣

13:52 <thejpster[m]> it's an image library. "To speed up compilation" every image has its own feature flag

13:57 <thejpster[m]> I won't say who just wrote this in the company chat:

13:57 <thejpster[m]> > svd2rust should generate one Cargo feature per MMIO register to improve build times.

14:02 <dirbaio[m]> wat

14:04 <TomB[m]> <thejpster[m]> "I won't say who just wrote..." <- > <@thejpster:matrix.org> I won't say who just wrote this in the company chat:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hBxeAshYHCzYKLcCbVYWjooe>)

14:04 <TomB[m]> based on chiptool

14:06 <TomB[m]> when I tried it like 4 years ago with svd2rust it took 10min

14:06 <TomB[m]> untenable, and the whole reason it went with the python ral generator, Ian ported all that to a chiptool fork which was really quite nice

14:08 <TomB[m]> I can only imagine trying to use svd2rust on something like a s32k/s32z...

16:05 <eZioPan[m]> I just find a rustc nightly feature that enable multi-thread compiling, which decreases stm32f4 build time around 42%

16:05 <eZioPan[m]> https://github.com/rust-lang/compiler-team/issues/681

19:36 <danielb[m]> 80% of my build times are in codegen because I like my binaries unnecessarily small. The rest of time rustc tries to cope with ~400 crates of dependency tree, more or less perfectly well feeding my 4-6 cores. I'm not hoping from much gain from this :)

19:36 <danielb[m]> s/from/for/