11:01 <thejpster[m]> I have a chip with atomic set/clear/xor aliases for every peripheral. Is there a way to get the register field shift and mask values from svd2rust generated code, so I can manually bash the set alias with the appropriate bitmask? It's weird to say `thing.register().read().field().bit()` but then `let p = thing.register().as_ptr(); p.add(0x3000).write(1 << 6);` I'd like to turn (register, field) into `1 << 6` somehow.

11:25 <burrbull[m]> <thejpster[m]> "I have a chip with atomic set/..." <- Interesting question. You can get `.offset()` and `width()` from `FieldWriter`, but it exists only inside `write` closure. So they useless for your case.

11:25 <burrbull[m]> But we already have atomic operation support. See https://docs.rs/svd2rust/latest/svd2rust/#the---atomics-flag and https://github.com/rust-embedded/svd2rust/blob/f864c3ef4c545b952881b186706a105b3774500b/src/generate/generic_atomic.rs#L51

11:30 <thejpster[m]> That looks like it’s using atomic types (which just lower to a volatile write and a fence). I have four addresses for every register.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rqRyUNEypuxGBBEbHnrhVqYK>)

11:33 <thejpster[m]> I guess in an ideal world there would be a set method that gives an s proxy to a closure, and you can only access single bit sized fields. Same for clear and toggle. But I don’t know how to do it in a portable way without just forking svd2rust. But rather than do that, accessing the shift values as a const would help.

11:33 <burrbull[m]> thejpster[m]: > <@thejpster:matrix.org> That looks like it’s using atomic types (which just lower to a volatile write and a fence). I have four addresses for every register.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FJqahggyVpTHkaFiFjmdkRyC>)

11:37 <thejpster[m]> Here’s an example: https://github.com/rp-rs/rp-hal/blob/885de2ea0730d02d03a12765d3ac3ef212aceb68/rp2040-hal/src/usb/errata5.rs#L141

11:37 <burrbull[m]> Like this https://github.com/rust-embedded/svd2rust/issues/535

11:37 <thejpster[m]> Ah, ha ha. Same chip. Yeah.

11:39 <thejpster[m]> I recently wrote some new stuff for it and I had to use the atomic writes to lower a &mut self down to a &self method, and in one case down to a free standing function to make it easier to call from an ISR where you don’t own the driver and I didn’t want to stick it in a mutex refcell option nightmare.

11:40 <thejpster[m]> I’m fine with calling write_bitmask_set by hand. I just need the const bitmask.

11:43 <dirbaio[m]> Maybe it's possible to add it via an extension trait?

11:43 <dirbaio[m]> Similar to this https://github.com/embassy-rs/embassy/blob/4e5a646f8b1905de014462f5f0441952ec7e209b/embassy-rp/src/lib.rs#L413

11:44 <dirbaio[m]> Impl it for all registers

11:44 <dirbaio[m]> From the hal

11:45 <burrbull[m]> I'm fine to add such extension. The issue that stopped #535 was that it is allowed not to all registers.

11:46 <burrbull[m]> <thejpster[m]> "I’m fine with calling write_bitm..." <- This is much more complex as requires to generate such mask for EACH field.

11:48 <thejpster[m]> Which you have already because the w proxy methods use it?

11:48 <thejpster[m]> dirbaio[m]: I’ll try this.

16:14 <corecode[m]> hi

16:16 <corecode[m]> can you suggest books/articles about hardware testing from firmware (self test), for production testing. i'm especially interested in formalisms for test procedures and test reporting

16:16 <corecode[m]> i've done the open coded turn a LED green or red, but i think it could be done much better

16:16 <corecode[m]> like keeping metrics during production

16:46 <JamesMunns[m]> ryan-summers gave a good talk at Oxidize this year about this

16:49 <LiamKinne[m]> https://www.youtube.com/watch?v=qcMXH6RT2hc

17:53 <ryan-summers[m]> Yeah I have some blog posts drafted up that I need to post... Will try and get to it this week and post a link :)

18:57 <dinkelhacker> regarding the talk: I don't get how probe.rs gets rid of the eeprom where calibration data is stored. I mean the argument is that with probe.rs I can write the settings directly to flash? Wouldn't I be able to do that with any flash programmer?

19:29 <LiamKinne[m]> Yeah that's not specific to probe-rs, but the point is you get both a CLI and library to write the code for your production tooling in.

19:36 <dinkelhacker> Right, but OpenOCD has that? So does trace32, and probably others aswell? I mean I get it: OpenOCD is much less convenient and trace32 is extremely expensive (and also less convenient). I'm just trying to understand how probe.rs is "fundementally different" than what is already exists.

19:44 <JamesMunns[m]> I think the point is that the probe-rs API, including integrated comms like rtt lowers the threshold substantially. I don't think it's novel, but rather, now accessible.

19:47 <dinkelhacker> That is also my understanding. Plus, it's much nicer to be able to write debugger scripts in rust than in some homegrown obscure scripting language.

21:03 <thejpster[m]> Please can someone tag https://github.com/rust-embedded/riscv/ with all the recent releases. Trying to fork the linker script, but I can't find exactly which linker script is used in the last release of riscv-rt.

21:07 <thejpster[m]> Meh, I copied it out of ~/.cargo for now.

22:25 <robtsuk[m]> Can anyone point me to an example of how to use https://docs.rs/embedded-hal-bus/0.2.0/embedded_hal_bus/spi/struct.AtomicDevice.html ?