<re_irc>
<yruama_lairba> korken89: i see some sort of "critical section" in Ssq. it wasn't possible to use atomic instead ?
fabic has joined #rust-embedded
<re_irc>
<korken89> It is
<re_irc>
<korken89> You could have a atomic bool and do checks against that
<re_irc>
<korken89> yruama_lairba:
<re_irc>
<korken89> +^
<re_irc>
<korken89> I could update it to work lite that instead
<re_irc>
<yruama_lairba> i should really how to use async in general and how it works for embed. for example i wondered if there was notion of priority, or at least if it's easy to implement such property
<re_irc>
<yruama_lairba> typical use case is when an IO need to be handled with a very short delay.
<re_irc>
<korken89> Not it uses "AtomicBool" instead of critical sections
<re_irc>
<korken89> * Now
<re_irc>
<yruama_lairba> you did it quick :)
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
<re_irc>
<korken89> :D
<re_irc>
<korken89> I was just lazy the first time I wrote the queue
<re_irc>
<korken89> Doing with atomic it the "right way" and your poke nerd-sniped me
<re_irc>
<korken89> yruama_lairba: In RTIC's async experiment async tasks have priority just like normal tasks do
<re_irc>
<korken89> Can't answer for async/await in general though :)
fabic has joined #rust-embedded
<re_irc>
<James Munns> yruama_lairba: It generally depends on what you mean by "priority".
<re_irc>
<James Munns> async/await is more generally known as "cooperative multitasking", as opposed to threads/RTIC, which would more generally be known as "preemptive multitasking"
<re_irc>
<James Munns> (I was getting there, but my doorbell rang :D)
<re_irc>
<James Munns> So when you mean "higher priority", do you mean, "the highest task is scheduled next", or "a higher priority task interrupts a lower priority one"
<re_irc>
<James Munns> (dirbaio's link shows how to do the second one!)
<re_irc>
<James Munns> But yeah, the answer is generally "have one executor per-priority level" :D
fabic has quit [Ping timeout: 240 seconds]
<re_irc>
<James Munns> Misc note, here's the official "postcard is going to v1.0 in the next month" announcement :D
<re_irc>
<James Munns> If there's something you want but don't see listed there, make sure to ping me some time in the next month, or open an issue! This will be a breaking change (both semver and wire format), but no additional breaking changes are planned beyond that (until 2.0, I guess!)
fabic has joined #rust-embedded
jr-oss has quit [Ping timeout: 240 seconds]
jr-oss has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
dc740 has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Client Quit]
<re_irc>
<adamgreig> room meeting time again 👋 agenda is https://hackmd.io/w_5R0qXQR0-OrAC74_CO-A, please add anything you'd like to discuss or announce and we'll start in 5 minutes :)
<re_irc>
<Phil Markgraf> I am interested to see how flavors are collapsed. Making COBS+CRC+Postman into a single step is a great idea.
<re_irc>
<adamgreig> ok, let's start! hi everyone
<re_irc>
<adamgreig> just one announcement from me, the next rust cross-team collaboration fun times meeting is this coming monday 16th, with James Munns and dirbaio talking about embedded, details here: https://rust-lang.github.io/ctcft/meetings/2022-05-16.html
<re_irc>
<adamgreig> (and skade too!)
<re_irc>
<adamgreig> anyone is welcome to come and listen and chat afterwards, so tune in if you're interested, it's at one of the more social european timezone slots this time
<re_irc>
<James Munns> Phil Markgraf: Happy to talk after the meeting!
<re_irc>
<adamgreig> does anyone else have any announcements?
<re_irc>
<dirbaio> I do! :)
<re_irc>
Just released "embedded-io" to crates.io. IO traits for no_std, embedded-hal style. Comes in both blocking and async flavors.
<re_irc>
<adamgreig> cool, next up is cortex-m, there's been a couple of minor PRs merged for bug/typo fixes but I'm afraid still no update on the bigger PRs that need some review/attention, and probably want resolving prior to thinking about a pre-release
<re_irc>
<adamgreig> I think discussion for those can probably keep going on the PR threads, including coordinating with critical-section 0.3
<re_irc>
<dirbaio> about critical-section:
<re_irc>
<dirbaio> 1. transfer to REWG yes or no? I'm happy to do it, but then the WG maintains it. I'm happy not to and keep maintaining it myself too
<re_irc>
<adamgreig> my preference would be yes if cortex-m starts using it, and maybe we integrate it into bare-metal or entirely deprecate bare-metal and move the CS token struct into c-s?
<re_irc>
<reitermarkus> I don't think "Mutex" should be in the "critical_section" crate.
<re_irc>
<adamgreig> though maybe at that point it's simpler to move the c-s methods into b-m
<re_irc>
<dirbaio> and 2. about "bare-metal": merge it into c-s yes or no? cortex-m hasn't adopted "bare-metal 1.0" yet, so either merging or not will be breaking. Perhaps we can do a "bare-metal" semver-hack release that reexports stuff from c-s
<re_irc>
<dirbaio> IMO the "bare-metal" name is not very descriptive of what it contains...
<re_irc>
<adamgreig> if CS moves from b-m to c-s then b-m only has Mutex left, so yea, even less descriptive
<re_irc>
<adamgreig> the "utils" of rust embedded, heh
<re_irc>
<adamgreig> but if you don't put Mutex in c-s it should still live somewhere
<re_irc>
<dirbaio> and it's better if the critical section crate has nothing else in it, if that "something else" requires a major bump it can be disruptive
<re_irc>
<therealprof> Yeah, bare-metal is a misnomer from previous times.
<re_irc>
<adamgreig> so maybe b-m re-exports c-s's CS and has its own Mutex, and c-s 1.0 defines CS? depends if we want to hold on to b-m basically
<re_irc>
<dirbaio> or move everything
<re_irc>
<adamgreig> I mean, it's not like we'll delete it, and it will keep having a Mutex and a CriticalSection type, so it would probably be nice if it works out in a fairly backwards-compatible way
<re_irc>
<dirbaio> the mutex is a "critical section mutex" after all
<re_irc>
<adamgreig> move everything as in move everything from b-m into c-s?
<re_irc>
<dirbaio> yes
<re_irc>
<dirbaio> at the very least, "b-m" needs an update because there's "current core" language on the docs that's now wrong
<re_irc>
<adamgreig> if we did, I'd be inclined to do a b-m 1.1 that re-exports c-s 1.0's CS and Mutex
<re_irc>
<dirbaio> and "Mutex" says "only safe on single-core systems" which is no longer true
<re_irc>
<dirbaio> adamgreig: SGTM!
<re_irc>
<adamgreig> just for continuity
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> dirbaio: but this is still a reason against Mutex in c-s
<re_irc>
<dirbaio> hmhmhm
<re_irc>
<adamgreig> I mean, the Mutex struct hasn't changed in forever, 2M downloads on crates.io can't be wrong right?
<re_irc>
<dirbaio> yeah, what possible changes we'd want to Mutex?
<re_irc>
<reitermarkus> I think as long as "CriticalSection" stays the same we also don't have to change "Mutex".
<re_irc>
<adamgreig> (final discussion on 44 there suggests also adding try_borrow and try_borrow_mut in the future)
<re_irc>
<adamgreig> so there is maybe scope for Mutex to get some new functions
<re_irc>
<GrantM11235> Those would be non-breaking changes, right?
<cr1901>
dirbaio: FWIW, I already adopted bm 1.0 for msp430, but since there's so many less users than c-m, I've no problem changing to critical_section/updating to 1.1
<re_irc>
<adamgreig> yea, so long as we don't eventually find something wrong with them or whatever
<re_irc>
<dirbaio> I have to run
aspe has joined #rust-embedded
<re_irc>
<dirbaio> * run, sorry :'(
<re_irc>
<dirbaio> please let me know the next steps for the transfer
<re_irc>
<adamgreig> ok, thanks for the thoughts! I think we have most of it worked out, just decide what to do with Mutex
<re_irc>
<dirbaio> and whether you guys want me to do the 1.0 release before, or if the WG will do it
<re_irc>
<adamgreig> don't mind, let's coordinate when you're around
<re_irc>
<dirbaio> 👍️
<re_irc>
<adamgreig> might make sense for you to do a 0.3 with what we think will be 1.0 and we can try it out a bit then have wg do 1.0 once it seems stable or something
<re_irc>
<reitermarkus> I guess it makes sense to do the "critical_section" 1.0 and "bare-metal" 1.1 releases synchronized at the same time.
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> with b-m 1.1 depending on c-s 1.0
<re_irc>
<reitermarkus> Yes.
<cr1901>
Why is there a c-s crate now anyways?
<re_irc>
<adamgreig> the bare-metal CriticalSection doesn't have any way share actually getting the token, and so it was provided by cortex-m (like interrupt::free), but that's only suitable for privileged execution on a single core
<re_irc>
<adamgreig> and no way to customise it for your platform
<re_irc>
<adamgreig> the c-s crate provides some free functions where the user/HAL/platform can provide implementations which enter/leave a suitable criticalsection
<re_irc>
<adamgreig> on multi-core for example they can lock both cores, or on nrf with softdevice they can leave the softdevice interrupts active to stop that breaking
<re_irc>
<adamgreig> cortex-m#433 keeps interrupt::free, but stops it giving the closure a CriticalSection token, since it's not actually true that you're always inside a critical section just because interrupts are off
<re_irc>
<adamgreig> (and libraries/drivers/applications using this to get a criticalsection (probably to give to a mutex) would then break people who did have multiple cores, or nrf, or were in an rtos or something)
<cr1901>
I'll have to look into what I need to do on the msp430 side of things
<cr1901>
updating interrupt::free to not give a critical_section token would break a lot of things as is right now
<re_irc>
<reitermarkus> Basically replace "interrupt::free" with "critical_section::with".
<cr1901>
>since it's not actually true that you're always inside a critical section just because interrupts are off
<cr1901>
Also, why isn't this true?
<re_irc>
<adamgreig> and write an implementation of the critical-section methods for msp430 crate, gated by an off-by-default feature
<re_irc>
<thejpster> cr1901: second core
<cr1901>
ignoring multicore case, or "whatever nrf does"
<re_irc>
<thejpster> Like the RP2040.
<cr1901>
what about the rtos case?
<re_irc>
<adamgreig> if you're unprivileged code on cortex-m, you can call "interrupt::disable()" and it's a NOP, too, so "interrupt::free" just runs your closure without stopping any interrupts
<re_irc>
<thejpster> Oh yeah. oxide-computer got upset about that.
<re_irc>
<adamgreig> in an RTOS you would be in a c-s but you might be mucking with the rtos, which has its own ways to provide a critical section and might want to lock its data structures around the c-s or something
<re_irc>
<adamgreig> * critical section
<cr1901>
ahhh hmmm
<re_irc>
<adamgreig> the idea with the critical-section crate is your RTOS would provide the implementation for enter/exit the CS, but drivers using the c-s crate will all continue to work properly
<re_irc>
<adamgreig> so the cortex-m crate can provide a very simple implementation for single-core privileged-only applications, and other platforms or HALs can provide more specialist implementations as required
<re_irc>
<thejpster> or on the rp2040 you have an implementation which uses the hardware spinlock peripheral
<re_irc>
<thejpster> I think the cortex-m implementation should be opt-in
<re_irc>
<adamgreig> yea, it's an off-by-default feature
<re_irc>
<adamgreig> some HALs might enable it by default for user convenience, if they know on their platform it will generally do the right thing, but that's up to them
<re_irc>
<adamgreig> but the rp2040 hal would not, it would instead provide its own feature for its implementation, probably on by default but possible to turn off if you wanted to use an RTOS's or something
<cr1901>
I didn't know HALs used criticalsections/mutexes directly, tbh
<re_irc>
<thejpster> The fact it doesn't work in unpriv mode is bad though.
<re_irc>
<adamgreig> if you're writing unpriv code you can not provide any implementation, and then code that needs a CS will fail to compile
aspe has quit [Quit: aspe]
<cr1901>
>so "interrupt::free" just runs your closure without stopping any interrupts
<cr1901>
I understand what you're getting at here
<re_irc>
<thejpster> But if you're using a HAL that provides the cortex-m implementation, and writing unpriv code.
<cr1901>
(disabling interrupts is privileged)
<cr1901>
but interrupt::disable() being a no-op/a lie sometimes seems wrong :P
<re_irc>
<newam> or runs it, but interrupts are still enabled on a second core
<re_irc>
<thejpster> You think it'd recoverably fault or something instead
<re_irc>
<adamgreig> thejpster: indeed, I suppose the HAL documentation has to make this clear, but at least it's possible to disable the feature; it seems unpriv code is a less common and at least this way it's possible for those people to control that they aren't accidentally using code that assumes it can disable interrupts
<re_irc>
<thejpster> Can the c-m implementation easily check for unpriv mode?
<cr1901>
newam: What was your comment in reply to?
<re_irc>
<thejpster> I assume there's a bit somewhere
<re_irc>
<newam> Are there any other danger zones in cortex-m with respect to priv/unpriv? not as in "running this in unpriv will cause a fault", more like "running this unpriv silently does nothing"
<re_irc>
<adamgreig> I think it would not be popular to check every time you enter a c-s in terms of overhead
<re_irc>
<adamgreig> I'm not sure what else, there's discussion in https://github.com/rust-embedded/cortex-m/issues/233 about the peripheral singletons as well, but that's sort of related to c-s and also not to c-m anyway
<re_irc>
<adamgreig> certainly interrupt::free is the main danger zone I know of
<re_irc>
<adamgreig> couple of quite embedded-hal points before we wrap up; https://github.com/rust-embedded/embedded-hal/pull/382 was merged to re-add default methods to async spi, which may be of interest to people following the embedded-hal-async development
<re_irc>
<adamgreig> there's some ongoing discussion about extending the CAN traits here: https://github.com/rust-embedded/embedded-hal/issues/381, though I suspect the answer is the same of "configuration doesn't go in embedded-hal"
<re_irc>
<eldruin> That's what I would say
<re_irc>
<eldruin> if there is something else general enough, fine but config is a can of worms as we all know
<re_irc>
<adamgreig> the only bit that's a little tricky to my eyes is that StandardId(u16) and ExtendedId(u32) will "Ord" in the normal integer sense, but "Id" (an enum that's one of those two) gets a custom "Ord" that obeys CAN rules
<re_irc>
<timokrgr> I came up with ordering according to arbitration rules because that way a btree map can be used to implement a correct priority queue for can messages
<re_irc>
<adamgreig> maybe that's OK? you use the Id enum if you want the CAN sorting, but the newtypes order as normal since they're basically just integers at that point?
<re_irc>
<timokrgr> yeah if you only use either standard ids or extended ids the normal sorting also fits the CAN priority model
<re_irc>
<eldruin> yeah maybe that's fine. a bit tricky though.
<re_irc>
<eldruin> timokrgr: ah, ok then it is all correct IIUC
<re_irc>
<eldruin> if you really just smash standard ids and extended ids because they are compatible instead of using the enum then you were really asking for trouble
<re_irc>
<eldruin> +:P
<re_irc>
<eldruin> +together as a map key
<re_irc>
<adamgreig> cool, yea, seems pretty reasonable then
<re_irc>
<adamgreig> I hadn't clocked that the sorting ends up consistent this wa
<re_irc>
<adamgreig> * way
<re_irc>
<adamgreig> great, that's all we have time for today, thanks everyone!
<re_irc>
<James Munns> By the way, has anyone out there other than me ever used unpriv mode in Rust?
<re_irc>
<James Munns> Im sure someone has, I just havent seen it in the wild outside of mnemos
<re_irc>
<adamgreig> hubris does, right?
<re_irc>
<adamgreig> and tock?
<re_irc>
<James Munns> (But even then: unpriv mode is a totally different binary for me, so sharing data between interrupts isnt relevant)
<re_irc>
<James Munns> Ah, fair! I guess thats why they complained re: critical sections
<re_irc>
<James Munns> Does tock? Or does it just use the mpu? Its been forever since I looked
<re_irc>
<James Munns> I guess it is an “OS” thing
<re_irc>
<adamgreig> there's not much call for it when you don't have a distinction between a privileged kernel and unpriv userspace I guess
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
dc740 has quit [Remote host closed the connection]