04:50 <re_irc> <@grantm11235:matrix.org> Can anyone help me find some sort of workaround or something for my chipselect trait? I am still in the bargaining/denial stage 😭 https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fcfa8d5f4252938079eb22a16e0d2c6f

06:01 <re_irc> <@newam:matrix.org> Has anyone tried updating to defmt-test 0.3.0? For some reason the macros are not generating a `main` fn.

06:02 <re_irc> <@newam:matrix.org> ooooooooohhhhhhhhhhhhhhhhhh.

06:02 <re_irc> <@newam:matrix.org> I was creating my tests as `src/testname.rs` and they hid everything behind `cfg(test)`

06:03 <re_irc> <@newam:matrix.org> Hmmmmmmmmm. Is there a way to spoof `cfg(test)`?

06:28 <re_irc> <@newam:matrix.org> newam:matrix.org: No good way unfortunately, `RUSTFLAGS='--cfg test'` works, but no one wants to type that out.

06:28 <re_irc> <@newam:matrix.org> I switched them back into tests from binaries, the output ELFs don't have a stable name anymore, but it still works.

09:53 <re_irc> <@gauteh:matrix.org> I'm trying to figure out why my interrupts doesn't work. Is there supposed to be a mention of `PRIMASK` when I objdump? I see that in the C examples there is some assembly that sets it, but if I try to do the same (using asm!) the program halts (I think).

10:08 <re_irc> <@adamgreig:matrix.org> You shouldn't need to touch it just to get interrupts working

10:13 <re_irc> <@gauteh:matrix.org> It seems like what the C code does is same as `cortex_m::interrupt::enable()`

10:14 <re_irc> <@gauteh:matrix.org> If I put that in my code it also just halts there... Maybe I have enabled some interrupt that I do not handle

10:15 <re_irc> <@gauteh:matrix.org> Do I usually need to call `interrupt::enable()`? I see that the primask.is_active is false before I do it

10:16 <re_irc> <@gauteh:matrix.org> I mean interrupts work in the sense that `wfi` continues, but my interrupt handler does not seem to be called.

10:16 <re_irc> <@gauteh:matrix.org> (without `enable()`)

10:24 <re_irc> <@adamgreig:matrix.org> Interrupts enabled should be the default state unless you've called disable

10:24 <re_irc> <@adamgreig:matrix.org> It's a bit weird that your program halts if you enable it admittedly

10:25 <re_irc> <@adamgreig:matrix.org> Do you have any kind of debugger you could use to see where program execution is when it halts? Or to put a breakpoint in the interrupt handler?

10:29 <re_irc> <@gauteh:matrix.org> Don't have a debugger at hand unfortunately. hs-probe in the mail (i think). `primask.is_active()` is false if I don't do anythin.

10:32 <re_irc> <@gauteh:matrix.org> It could be that once I enable all interrupts the interrupts keep firing and are not handled, and therefore the program does not continue?

10:45 <re_irc> <@adamgreig:matrix.org> Yes, perhaps

10:45 <re_irc> <@adamgreig:matrix.org> The default handler in cortex-m-rt will just loop forever, so if you have enabled (in both nvic and in the peripheral that generates it) an interrupt which you don't have a handler for, it will hang there

10:45 <re_irc> <@adamgreig:matrix.org> How are you defining your interrupt handler?

10:49 <re_irc> <@gauteh:matrix.org> Like this modulo infinite attempts later: https://github.com/gauteh/ambiq-rs/blob/main/boards/redboard-nano/examples/rtc_alarm.rs#L71

10:50 <re_irc> <@gauteh:matrix.org> I use `set_bit` to clear the interrupt (not clear_bit as in the code there)

10:57 <re_irc> <@ryan-summers:matrix.org> What's the magic sugar to get GDB to allow me to read memory mapped register addresses? It's giving me a "Cannot access memory at address" error and `info mem` shows that RAM/memory-mapped registers aren't in the regions listed

10:58 <re_irc> <@adamgreig:matrix.org> set mem inaccessible-by-default off

10:58 <re_irc> <@ryan-summers:matrix.org> Ah thank you. I always forget that one

10:59 <re_irc> <@adamgreig:matrix.org> gauteh:matrix.org: Looks ok at a glance... does the HAL enable the interrupt in NVIC as well as in the RTC?

