01:38 <re_irc> < (@adamgreig:matrix.org)> hah

01:39 <re_irc> < (@adamgreig:matrix.org)> you know how cortex_m::asm::delay, as of 0.6.5 (or https://github.com/rust-embedded/cortex-m/pull/312), was fixed to delay by more cycles to account for cortex-m7 cores being good

01:39 <re_irc> < (@adamgreig:matrix.org)> and that caused people to complain that on the cortex-m0, cortex-m3, cortex-m4 etc cores that can't dual-issue, delay now delays for 1.5x as long as it used to

01:40 <re_irc> < (@adamgreig:matrix.org)> the delay loop is a two-instruction "subs, bne", repeated x/2 times (for "delay(x)"), and on cortex-m4 that takes 3 clock cycles, so overall it's "1.5 * x" cycles

01:40 <re_irc> < (@adamgreig:matrix.org)> but on cortex-m7, it can actually issue both the subs and the bne simultaneously? in a single cycle? so it takes in total... "0.5 * x" cycles

01:40 <re_irc> < (@adamgreig:matrix.org)> which means it's actually _still wrong_ for cortex-m7 💀

01:40 <re_irc> < (@adamgreig:matrix.org)> can't please anyone

01:50 <re_irc> < (@adamgreig:matrix.org)> * any~one~core

01:50 <re_irc> < (@adamgreig:matrix.org)> * any core

02:39 <re_irc> <rjmp> : is that routine put in RAM? If i remember right from past experience, on some cores if you run from flash it is liable to be different clocks per loop based on alignment

05:28 <re_irc> <Félix the Newbie> What would you recommend as a no-std stack-based vector? I want to return a variable number (from 0 to N) of "Foo"s from a function, that's my only usecase.

05:37 <re_irc> <Félix the Newbie> Maybe https://crates.io/crates/arrayvec?

05:40 <re_irc> <Félix the Newbie> There also is this https://crates.io/crates/fixed-slice-vec

06:24 <re_irc> < (@korken89:matrix.org)> Félix the Newbie: "heapless::Vec" ?

06:24 <re_irc> < (@korken89:matrix.org)> https://docs.rs/heapless/latest/heapless/struct.Vec.html

06:28 <re_irc> < (@jspn:matrix.org)> If I know N at compile time, and I don't have too many different N's, I tend to use const generics. https://doc.rust-lang.org/reference/items/generics.html#const-generics

06:49 <re_irc> <Félix the Newbie> : Thanks! Do you know what're the main differences with array-vec? From a superficial pov, the implementation looks roughly the same.

06:49 <re_irc> < (@korken89:matrix.org)> Not sure

06:49 <re_irc> < (@korken89:matrix.org)> "heapless::Vec" copies the interface of "std::Vec" and just adds fallible interfaces where needed due to the max size limit

09:01 <re_irc> < (@adamgreig:matrix.org)> rjmp: Flash with icache, which I figure should be good for a two instruction loop :p

13:56 <re_irc> < (@jamesmunns:beeper.com)> Looks like the (C) RPi SDK supports BLE now on the Pico W: https://twitter.com/arturo182/status/1623129075203047426

13:58 <re_irc> < (@jamesmunns:beeper.com)> (ah j/k, still planned, not release: https://github.com/raspberrypi/pico-sdk/issues/1164)

14:00 <re_irc> < (@dirbaio:matrix.org)> some stuff https://github.com/georgerobotics/cyw43-driver/commit/3c31d0b91aa796d46be7a46ce10fbb9672ae12b9

14:01 <re_irc> < (@dirbaio:matrix.org)> seems incomplete though, no source for "cyw43_btbus_init" and co

14:02 <re_irc> < (@dirbaio:matrix.org)> hopefully they forgot to "git add" a ".c" file and it's not a blob 😂

14:02 <re_irc> < (@dirbaio:matrix.org)> * file,

14:18 <re_irc> < (@dirbaio:matrix.org)> and of course, getting it working in Rust means someone'll have to write a Rust bluetooth stack, just like all other chips... 😭

15:15 <re_irc> <riskable> Should I use a 32-bit timer as my monotonic timer ("stm32f4xx_hal") or are any of the 16-bit timers good enough?

15:15 <re_irc> <riskable> Like, are there tradeoffs/gotchas there?

15:16 <re_irc> < (@jamesmunns:beeper.com)> pretty much the tradeoffs are "range" and "precision"

15:16 <re_irc> < (@jamesmunns:beeper.com)> so mostly - if the 16-bit timer covers enough for your intervals at the clock rate you need for your precision, you are good to go

15:16 <re_irc> <riskable> I've been using a 32-bit timer but I realized that my IR receiver code might work better if I used a 32-bit timer but if I want to do that I need to shift some things around. I figured I could put the monotonic stuff on "TIM1" instead of "TIM2" and use "TIM2" for IR instead (since it's 32-bit)

15:17 <re_irc> < (@jamesmunns:beeper.com)> if you're asking for RTIC specifically, I think it's mostly how long the longest "next scheduled task" is? I'm not sure how they handle roll overs and stuff tho

15:17 <re_irc> <riskable> I wouldn't _think_ 1ms polling of USB devices would require 32-bit precision but the ws2812b LEDs and the IR sensor are much more timing-sensitive

15:18 <re_irc> <riskable> : Aha! Now _that_ makes sense! Yeah nothing is timed that far out for it to matter in my code. Everything is either on 1ms, protocol-specific (ws2811 protocol or IR protocols), or in the range of 1-5 seconds (for occasional sensor recalibration)

15:18 <re_irc> < (@jamesmunns:beeper.com)> "1ms / (2**16)" means you have a precision of 15ns/tick max (also depends on your clock rate, if it goes that high)

15:19 <re_irc> < (@jamesmunns:beeper.com)> but 10 seconds / "2 ** 16" is a precision of 152us

15:19 <re_irc> < (@jamesmunns:beeper.com)> which - probably still good enough if your max range is 10s and your needed precision is broader than 152us.

15:20 <re_irc> < (@jamesmunns:beeper.com)> note: probably check the rtic monotonic docs, I might be missing some other thing they are using it for that requires a longer practical range than your largest time delta for a scheduled task.

15:21 <re_irc> <riskable> Yeah the USB polling isn't _that_ sensitive. I've tested it (on Linux) and the kernel doesn't seem to give AF LOL. Even if your tell it you're doing 1ms polling and accidentally set your stuff to actually poll at 125Hz it still works. That doesn't work so well in Windows though! Just an FYI 😄

15:21 <re_irc> <riskable> : You're telling me to _RTFM_‽ Savage! 😄

15:22 <re_irc> <riskable> ...but I think I have much of the RTIC manual memorized by now anyway haha

15:22 <re_irc> <riskable> (it's really quite good)

15:22 <re_irc> <riskable> Now I'm thinking, "optimize!" and I'm looking at the data sheet for the STM32F411CEU6 and seeing that TIM9 is 16-bit and can only count UP. Sounds perfect for a monotonic timer 👍

15:23 <re_irc> <riskable> Been working in RP2040 land for long enough that I've forgotten how much of a PITA STM32 chips are. What's funny is that _back in the day_ STM32 were considered _the easy ones_! haha

15:23 <re_irc> < (@jamesmunns:beeper.com)> https://docs.rs/rtic-monotonic/latest/rtic_monotonic/trait.Monotonic.html has less about impl details than I might like

15:24 <re_irc> < (@jamesmunns:beeper.com)> but I think the trait contains enough information that if you did have a timer that has too low of a range (say: 10s), and you ask it to schedule 20-30s in the future, it might be smart enough to "count overflows"?

15:24 <re_irc> < (@jamesmunns:beeper.com)> it's been a while since I've poked around in those parts of RTIC :D

15:24 <re_irc> < (@dirbaio:matrix.org)> with the right impl you can use a 16bit timer and extend it to 32bit or higher by software, by counting overflows

15:25 <re_irc> < (@jamesmunns:beeper.com)> (if it does handle that, the "cost" is three extra interrupt triggers to "reload" the timer)

15:25 <re_irc> < (@dirbaio:matrix.org)> stm32f4xx-hal doesn't though

15:25 <re_irc> < (@jamesmunns:beeper.com)> yup, just make sure you're not firing roll-over interrupts every 100us or something lol

15:25 <re_irc> < (@dirbaio:matrix.org)> and handle race conditions around the rollover :P

15:26 <re_irc> < (@jamesmunns:beeper.com)> but 1/hour or minute or second is probably going to be fine, honestly.

15:26 <re_irc> < (@jamesmunns:beeper.com)> yeah - you probably want it to "saturate" if you are doing that, instead of "self resetting" back to zero and continuing.

15:27 <re_irc> < (@dirbaio:matrix.org)> make the hw timer saturate? you'd lose ticks this way if the isr is delayed

15:27 <re_irc> < (@jamesmunns:beeper.com)> I have a personal preference for "32-bit timer, at 1MHz", because it gives you >1h of range and 1us precision

15:27 <re_irc> < (@jamesmunns:beeper.com)> yeah, sorry, let me wave around some more "it depends" :D

15:28 <re_irc> < (@dirbaio:matrix.org)> It Depends™

15:28 <re_irc> < (@dirbaio:matrix.org)> as always :D

15:28 <re_irc> < (@jamesmunns:beeper.com)> "It Depends™ as a Service"

15:35 <re_irc> <riskable> OK so I tried it and TIM9 won't work as an RTIC monotonic timer because I'm using "stm32f4xx_hal::timer::monotonic::MonoTimer" and it's type signature requires a 32-bit timer:

15:35 <re_irc> pub struct MonoTimer<TIM, const FREQ: u32>(_);

15:37 <re_irc> <riskable> The specific error you'll see (if anyone else has this problem and searches for it) is this:

15:37 <re_irc> type mismatch resolving `<TIM10 as stm32f4xx_hal::timer::sealed::General>::Width == u32`

15:37 <re_irc> required for `stm32f4xx_hal::timer::MonoTimer<TIM10, 1000000>` to implement `rtic::Monotonic`

15:37 <re_irc> <riskable> (I also tried TIM10 before I figured out what was going on hehe)

15:38 <re_irc> <riskable> So FYI, the only valid timers for RTIC monotonic stuff (on stm32f411ceu6 and stm32f401ceu6 chips) are TIM2 and TIM5.

15:44 <re_irc> < (@jamesmunns:beeper.com)> this might be a limitation of the HAL itself, or rather: their blanket impl is too specific. You could likely impl the rtic::Monotonic trait on your own type that wraps the HAL type, or make a PR that adds impls for non-32-bit timers

15:45 <re_irc> < (@jamesmunns:beeper.com)> but depends on the yaks you'd like to shave.

16:53 <re_irc> < (@korken89:matrix.org)> Ping me if you need help, I have 16 bit timer impls

16:54 <re_irc> < (@korken89:matrix.org)> riskable: Ping me if you need help, I have 16 bit timer impls for the L4

17:40 <corecode> hi

17:42 <corecode> i'm planning to use rust on a silabs gecko mcu, which has this complicated build/configuration system. i'm wondering whether i should use the silabs stuff as a separate FFI crate and do the main app build using cargo, or whether i should build my rust stuff into a static library that i link with the silabs build in the end

18:20 <corecode> seeking suggestions on that topic

18:24 <re_irc> < (@chemicstry:matrix.org)> I'm not sure if anyone if familiar with that MCU here so you would have to explain what is the complicated build system. Is it some special firmware signing/uploading?

18:25 <re_irc> < (@chemicstry:matrix.org)> Because it is cortex-m core, so you should be able to use just rust

18:25 <re_irc> < (@chemicstry:matrix.org)> I'm not sure if anyone is familiar with that MCU here so you would have to explain what is the complicated build system. Is it some special firmware signing/uploading?

18:26 <re_irc> < (@chemicstry:matrix.org)> And then write your own HAL, or use silabs HAL with FFI

18:26 <corecode> it's cortex-m, but there is a lot of vendor code

18:26 <corecode> yea i think i'd use their HAL with FFI

20:18 <re_irc> <FredrikLL> I am trying to work with a Silabs chip as well. I am attempting to go the other way, everything in rust and using FFI for the Bluetooth API.

20:19 <re_irc> <FredrikLL> Based on my experience so far I think the other route would be easier.

21:05 <corecode> what do you mean by the other route? using their CRT and HAL and then interfacing into a rust app?

22:05 <re_irc> < (@chrysn:matrix.org)> Other than using bit-banded memory mappings (which are available on some cortex-m3), is there any cheaper way to concurrently set and clear bits than using atomics?

22:05 <re_irc> < (@chrysn:matrix.org)> (I don't care about the old values, I even know reliably what the old value is, but I need to avoid RMW errors in adjacent bits)

22:06 <re_irc> <dngrs (spookyvision@{github,cohost})> corecode: if you want some inspiration for how to FFI vendor code, my suggestion would probably be to look at cmsis dsp.rs (https://github.com/samcrow/cmsis_dsp.rs.git)

22:06 <re_irc> <dngrs (spookyvision@{github,cohost})> don't know anything about gecko specifically I'm afraid

22:13 <re_irc> <FredrikLL> corecode: I compile just the BLE stuff to a static lib and linking it into my rust project. Not using their HAL.

22:20 <corecode> re_irc: do you have a working HAL?