crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
emerent has joined #rust-embedded
emerent is now known as Guest999
Guest999 has quit [Killed ( (Nickname regained by services))]
emerent has joined #rust-embedded
alixgoover has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Quit: Leaving]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <> Can anyone help me find some sort of workaround or something for my chipselect trait? I am still in the bargaining/denial stage 😭
fabic has quit [Ping timeout: 240 seconds]
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc> <> Has anyone tried updating to defmt-test 0.3.0? For some reason the macros are not generating a `main` fn.
<re_irc> <> ooooooooohhhhhhhhhhhhhhhhhh.
<re_irc> <> I was creating my tests as `src/` and they hid everything behind `cfg(test)`
<re_irc> <> Hmmmmmmmmm. Is there a way to spoof `cfg(test)`?
<re_irc> <> No good way unfortunately, `RUSTFLAGS='--cfg test'` works, but no one wants to type that out.
<re_irc> <> I switched them back into tests from binaries, the output ELFs don't have a stable name anymore, but it still works.
tokomak has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
<re_irc> <> 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).
<re_irc> <> You shouldn't need to touch it just to get interrupts working
<re_irc> <> It seems like what the C code does is same as `cortex_m::interrupt::enable()`
<re_irc> <> If I put that in my code it also just halts there... Maybe I have enabled some interrupt that I do not handle
<re_irc> <> Do I usually need to call `interrupt::enable()`? I see that the primask.is_active is false before I do it
<re_irc> <> I mean interrupts work in the sense that `wfi` continues, but my interrupt handler does not seem to be called.
<re_irc> <> (without `enable()`)
<re_irc> <> Interrupts enabled should be the default state unless you've called disable
<re_irc> <> It's a bit weird that your program halts if you enable it admittedly
<re_irc> <> 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?
<re_irc> <> 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.
<re_irc> <> It could be that once I enable all interrupts the interrupts keep firing and are not handled, and therefore the program does not continue?
<re_irc> <> Yes, perhaps
<re_irc> <> 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
<re_irc> <> How are you defining your interrupt handler?
<re_irc> <> Like this modulo infinite attempts later:
<re_irc> <> I use `set_bit` to clear the interrupt (not clear_bit as in the code there)
<re_irc> <> 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
<re_irc> <> set mem inaccessible-by-default off
<re_irc> <> Ah thank you. I always forget that one
<re_irc> <> Looks ok at a glance... does the HAL enable the interrupt in NVIC as well as in the RTC?
<re_irc> <> Yes, it's in the same repo:
<re_irc> <> 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.
fabic has joined #rust-embedded
<re_irc> <> New knurling things to play with -
<re_irc> <> Definitely need to eventually look into defmt logging. Does it allow you to send logs to some on-device backend?
<re_irc> <> 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
<re_irc> <> The only "backend" we maintain is the RTT one
<re_irc> <> 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.
<re_irc> <> Most likely it is, due to the changes in featuers
<re_irc> <> korken89 there's a migration guide:
<re_irc> <> I do believe it's breaking though.
<re_irc> <> Yeah, if a app uses 0.2 and a dep uses 0.3 we get problem
<re_irc> <> `error: failed to select a version for 'defmt'.`
<re_irc> <> 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
<re_irc> <> And select one of them based on a feature flag
<re_irc> <> defmt02 = { version = "0.2", package = "defmt", optional = true }
<re_irc> <> defmt03 = { version = "0.3", package = "defmt", optional = true }
<re_irc> <> And in the code where `#[derive(Format)]` is used one does:
<re_irc> <> use defmt02 as defmt;
<re_irc> <> #[cfg(feature = "defmt02")]
<re_irc> <> #[cfg(feature = "defmt03")]
<re_irc> <> use defmt03 as defmt;
<re_irc> <> Not too bad
<re_irc> <> Maybe if one has custom `Format` impls one need to define 2 - not sure
<re_irc> <> James Munns: Maybe this is a good thing to add to the migration guide?
<re_irc> <> "Non breaking update of defmt for libs
<re_irc> <> I'm not in charge of knurling, but I can't see it hurting!
<re_irc> <> Ah sorry, I thought you steered that ship :)
<re_irc> <> not in a looooong time
<re_irc> <> Just an enthusiastic user and hype-man :)
<re_irc> <> Feel free to open an issue/PR, and I'll ping folks internally about it!
<re_irc> <> Hmm, maybe I was overly confident - event with 2 packages and none used I get errors
<re_irc> <> Odd, we used the same trick in `cortex-m-rtic` for `cortex-m` `0.6`/`0.7`
<re_irc> <> Not sure what is different with `defmt`
<re_irc> <> Hmm... `cortex-m` also uses the `links` keyword so it should work for defmt as well
<re_irc> <> I'm testing here if someone has any idea:
emerent_ has joined #rust-embedded
emerent is now known as Guest9840
Guest9840 has quit [Killed ( (Nickname regained by services))]
emerent_ is now known as emerent
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
cr1901 has joined #rust-embedded
kehvo has joined #rust-embedded
<re_irc> <> Hoping this new version allows printing arbitrary len arrays instead of powers of 10 only
<re_irc> <> dirbaio: I think that 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 😜)
<re_irc> <> Love the improvements to cargo.toml etc
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <> `ReadWrite<W>` already requires `Read<W> + Write<W>` for the same `W` so I guess this is already the case?
<re_irc> <> (About 323, `ManagedCS(ImplementingTraitUsingDefaults)` then `impl Trait for ManagedCS { fn associated(args) { csdown(); self.0.associated(args); csup(); } }` would be too OO style?)
<re_irc> <> 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.
<re_irc> <> 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.
<re_irc> <> Any assistance would be awesome, thanks!
<re_irc> <> 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.
<re_irc> <> 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.
<re_irc> <> I didn't impl Flash on H7 because it's diff from the others and I'm lazy
<re_irc> <> Shouldn't be too tough though. More complicated IIRC
<re_irc> <> I guess I missed a step 1 there, check the reference manual to make sure the registers exist to begin with 😆
<re_irc> <> I should probably just impl it - have an H7 project that will need persistent storage
<re_irc> <> Maybe this weekend. You can copy it in h7xx Hal etc
<re_irc> <> fi
<re_irc> <> I'd probably spend 2 weeks trying to figure it out
<re_irc> <> woo, my solokeys key arrived! I think now the second thing i've ordered online that arrives running rust firmware?
<re_irc> <> that I know of, anyway 🤔
<re_irc> <> PID is 0xBEEE, amazing
<re_irc> <> Weee, hope mine arrive soon, too.
<re_irc> <> mine arrived from germany so yours can't be far behind!
<re_irc> <> assuming you were also a kickstarter backer anyway
<re_irc> <> those are yubi-like?
<re_irc> <> yep, same concept as a yubikey, supports u2f/webauthn/fido protocols
<re_irc> <> I sure am, it's my second round even.
<re_irc> <> 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
<re_irc> <> if they had a USBC Somu
<re_irc> <> I love my tiny usbc yubi
<re_irc> <> they do have usb-c ones, but not super tiny ones
<re_irc> <> the usb-a is a very cute works-either-way-up design though
<re_irc> <> Maybe the USB-C ones will take longer, I only have those.
tokomak has quit [Ping timeout: 245 seconds]
<re_irc> <> that doesn't work due to
<re_irc> <> arguably a cargo bug...
<re_irc> <> it doesn't :(
<re_irc> <> 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
<re_irc> <> I would say so, there are a lot of issues with how cargo handles features.
<re_irc> <> Oh lame!
<re_irc> <> It's a nitpick though. I love defmt, and the Cargo.toml changes
<re_irc> <> Good to know it supports powers of 2 also
<re_irc> <> I wonder what the limfac is here
<re_irc> <> Seems like you could work around it using a script
<re_irc> <> With 0 padding
<re_irc> <> Or stringing together multiple print statements
<re_irc> <> you can just make it a slice
<re_irc> <> only downside is it has to include the length in the encoded stream
<re_irc> <> vs with fixed-size arrays the decoder already knows the size
<re_irc> <> The slice still needs to be an approved size
<re_irc> <> AFAIK
<re_irc> <> You could print a 256 byte slice, then a 128 byte slice etc until you get the right length?
<re_irc> <> 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 . Now that I think about it, using an associated word type would means that we couldn't have it default to `u8`
<re_irc> <> 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
<re_irc> <> yeah the problem with associated types is a HAL can't implement mulitple word sizes at the same time
<re_irc> <> with generic traits it can
<re_irc> <> 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
<re_irc> <> but still allowing HALs to implement multiple word sizes
<re_irc> <> or drivers to use multiple, like `where T: ReadWrite<u8> + ReadWrite<u16>`
<re_irc> <> which would be weird
<re_irc> <> It doesn't work for slices for me unless they're an approved size
<re_irc> <> I'm probably doing something wrong
fabic has joined #rust-embedded