ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
GenTooMan has joined #rust-embedded
<re_irc> <dirbaio> Is there some way to get "x * 1000 / 1000" to compile to a nop?
<re_irc> <dirbaio> like "x.unchecked_mul(1000) / 1000", but without UB if it actually overflows
<re_irc> <GrantM11235> "x * (1000 / 1000)"
<re_irc> <dirbaio> context: it's for converting times. It's actually "x * CONST / 1000"
<re_irc> <dirbaio> I want it to compile to "x" if "CONST=1000"
<re_irc> <dirbaio> "x/100" if "CONST=10"
<re_irc> <dirbaio> "x*1000" if "CONST=1000_000"
<re_irc> <dirbaio> etcetc
<re_irc> <GrantM11235> "x * (CONST / 1000)"
<re_irc> <dirbaio> like, scaling stuff while retaining the max range possible
<re_irc> <dirbaio> "x * (CONST / 1000)" compiles to "0" if CONST=10
<re_irc> <GrantM11235> oh
<re_irc> <GrantM11235> What do you want it to do if it overflows?
<re_irc> <dirbaio> ideally panic if overflow-checks=true, garbage otherwise
<re_irc> <dirbaio> but not UB
<re_irc> <dirbaio> hm
<re_irc> <dirbaio> "const fn gcd(a: u32, b: u32) -> u32", then "x * (CONST / GCD(CONST, 1000)) / (1000 / GCD(CONST, 1000))"
<re_irc> <dirbaio> * gcd(CONST, 1000)) / (1000 / gcd(CONST,
<re_irc> <dirbaio> seems cursed
<re_irc> <dirbaio> holy shit it works
<re_irc> <dirbaio> it doesn't really help if the tick rate is not a clean multiple, like "32768" in nrf... but at least it's not worse :D
<re_irc> <adamgreig> have you seen and (which it uses)?
<re_irc> <dirbaio> ohh
<re_irc> <adamgreig> I guess your Instant is basically doing the same thing as fugit::Instant there
<re_irc> <dirbaio> yes I had seen fugit but it didn't occur to me to look how it did it 😂
<re_irc> <adamgreig> or fugit::TimerInstantU64 to be specific heh
<re_irc> <dirbaio> same concept
<re_irc> <dirbaio> but zero generics in embassy :D
<re_irc> <adamgreig> fair
<re_irc> <adamgreig> your gcd implementation seems nicer than a dependency too, hm
<re_irc> <adamgreig> embassy doesn't support ticking at 1GHz though :P what if you wanted a PTP time driver?
unknown__ has joined #rust-embedded
<re_irc> <dirbaio> hahaha
creich_ has quit [Ping timeout: 250 seconds]
<cr1901> Yuhan Lin: Sorry, but I need a break from Rust code for a few days. Once I've recharged, I'll look at the PR and get it merged
<cr1901> and hopefully after that, msp430-rt won't need any more changes for a bit
<cr1901> I took on too many things at once, I just don't have the bandwidth to spare right now
starblue1 has quit [Ping timeout: 260 seconds]
starblue1 has joined #rust-embedded
<re_irc> <Yuhan Lin> no worries
<cr1901> Yuhan Lin: You've done an excellent job w/ the changes :D. This is on me biting off more than I could chew lol
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> <dngrs (spookyvision@github)> James Munns: looks like a good fit, thx!
<re_irc> <chrysn (> adamgreig: Thanks for the pointer, one more custom thing I can replace with something more generically managed, and one fewer set of conversions to hand-code.
<re_irc> <dngrs (spookyvision@github)> we need to enhance clippy towards "it looks like you're reimplementing <appropriate crate here>, are you sure you want to do that?"
<re_irc> <chrysn (> That'll be really tricky. What might be criteria -- having the same set of (Try)From implementations? My Ticks ( have only TryFromcore::time::Duration in common with the fugit::Duration, maybe not even that (just checking what it actually implements in terms of conversion)
<re_irc> <dngrs (spookyvision@github)> oh it's super hard for sure, I was mainly joking :D But I'd assume this is one of the few areas where large language models could be helpful, maybe.
<re_irc> <dngrs (spookyvision@github)> in unrelated news, if my flash memory init call crashes with "Error::UnexpectedStatus" since I probably wrote at an invalid address (power down even over night did not recover from it), is it safe to assume I've fried it?
<re_irc> <chrysn (> dngrs (spookyvision@github): Can you try with the precise code (locked crate versions etc) that worked previously? If so, quite possible (but knowing for sure will need details like what kind of flash and which crate it's used through).
<re_irc> <dngrs (spookyvision@github)> the crate version hasn't changed - it's "spi_memory" latest, 0.2. Crashing init code is
<re_irc> // also be deasserted.
<re_irc> // Here we don't expect any writes to be in progress, and the latch must
<re_irc> if !(status & (Status::BUSY | Status::WEL)).is_empty() {
<re_irc> <dngrs (spookyvision@github)> flash is winbond series 25
<re_irc> <chrysn (> if !(dbg!(status) & (Status::BUSY | Status::WEL)).is_empty() {
<re_irc> <chrysn (> Can you peek into the status, eg. using
<re_irc> if !(dbg!(status) & (Status::BUSY | Status::WEL)).is_empty() {
<re_irc> <chrysn (> (which will both tell which of the two tested flags are set, and whether anything else is set as well)
<re_irc> <dngrs (spookyvision@github)> not trivially since I'm using "defmt" for logging, but I can copy the crate and add that
<re_irc> <chrysn (> You can probably also cast (convert? not sure what bitflags provides) the status to u8 and look at it that way, comparing the bits with what's in
<re_irc> <chrysn (> but generally, if code is known to be good and hardware is unaltered and has been powered down and no component involved has any weird super-low-power states ... sounds bad
<re_irc> <dngrs (spookyvision@github)> yeah I just need the spi comms to take place and those aren't public
<re_irc> <dngrs (spookyvision@github)> maybe I can also just brute force go ahead with the init and ignore the dirty flags
<re_irc> <dngrs (spookyvision@github)> let's see what's in them first
<re_irc> <dngrs (spookyvision@github)> "BUSY | WEL | PROT | SRWD"
<re_irc> <chrysn (> Can you tell whether the undefined bits (0b1100000) are set as well? If so (and if that is uncommon, which I guess it is), the device may really not be sending anything any more, and just keep the line at the 1 level all the time.
<re_irc> <dngrs (spookyvision@github)> let's see
<re_irc> <dngrs (spookyvision@github)> yup, all 1s :<
<re_irc> <phlimy/azorlogh> Hello, can someone help me a bit with the nrf52? I have one with Adafruit bootloader, and I'm trying to understand how to use timers + interrupts. I tried making the most basic example but my mcu resets right as the timer hits 2 seconds
<re_irc> <diondokter> phlimy/azorlogh: The code looks fine imo. How do you know the MCU resets?
<re_irc> <diondokter> Maybe try to run it without the bootloader. Maybe that turns on the watchdog?
<re_irc> <phlimy/azorlogh> diondokter: There is an led which blinks whenever it resets
<re_irc> <phlimy/azorlogh> diondokter: I update flash it via usb because I don't have the device to flash it completely
<re_irc> <diondokter> You can query the reset reason with this register:
<re_irc> <phlimy/azorlogh> Ooh that's super useful
<re_irc> <phlimy/azorlogh> thanks I'll try that and report back
<re_irc> <phlimy/azorlogh> Okay the reset reason is CPU lockup apparently
<re_irc> <phlimy/azorlogh> I'm not sure what that means
<re_irc> <K900> Forgot to pet the watchdog maybe?
<re_irc> <xiretza> K900: hehe, I'm not the only one that uses that verb then
<re_irc> <firefrommoonlight> FYI I am making quadcopter firmware. Rust is working great! The struct and enum workflow makes organizing the somewhat complicated control system manageable. Had to translate a ST TOF sensor driver from C, but not a big deal. An ST dev tried to get it working with an automatic translater, but it didn't work
<re_irc> <firefrommoonlight> * that
<re_irc> <firefrommoonlight> Using Stm32H7. Set up with RTIC, although the interrupt flow is fairly simple so far, with a main loop timer at fixed rate, and IMU update ISR to set the PID as soon as readings are avail
<re_irc> <firefrommoonlight> Hoping to flight test within the next month
<re_irc> <phlimy/azorlogh> What's a watchdog here?
<re_irc> <xiretza> phlimy/azorlogh:
<re_irc> <phlimy/azorlogh> Aah does it mean the bootloader setup a timer to reset the device after a while, and because I use that same timer again without telling it not to reset it resets the device again ?
<re_irc> <K900> No, it's a separate timer
<re_irc> <K900> The bootloader might set it up to just reset the device if it doesn't signal that it's alive in 2 seconds
<re_irc> <phlimy/azorlogh> Oooh okay
<re_irc> <firefrommoonlight> Do y'all know how Rust native, and CMSIS-DSP sin and cos performance compare?
<re_irc> <James Munns> xiretza: I used that for the nrf52 hal too :D
<re_irc> <firefrommoonlight> Of note, the CMSIS ones are labeled "fast approximations", and use LUT plus interp
<re_irc> <firefrommoonlight> So probably faster than Rust native?
<re_irc> <adamgreig> I don't think the f64::sin etc methods are available on the thumb targets anyway, and they use libm's implementations on std platforms iirc
<re_irc> <phlimy/azorlogh> I don't understand how to pet the watchdog. The only way to get a watchdog handle is through the Watchdog struct which I can't create once the watchdog is already up and running
<re_irc> <K900> You should be able to just create a new handle
<re_irc> <dirbaio> why do you think it's the watchdog?
<re_irc> <phlimy/azorlogh> I made a handle with unsafe and it still resets
<re_irc> <phlimy/azorlogh> I don't think it's the watchdog
<re_irc> <phlimy/azorlogh> plus there's no mention of something like that in the adafruit bootloader
<re_irc> <dirbaio> set up some kind of logging (defmt, or something over uart)
<re_irc> <firefrommoonlight> adamgreig: Oh good point - Thanks! I haven't tried compiling this yet, and prototyped with the Rust methods
<re_irc> <dirbaio> and add log prints to see what the code is doing
<re_irc> <firefrommoonlight> Guess this makes it easy to choose CMSIS too
<re_irc> <dirbaio> in particular, log something on the panic handler and the HardFault handler
<re_irc> <dirbaio> you'll be able to see the reason of the crash
<re_irc> <dirbaio> most likely it's a panic
<re_irc> <dirbaio> like an ".unwrap()" failing or something
<re_irc> <firefrommoonlight> Of note, CMSIS also includes Quaternions (awesome) and a PID controller, although the PID controller seems only suitable for the most basic cases. Ie no anti windup, lowpass on deriv etc
<re_irc> <phlimy/azorlogh> Ok I'll do that and report back thanks
<re_irc> <adamgreig> JPL or hamiltonian quarternions?
<re_irc> <firefrommoonlight> Not sure yet lol!
<re_irc> <firefrommoonlight> That will come up soon though!
<re_irc> <phlimy/azorlogh> gah i'm struggling to setup usb serial logging so i'll give up for now, my rust keeb firmware can wait lol
bpye has joined #rust-embedded
bpye8 has quit [Ping timeout: 260 seconds]
<re_irc> <dngrs (spookyvision@github)> yeah it's not quite trivial, you first need to set up a usb cdc device etcblah ... anyway, "defmt_bbq" is nice once you have that going
<re_irc> <dngrs (spookyvision@github)> firefrommoonlight: I'll hopefully do some FFTs using CMSIS DSP on an f411 in the following weeks; once I've got it all set up I can do a comparison of fpu sin + cmsis sin if you're interested