<bartmassey[m]>
Interesting. Maybe I'm wrong, but it seems to me like it shouldn't be stabilized in this form: it looks more confusing than helpful? What's a good use case for this kind of TAIT?
pcs38 has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room , meeting time again! agenda for this week is https://github.com/rust-embedded/wg/discussions/823, please add anything you want to announce or discuss and we'll start in a few mins
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
datdenkikniet[m] has joined #rust-embedded
<datdenkikniet[m]>
Are PR's to repo's within the rust-embedded team relevant for this meeting?
<datdenkikniet[m]>
* this meeting? Or should I bring that up some other time :P
<datdenkikniet[m]>
* Is asking for attention to PR's to repo's within the rust-embedded team relevant for this meeting? Or should I bring that up some other time :P
<adamgreig[m]>
<bartmassey[m]> "Ah. Sad. I teach during that..." <- stupid daylight savings! though i am excited to have longer evenings soon. see you in a few weeks :p
<adamgreig[m]>
ok, let's begin! just a couple of announcements, svdtools 0.4.5 and svd2rust 0.36.0 released, thanks for the continued hard work on those burrbull and emilgardis!
<adamgreig[m]>
so if you wanted to use loom elsewhere you could provide a c-s impl externally, like you do any other c-s impl, but with this PR, you can enable the loom feature instead?
<datdenkikniet[m]>
Yes, and no: you could provide a c-s implementation externally, or activate --cfg loom in your RUSTFLAGS
<datdenkikniet[m]>
* Yes, and no: you could provide a c-s implementation externally, or activate --cfg loom in your RUSTFLAGS and --features std
<datdenkikniet[m]>
I think the main reason is that, in practice, you never want loom active outside of tests
<datdenkikniet[m]>
so a feature is "too brittle", perhaps (since it'll only show up at runtime)? Now that I think about it I'm not 100% certain why they recommend a cfg over a feature, but it's what they recommend
<datdenkikniet[m]>
s/recommend/do/
<adamgreig[m]>
is there any particular advantage to having it included in the c-s crate, or just convenience instead of having to provide your own impl? i.e. could you have a critical-section-loom crate that provides the impl and users just depend on that?
<datdenkikniet[m]>
The trickiest part is that you have to somehow deactivate c-s-std when activating loom
<datdenkikniet[m]>
* The annoying part is that you have to somehow deactivate c-s-std when activating loom (which you can do with an additional target.'cfg(not(loom))'.dependencies block), but besides that an external crate should work just as well
<datdenkikniet[m]>
* The annoying part is that you have to somehow deactivate c-s-std when activating c-s-loom, in that case (which you can do with an additional target.'cfg(not(loom))'.dependencies block), but besides that an external crate should work just as well
<datdenkikniet[m]>
given that there loom doesn't seem too widely used yet, that may be a worthwhile pain until it becomes more relevant to integrate into c-s
<adamgreig[m]>
you can't just leave c-s std feature disable d?
<datdenkikniet[m]>
s/there /`/, s//`/
<datdenkikniet[m]>
not if you want to write non-loom tests as well
<datdenkikniet[m]>
(loom primitives panic outside of the loom runtime)
<datdenkikniet[m]>
s/(/right, relevant: /, s/)/, so they can't be used to write "normal" tests that also call c-s/
<adamgreig[m]>
datdenkikniet[m]: ah yea I see
<datdenkikniet[m]>
but, I would be adaptable to just setting up a c-s-loom as well, and see how well that goes. If it gets more traction, we could revisit the PR :)
<datdenkikniet[m]>
* but, I would be adaptable to just setting up a c-s-loom as well (I can do it, outside of rust-embedded for now), and see how well that goes. If it gets more traction, we could revisit the PR :)
<adamgreig[m]>
it sounds like that might be basically as good, but see what the libs team think about the pr first i think
<diondokter[m]>
Oh yeah, I've heard of Loom. Pretty cool to see work with it in the embedded space
<diondokter[m]>
Also, hello from embedded world btw. Many people curious about Rust there!
<adamgreig[m]>
i think a bunch of our regulars are probably busy there too :p enjoy!
<adamgreig[m]>
anything else anyone would like to discuss this week?
zeenix[m] has joined #rust-embedded
<zeenix[m]>
I just added a comment (sorry late to the party)
<zeenix[m]>
heapless 0.9 release request. It was discussed recently.
<adamgreig[m]>
what are you looking for in 0.9 specifically? it looks like a 0.8 backport with some fixes could be done without 502, but perhaps best to get 502 merged and just release it in 0.9
<zeenix[m]>
newam[m]: I'll try and help but I'll have to look up again what covariance and invariance mean. 😂
<zeenix[m]>
Not necessarily 0.9
<zeenix[m]>
Just a release that includes fixes since 0.8.0
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
if its just fixes, wouldn't that be a patch release, e.g. 0.8.1?
<newam[m]>
We've had breaking changes too.
<newam[m]>
Could do a point release and backport just non-breaking, but I'm pretty sure the nitrokey guys want some of the breaking changes.
<adamgreig[m]>
sounds like it might be more worthwhile getting to 0.9 then
<adamgreig[m]>
ok, if that's all then let's finish here for this week, thanks everyone!
<datdenkikniet[m]>
Thank you for hosting, adam :) 👋
<datdenkikniet[m]>
s/adam/Adam/
embedded-enthusi has quit [Remote host closed the connection]
<thejpster[m]>
I met Robin today. He wants to do Rust on satellites at the University of Stuttgart. Very cool stuff.
igiona[m] has quit [Quit: Idle timeout reached: 172800s]
kentborg[m] has joined #rust-embedded
<kentborg[m]>
Has there been any talk of a tickless embassy? That is, don't wake up every tick, only wake up if there is an interrput indicating something has happened, or something is scheduled to happen. It seems a way to get higher timing resolution and more responsive code, without burning up the battery.
<kentborg[m]>
I know the Linux kernel was made tickless for these reasons. Though, it took a while.
chrysn[m] has joined #rust-embedded
<chrysn[m]>
kentborg[m]: Does embassy use ticks in the first place? I didn't check its timers in depth, but it'd be highly surprising to me.
<datdenkikniet[m]>
https://crates.io/crates/embassy-executor implies that it doesn't "No busy-loop polling: CPU sleeps when there's no work to do, using interrupts or WFE/SEV."
<chrysn[m]>
(Yes, embassy-time talks about ticks, but that's a different thing: ticks there refers to the unit of time the underlying hardware clock has; tickless refers to not waking up every time a single unit of any particular time passes)
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
if you have a time driver I think you'd need ticks if the resolution is too small. But I suspect this isn't time driver related
<datdenkikniet[m]>
s/implies/says/
<kentborg[m]>
The documentation says "tick-hz-x: Configures the tick rate of embassy-time. Higher tick rate means higher precision, and higher CPU wakes." suggesting the ticks, um, tick. But it also says ticks can be 1 MHz, which would be a nasty rate to be ticking-and-doing-stuff at.
ouilemur has quit [Ping timeout: 244 seconds]
<chrysn[m]>
Those are ticks as in "the units of time in which things can be expressed". Having them small means that sometimes you'd have to wake up when they wrap, or (depending on what is backing them) that a higher-power clocks is kept running (eg. a 48MHz oscillator rather than a 32kiHz oscillator), but those are not the "kernel reschedules every so-and-so-much time" ticks.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
kentborg: yep embassy is already tickless
<dirbaio[m]>
(well technically it depends on the time driver implementation, but all impls out there are tickless)
<dirbaio[m]>
a tick rate of 1mhz means the hw timer ticks at 1mhz, not that the cpu is getting interrupts at 1mhz.
<i509vcb[m]>
In the stm32 and mspm0 (I "borrowed" the stm32 implementation) implementations, it dictates the rate at which the timer ticks. The time driver itself does need to wake if the timers overflow to increment an internal counter for these two implementations.
<dirbaio[m]>
cpu gets interrupts when a timer expires, and once per period to handle overflows
<dirbaio[m]>
* handle overflows (or twice in some impls)
<dirbaio[m]>
for example at 1mhz you get an overflow every 4294s if the timer is 32mhz, every 65ms if it's 16bit
<kentborg[m]>
Regular ticks also make drift-free timing easier, though I timers are pretty capable these days and can still do that on a scheduled basis.
<kentborg[m]>
* Regular ticks also make drift-free timing easier, though I think timers are pretty capable these days and can still be drift-free on a scheduled basis.
<dirbaio[m]>
so yeah for 16bit you have to be a bit careful not to set the tick rate too high
<dirbaio[m]>
kentborg[m]: it sets compares against a single free-running timer that's never stopped, so it doesn't drift
<kentborg[m]>
Cool. So the only real cost to a fast "tick" is rollover. Excellent.