<re_irc>
<thejpster> Clearly I cannot operate a computer. That's a comment under the AdaCore story. But still.
fooker has quit [Ping timeout: 250 seconds]
limpkin has quit [Remote host closed the connection]
limpkin has joined #rust-embedded
fooker has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
fabic has joined #rust-embedded
m5zs7k has quit [Ping timeout: 260 seconds]
m5zs7k has joined #rust-embedded
<re_irc>
<danielzfranklin> Is there something like embedded-hal's DelayUs that would return a monotonic us count? I'm aware of rtic's monotonic but it's not sharable.
<re_irc>
(I'm writing a non-blocking driver with a manual state machine instead of something like async, and need for example to return my "not ready" indicator until a second has passed)
<re_irc>
<adamgreig> Can you just ask to be given the current time in us? Even just as a few or u64? You could take like a fugit:: MicrosDurationU64 but maybe just a plain integer would work
<re_irc>
<SEGFAULT (Lauren)> How's bluetooth on embedded these days? I got a toy embedded bt project thst might be suitible to do in rust
<re_irc>
<korken89> danielzfranklin: You can share RTIC's monotonic, no problem. Just take a "fn() -> TheMonotonicsInstant", the "monotonics::now()" method in RTIC is specifically designed to allow for sharing.
<re_irc>
<danielzfranklin> korken89: Thanks! I misremembered why I didn't use it for something else (which was because it briefly disables interrupts, so I can't spin on it in idle)
<re_irc>
<korken89> Sure you can, it only locks for a very short instant
<re_irc>
<korken89> Usually a few clock cycles
<re_irc>
<korken89> So spin wait is fine
<re_irc>
<danielzfranklin> I was doing something like
<re_irc>
while now() < timeout && not_received_data { continue }
<re_irc>
<korken89> So your worst added interrupt latency is those few clock cycles
<re_irc>
<dirbaio> you can spin on something that disables irqs no problem: if an irq happens while disabled it's not lost, just delayed, it'll fire immediately when exiting the CS
<re_irc>
<danielzfranklin> +so, so I think the interrupt could never fire
<re_irc>
<korken89> danielzfranklin: LGTM!
<re_irc>
<korken89> That's fine
<re_irc>
<dirbaio> your spin can be 10000 cycles irqs disabled, 1 cycle irq enabled, and you won't lose any irqs
<re_irc>
<danielzfranklin> Huh, must have been a different issue then. Thanks!
<re_irc>
<korken89> Keep on fighting! :D
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
<re_irc>
<unrelentingtech> thejpster: rubble works great for beacons but the connection stuff is.. well lots of devices just don't see the rubble device when it sends connectable advertisements, probably due to not doing some timing things: https://github.com/jonas-schievink/rubble/issues/56 (hmm could async make the required timing code easier?)
<re_irc>
<dirbaio> also rubble is not low-power (requires high-freq 1mhz timer)
<re_irc>
<ryan-summers> I'm a bit hesitant to say that async would help with hard real-time requirements, but I guess it could help if you didn't have any other tasks on the executor
<re_irc>
<dirbaio> "async can't do realtime" is a myth
<re_irc>
<ryan-summers> Doesn't the first line of that file essentially restate what I said though? You can't have other tasks on the real time executor that can block the real-time tasks
<re_irc>
<dirbaio> you spawn realtime tasks in their own dedicated executor with higher prio
<re_irc>
<dirbaio> so they preempt lower-prio stuff
<re_irc>
<dirbaio> you can have as many tasks in the low-prio executor as you want, and they can even do dumb stuff like blocking spinning for long periods
<re_irc>
<dirbaio> and the high-prio tasks will still fire, with consistent timing
<re_irc>
<dirbaio> +(the executor is constant-time)
<re_irc>
<dirbaio> it even has less latency and less jitter than freertos 😎
<re_irc>
<unrelentingtech> dirbaio: isn't that like, the radio's requirement? or do you mean that rubble does not currently support turning that off when not actively using the radio?
<re_irc>
<dirbaio> yeah, the second
<re_irc>
<dirbaio> the softdevice only needs the 32khz low-power RTC on at all times, and starts HFCLK only during radio events
<re_irc>
<dirbaio> it uses the 32khz RTC to keep track of time between radio events, widening the window as necessary to account for inaccuracies
<re_irc>
<unrelentingtech> not supporting dynamic switching to low-power modes seems to be a big general gap in embedded rust, there's a lot of the "freeze the clocks object and keep it forever and pass it to things to prove you're in high perf mode" thing in all the HALs
<re_irc>
<dirbaio> yeah stm32 lowpower is hairier
<re_irc>
<dirbaio> nrf lowpower rust is in quite a good shape with embassy, I'm shipping devices with years of battery life with it
<re_irc>
<dirbaio> nrf is easier though, because it'll start/stop hfclk automatically in hardware as required
<re_irc>
<unrelentingtech> damn, I should switch to softdevice, my little rubble nrf51 sensor beacon drains a 3.7v lipo in like a month and a half
<re_irc>
<dirbaio> but a stm32 hal could do the equivalent in software
<re_irc>
<dirbaio> I think it's just that stm32 people do less lowpower stuff in general
Guest2 has quit [Quit: Client closed]
<re_irc>
<unrelentingtech> dirbaio: true, most people don't even buy the L series that have tons of low-power support. I'm going to work on stm32l1 keyboard firmware soon, I'll try to make it as low power as possible, just for fun
<re_irc>
<dirbaio> :D
<re_irc>
<ryan-summers> Yeah, if I were doing a low power radio design, I'd just get an nRF52 series.
<re_irc>
<unrelentingtech> funnily enough I mostly picked the L1 because it somehow was a "basic part" on jlcpcb (meaning no $3 pick&place loading fee)
<re_irc>
<dirbaio> I wonder how stm32 hal lowpower support would look
<re_irc>
<dirbaio> probably "clock refcounting" would work
<re_irc>
<dirbaio> when creating a peripheral that requires HF clock, increase refcount
<re_irc>
when dropping it, decrease refcount
<re_irc>
if refcount goes nonzero -> zero, stop it
<re_irc>
<dirbaio> if refcount goes zero -> nonzero, start HSE
<re_irc>
<dirbaio> 🤔
<re_irc>
<unrelentingtech> but peripherals could "sleep" without being dropped?
<re_irc>
<unrelentingtech> and that's what makes it tricky
<re_irc>
<dirbaio> one way is to add enable/disable methods to peripheral drivers
<re_irc>
<dirbaio> but IMO that's not a good design because you can still try to use the peripheral while disabled, which would break/panic
<re_irc>
<dirbaio> instead, embassy does create=enable, drop=disable
<re_irc>
<dirbaio> so it enforces you can't use a peripheral while disabled, at compile time
<re_irc>
<dirbaio> and to allow creating the peripheral "multiple times" you can create it with borrowed singletons instead of owned singletons
<re_irc>
<unrelentingtech> one fun thing I can think of is like a "in_low_power_mode(|| loop { do_things_here(); if time_to_go_fast { break; } })" that would basically temporarily replace the entire running program with a low-power subprogram.. (but that might require saving and restoring the state of ALL peripherals :/)
<re_irc>
<dirbaio> hmm yeah, and other concurrent tasks might not be happy to be "low-powerified" like that without their consent heh
<re_irc>
<unrelentingtech> no, like, concurrent tasks would all be suspended, the interrupt table would also be saved on enter / restored on exit etc.
<re_irc>
<dirbaio> the exact same idea but in reverse probably works better, allow tasks to request high-power mode :D
<re_irc>
<dirbaio> either by enabling a peripheral that requires it, or a closure like that to make the cpu itself go fast...? 🤔
<re_irc>
<dirbaio> and the fast clock is enabled as long as at least one task/peripheral is requiring it
<re_irc>
<unrelentingtech> true, this might actually work super well in a full RTOS like Hubris
<re_irc>
<unrelentingtech> maybe with async executors too.. if there's some way to get the executor to know who's holding the high-power peripherals
<re_irc>
<dirbaio> peripheral drivers would call into rcc to increase/decrease refcount
<re_irc>
<dirbaio> no need for the executor to get involved probably
<re_irc>
<unrelentingtech> just a refcount wouldn't allow automatically going into low-power mode when switching to a low-power task (and vice versa)
<re_irc>
<dirbaio> oh, for executing cpu code itself, hmm
<re_irc>
<dirbaio> nrf enables hfclk every time the cpu wakes up, there's no way at all to run the cpu from lfclk
<re_irc>
<dirbaio> so lowpower is just "spend max time sleeping, with no peripheral requiring hfclk"
<re_irc>
<dirbaio> and it works well enough
<re_irc>
<dirbaio> so perhaps the same for stm32 would be good enough? as a starting point at least
<re_irc>
<unrelentingtech> the situation I'm imagining is: stm32, we have a usb task and a keyboard matrix scan task, the latter is low-power. when there are no usb interrupts the scan one is sometimes awaiting a timer, sometimes fiddling with gpio — we should stay in low power mode (LP Run & LP Sleep) until a usb interrupt comes to wake the usb task (or the scan task messages the usb task to initiate comms)
<re_irc>
<unrelentingtech> a tricky thing here is that IIRC the usb peripheral also requires some register bits of its own to go to sleep :/
<re_irc>
<dirbaio> is it really worth doing the matrix scan in LP Run mode?
<re_irc>
<dirbaio> vs starting HF osc then doing it in high-power, so faster?
<re_irc>
<dirbaio> like, if your matrix has pullups/pulldowns doing it faster will make it leak current for less time :D
slugbyte has joined #rust-embedded
<re_irc>
<dirbaio> I guess it's hard to know
<re_irc>
<dirbaio> +without measuring it..?
<re_irc>
<unrelentingtech> maybe not worth, I just like the concept of lp run lol
<re_irc>
<dirbaio> it just feels weird to me, coming from nrf where it doesn't exist at all heh
<re_irc>
<dirbaio> but if it exists it must have its usecases yeah..
<re_irc>
<unrelentingtech> but grepping 'stm32f303' in embassy would only show 'x' in this particular line
<re_irc>
<dirbaio> ah these features don't exist... it's a bug then
<re_irc>
<unrelentingtech> I'm just trying to add usb for all the series, so maybe we need to make them (as cfgs rather than features)
<re_irc>
<unrelentingtech> f3 series looks like a huge mess :/
<re_irc>
<dirbaio> yeah..
<re_irc>
<dirbaio> if the RCC regs are different then that should be two rcc_f3 versions in stm32-metapac
<re_irc>
<dirbaio> so you can then do "#[cfg(rcc_f3v1)]" or whatever
<re_irc>
<dirbaio> and it's automatically enabled for the right chips
<re_irc>
<unrelentingtech> not regs, in this case it's frequency calculations, with the comment "For some chips PREDIV is always two, and cannot be changed"
<re_irc>
<dirbaio> oof, then cfgs is the best we can do I guess :D
<re_irc>
<dirbaio> damn stm32
<re_irc>
<dirbaio> there's chips with an actual "x" in their names btw, wtf
<re_irc>
<dirbaio> "STM32H757xI" is not the same as "STM32H757XI"
<re_irc>
<dirbaio> yay ST
<re_irc>
<unrelentingtech> lol
<re_irc>
<TimSmall> I noticed a talk on this ("no_std") NTFS filesystem crate as part of this weekend's (online, free) FOSDEM conference: https://fosdem.org/2022/schedule/event/misc_ntfs_rust/ in case anyone's interested. I'd not previously come across it, but when I get a moment, I'll give it a spin on a µc and SD card...
<re_irc>
<TimSmall> ... BTW FOSDEM's online presence is via Matrix, so the "Chat" link in that URL will take you to the Matrix room, where the talk will be streamed (at the scheduled time), and for live Q+A.
<re_irc>
<TimSmall> (readonly at the moment BTW, but still an interesting looking project!).
<re_irc>
<TimSmall> I noticed a talk on this ("no_std") NTFS filesystem crate as part of this weekend's (online, free) FOSDEM conference: https://fosdem.org/2022/schedule/event/misc_ntfs_rust/ in case anyone's interested. I'd not previously come across it, but when I get a moment, I'll give it a spin on a µc and SD card (assuming it'll fit in RAM)...
<re_irc>
<TimSmall> Otherwise not much Rust stuff at this year's FOSDEM, there are "dev rooms" for Go, Raku, JS, Dart, Kotlin, Python, Ada, OpenJDK, LLVM, Nim, but no Rust dev room this year :-( The "Computer Aided Modeling and Design devroom", includes a couple of KiCAD talks, and some other OS electronics and PCB design stuff (but no main project update from the KiCAD project lead this year). ...
<re_irc>
<TimSmall> Otherwise not much Rust stuff at this year's FOSDEM, there are "dev rooms" for Go, Raku, JS, Dart, Kotlin, Python, Ada, OpenJDK, LLVM, Nim, but no Rust dev room this year :-( The "Computer Aided Modeling and Design devroom", includes a couple of KiCAD talks, and some other OS electronics and PCB design stuff. The main KiCAD "status" talk is usually given by project lead Wayne Stambaugh, but he's not listed this year...