11:00 <re_irc> <@gauteh:matrix.org> Yes, it's in the same repo: https://github.com/gauteh/ambiq-rs/blob/rtc-alarm-attempts/ambiq-hal/src/rtc.rs#L100

11:02 <re_irc> <@gauteh:matrix.org> I try to use the C HAL mixed in as well, but I've disabled it for the attempts to make sure that it doesn't mess with the interrupts.

11:56 <re_irc> <@thejpster:matrix.org> New knurling things to play with - https://twitter.com/FerrousSystems/status/1458394195861909513

12:00 <re_irc> <@ryan-summers:matrix.org> Definitely need to eventually look into defmt logging. Does it allow you to send logs to some on-device backend?

12:53 <re_irc> <@jamesmunns:beeper.com> Yup, you can define a sink (sort of like a global logger), that could be over RTT, could be to RAM, could be to serial

12:53 <re_irc> <@jamesmunns:beeper.com> The only "backend" we maintain is the RTT one

12:54 <re_irc> <@korken89:matrix.org> Does anyone know if defmt 0.3 is backwards compatible with 0.2? I'm looking to update a lot of crates that I'm maintaining, but not sure if this is a breaking change.

12:54 <re_irc> <@korken89:matrix.org> Most likely it is, due to the changes in featuers

13:24 <re_irc> <@jamesmunns:beeper.com> korken89 there's a migration guide: https://defmt.ferrous-systems.com/migration-02-03.html

13:24 <re_irc> <@jamesmunns:beeper.com> I do believe it's breaking though.

13:33 <re_irc> <@korken89:matrix.org> Yeah, if a app uses 0.2 and a dep uses 0.3 we get problem

13:34 <re_irc> <@korken89:matrix.org> `error: failed to select a version for 'defmt'.`

14:09 <re_irc> <@korken89:matrix.org> Okey, one can include both 0.2 and 0.3 in libraries and implement Format based on 2 rename crates. So one has `defmt02` and `defmt03` crates

14:09 <re_irc> <@korken89:matrix.org> And select one of them based on a feature flag

14:11 <re_irc> <@korken89:matrix.org> defmt02 = { version = "0.2", package = "defmt", optional = true }

14:11 <re_irc> <@korken89:matrix.org> defmt03 = { version = "0.3", package = "defmt", optional = true }

14:12 <re_irc> <@korken89:matrix.org> And in the code where `#[derive(Format)]` is used one does:

14:12 <re_irc> <@korken89:matrix.org> use defmt02 as defmt;

14:12 <re_irc> <@korken89:matrix.org> #[cfg(feature = "defmt02")]

14:12 <re_irc> <@korken89:matrix.org> #[cfg(feature = "defmt03")]

14:12 <re_irc> <@korken89:matrix.org> use defmt03 as defmt;

14:12 <re_irc> <@korken89:matrix.org> Not too bad

14:13 <re_irc> <@korken89:matrix.org> Maybe if one has custom `Format` impls one need to define 2 - not sure

14:17 <re_irc> <@korken89:matrix.org> James Munns: Maybe this is a good thing to add to the migration guide?

14:17 <re_irc> <@korken89:matrix.org> "Non breaking update of defmt for libs

14:18 <re_irc> <@jamesmunns:beeper.com> I'm not in charge of knurling, but I can't see it hurting!

14:18 <re_irc> <@korken89:matrix.org> Ah sorry, I thought you steered that ship :)

14:18 <re_irc> <@jamesmunns:beeper.com> not in a looooong time

14:19 <re_irc> <@jamesmunns:beeper.com> Just an enthusiastic user and hype-man :)

14:19 <re_irc> <@jamesmunns:beeper.com> Feel free to open an issue/PR, and I'll ping folks internally about it!

14:24 <re_irc> <@korken89:matrix.org> Hmm, maybe I was overly confident - event with 2 packages and none used I get errors

14:27 <re_irc> <@korken89:matrix.org> Odd, we used the same trick in `cortex-m-rtic` for `cortex-m` `0.6`/`0.7`

14:28 <re_irc> <@korken89:matrix.org> Not sure what is different with `defmt`

14:29 <re_irc> <@korken89:matrix.org> Hmm... `cortex-m` also uses the `links` keyword so it should work for defmt as well

14:35 <re_irc> <@korken89:matrix.org> I'm testing here if someone has any idea: https://github.com/japaric/heapless/blob/dual-defmt/Cargo.toml#L37

17:14 <re_irc> <@firefrommoonlight:matrix.org> Hoping this new version allows printing arbitrary len arrays instead of powers of 10 only

17:15 <re_irc> <@grantm11235:matrix.org> dirbaio: I think that https://github.com/rust-embedded/embedded-hal/pull/323 is a really good idea. Have you considered also restricting the word type somehow to always be the same between the read and write traits? (We can discuss this in the PR if you prefer, I'm just worried that it would completely derail the PR 😜)

17:16 <re_irc> <@firefrommoonlight:matrix.org> Love the improvements to cargo.toml etc

18:07 <re_irc> <@dirbaio:matrix.org> grantm11235:matrix.org: `ReadWrite<W>` already requires `Read<W> + Write<W>` for the same `W` so I guess this is already the case?

18:34 <re_irc> <@come_744:converser.eu> (About 323, `ManagedCS(ImplementingTraitUsingDefaults)` then `impl Trait for ManagedCS { fn associated(args) { csdown(); self.0.associated(args); csup(); } }` would be too OO style?)

18:53 <re_irc> <@osten_music:matrix.org> Wondering if anyone involved in the `stm32h7xx-hal` project can point me in the right direction. I'm trying to adapt the `flash` implementation from `stm32f4xx-hal` and add it to the stm32h7xx-hal project, so its possible to easily erase and write to the FLASH of the device for a bootloader application.

18:54 <re_irc> <@osten_music:matrix.org> My problem mainly at the moment is that in `stm32h7xx-hal` I have no access to the CR, SR and KEYR registers of the FLASH for some reason and I'm scratching my head trying to figure this out.

18:54 <re_irc> <@osten_music:matrix.org> Any assistance would be awesome, thanks!

18:55 <re_irc> <@newam:matrix.org> A common technique is to remove dangerous registers from the peripheral struct somewhere in the HAL. Check the type of the FLASH peripheral and make sure it is what you expect.

18:56 <re_irc> <@newam:matrix.org> If the struct is coming directly from the peripheral access crate and is missing the regs then the device SVD (system view description) likely needs to be updated/patched in the stm32-rs/stm32-rs repo.

19:01 <re_irc> <@firefrommoonlight:matrix.org> I didn't impl Flash on H7 because it's diff from the others and I'm lazy

19:01 <re_irc> <@firefrommoonlight:matrix.org> Shouldn't be too tough though. More complicated IIRC

19:02 <re_irc> <@newam:matrix.org> I guess I missed a step 1 there, check the reference manual to make sure the registers exist to begin with 😆

19:05 <re_irc> <@firefrommoonlight:matrix.org> I should probably just impl it - have an H7 project that will need persistent storage

19:05 <re_irc> <@firefrommoonlight:matrix.org> Maybe this weekend. You can copy it in h7xx Hal etc

19:07 <re_irc> <@osten_music:matrix.org> fi

19:07 <re_irc> <@osten_music:matrix.org> I'd probably spend 2 weeks trying to figure it out

19:53 <re_irc> <@adamgreig:matrix.org> woo, my solokeys key arrived! I think now the second thing i've ordered online that arrives running rust firmware?

19:53 <re_irc> <@adamgreig:matrix.org> that I know of, anyway 🤔

19:54 <re_irc> <@adamgreig:matrix.org> PID is 0xBEEE, amazing

19:59 <re_irc> <@therealprof:matrix.org> Weee, hope mine arrive soon, too.

19:59 <re_irc> <@adamgreig:matrix.org> mine arrived from germany so yours can't be far behind!

19:59 <re_irc> <@adamgreig:matrix.org> assuming you were also a kickstarter backer anyway

20:01 <re_irc> <@bobmcwhirter:matrix.org> those are yubi-like?

20:01 <re_irc> <@adamgreig:matrix.org> yep, same concept as a yubikey, supports u2f/webauthn/fido protocols

20:01 <re_irc> <@therealprof:matrix.org> I sure am, it's my second round even.

20:02 <re_irc> <@adamgreig:matrix.org> doesn't do the gpg of yubikey (yet anyway), but is open source hardware/firmware and also it runs rust, plus mine has transparent epoxy with glitter in for bonus fun

20:02 <re_irc> <@bobmcwhirter:matrix.org> if they had a USBC Somu

20:02 <re_irc> <@bobmcwhirter:matrix.org> I love my tiny usbc yubi

20:05 <re_irc> <@adamgreig:matrix.org> they do have usb-c ones, but not super tiny ones

20:05 <re_irc> <@adamgreig:matrix.org> the usb-a is a very cute works-either-way-up design though

20:12 <re_irc> <@therealprof:matrix.org> Maybe the USB-C ones will take longer, I only have those.

20:51 <re_irc> <@dirbaio:matrix.org> korken89:matrix.org: that doesn't work due to https://github.com/knurling-rs/defmt/issues/426

20:51 <re_irc> <@dirbaio:matrix.org> https://github.com/knurling-rs/defmt/blob/main/defmt/Cargo.toml#L13

20:51 <re_irc> <@dirbaio:matrix.org> arguably a cargo bug...

20:53 <re_irc> <@dirbaio:matrix.org> firefrommoonlight:matrix.org: it doesn't :( https://github.com/knurling-rs/defmt/blob/main/defmt/src/impls/arrays.rs#L33

20:53 <re_irc> <@dirbaio:matrix.org> I wonder if that can be changed to const generics without it being a breaking change... :S It would be great if it was possible

20:54 <re_irc> <@newam:matrix.org> dirbaio:matrix.org: I would say so, there are a lot of issues with how cargo handles features.

22:11 <re_irc> <@firefrommoonlight:matrix.org> Oh lame!

22:11 <re_irc> <@firefrommoonlight:matrix.org> It's a nitpick though. I love defmt, and the Cargo.toml changes

22:12 <re_irc> <@firefrommoonlight:matrix.org> Good to know it supports powers of 2 also

22:12 <re_irc> <@firefrommoonlight:matrix.org> I wonder what the limfac is here

22:12 <re_irc> <@firefrommoonlight:matrix.org> Seems like you could work around it using a script

22:12 <re_irc> <@firefrommoonlight:matrix.org> With 0 padding

22:13 <re_irc> <@firefrommoonlight:matrix.org> Or stringing together multiple print statements

22:17 <re_irc> <@dirbaio:matrix.org> you can just make it a slice

22:18 <re_irc> <@dirbaio:matrix.org> only downside is it has to include the length in the encoded stream

22:18 <re_irc> <@dirbaio:matrix.org> vs with fixed-size arrays the decoder already knows the size

22:34 <re_irc> <@firefrommoonlight:matrix.org> The slice still needs to be an approved size

22:34 <re_irc> <@firefrommoonlight:matrix.org> AFAIK

22:34 <re_irc> <@firefrommoonlight:matrix.org> You could print a 256 byte slice, then a 128 byte slice etc until you get the right length?

23:00 <re_irc> <@grantm11235:matrix.org> dirbaio:matrix.org: Ah, I didn't notice that. I was thinking about adding a `Word` associated type to the `Spi` trait, but I guess that would just be a rehash of https://github.com/rust-embedded/embedded-hal/pull/321 . Now that I think about it, using an associated word type would means that we couldn't have it default to `u8`

23:24 <re_irc> <@dirbaio:matrix.org> firefrommoonlight:matrix.org: slices can be of any len. arrays hvae to be one of the preapproved lens, unless you coerce them to a slice and then print that

23:24 <re_irc> <@dirbaio:matrix.org> grantm11235:matrix.org: yeah the problem with associated types is a HAL can't implement mulitple word sizes at the same time

23:24 <re_irc> <@dirbaio:matrix.org> with generic traits it can

23:25 <re_irc> <@dirbaio:matrix.org> and in my PR the way it's setup if you do `T: ReadWrite<u16>` then that includes `Read<u16>` and `Write<u16>`, so it's kinda "forcing" word sizes are the same

23:26 <re_irc> <@dirbaio:matrix.org> but still allowing HALs to implement multiple word sizes

23:26 <re_irc> <@dirbaio:matrix.org> or drivers to use multiple, like `where T: ReadWrite<u8> + ReadWrite<u16>`

23:26 <re_irc> <@dirbaio:matrix.org> which would be weird

23:51 <re_irc> <@firefrommoonlight:matrix.org> It doesn't work for slices for me unless they're an approved size

23:51 <re_irc> <@firefrommoonlight:matrix.org> I'm probably doing something wrong