IlPalazzo-ojiisa has quit [Remote host closed the connection]
dav1d has quit [Ping timeout: 240 seconds]
dav1d has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
kenny has quit [Quit: WeeChat 4.0.5]
kenny has joined #rust-embedded
kenny has quit [Quit: WeeChat 4.0.5]
kenny has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
Guest7221 has joined #rust-embedded
TeXitoi[m] has quit [Quit: Idle timeout reached: 172800s]
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has joined #rust-embedded
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
Guest7221 has joined #rust-embedded
Guest7221 has quit [Changing host]
Guest7221 has joined #rust-embedded
yruama_lairba[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901>
adamgreig[m]: Just like w/ the amaranth meeting yesterday; I'm physically present, but dealing w/ meatspace stuff. So won't be around much today
xfbs[m] has joined #rust-embedded
<xfbs[m]>
What’s a meatspace?
<xfbs[m]>
I love meat. Didn’t know we had a space
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
The opposite of cyberspace! 😀
<jessebraham[m]>
Matspace = the real world
<jessebraham[m]>
s/Matspace/Meatspace/
GenTooMan has quit [Ping timeout: 245 seconds]
<adamgreig[m]>
<cr1901> "adamgreig: Just like w/ the..." <- Nw, thanks for the heads up
GenTooMan has joined #rust-embedded
<adamgreig[m]>
hi @room , meeting time again! agenda is https://hackmd.io/2xWqV5BCQsGmBMdQHScPFw, please add anything you want to announce or discuss and we'll start in a few mins
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
On the agenda: I @ rust
<adamgreig[m]>
you... at rust?
<firefrommoonligh>
Oops. That was an unfortunate typo
<firefrommoonligh>
I ♥ rust
<firefrommoonligh>
I have been doing some python and JS coding lately at work; it is quite sloppy by comparison!
<firefrommoonligh>
more on topic, dirbaio newam - Thx for takign ownership of heapless! It is a great/fundamental lib. Ie it's like "Hey I want rust STD allocated collections, but without an allocator"
<firefrommoonligh>
I wouldn't mind if it were built into core itself
<thejpster[m]>
Not here today I’m afraid. I’m not very well.
<adamgreig[m]>
hope you feel better soon!
<adamgreig[m]>
ok, let's start then, a few announcements
<adamgreig[m]>
as you may have seen we have a libs team now 🎉
<adamgreig[m]>
currently dirbaio and newam are maintaining the libs, but if anyone is keen to help out let them know
elpiel[m] has joined #rust-embedded
<elpiel[m]>
I'm joining today but with the baby ATM so she might wake up soon 😅
<elpiel[m]>
Awesome news for the new libs team !!!
<adamgreig[m]>
consequently japaric has transferred heapless and volatile-register to the wg under the libs team, and we've internally moved embedded-alloc (which used to be cortex-m when it was alloc-cortex-m) and qemu-exit (which didn't have a team...) to libs too
<elpiel[m]>
thejpster[m]: Wish you fast recovery
<adamgreig[m]>
which means we have already fixed the outstanding concern about struct reprs in volatile-register, which fixes the issue for cortex-m too, and hopefully heapless can see some more active maintenance oto
<adamgreig[m]>
s/oto/too/
<adamgreig[m]>
in other news, embedded-io 0.6.1 is out with a minor visibility fix for an error enum, and svd2rust 0.30.2 is out with some bug fixes
<elpiel[m]>
adamgreig[m]: I added an agenda item for helpless release. There are a few fixes that help a lot so I would love a 0.8 release
<adamgreig[m]>
that's it for announcements, quick poll again if anyone's seen any issues with the anti-spam bot, please shout if so
<dirbaio[m]>
o/
<adamgreig[m]>
on the rustc target maintainers front, I opened the PR to add us to various targets, no response yet so nothing more for us to do now
<adamgreig[m]>
the other agenda items are from last week, so we could start with the new item about heapless 0.8, elpiel did you want to say anything in particular?
<elpiel[m]>
I believe there was something in main that I needed for a project and it would be nice to release a 0.8 version with it.
<elpiel[m]>
Let me check what it was
<dirbaio[m]>
the plan is to go through open PRs, merge what's mergeable, release 0.8
<dirbaio[m]>
master already has breaking changes so it has to be 0.8 instead of 0.7.x anyway
hayley_gayley[m] has joined #rust-embedded
<hayley_gayley[m]>
<adamgreig[m]> "currently dirbaio and newam..." <- It'd be willing to help addres https://github.com/rust-embedded/volatile-register/issues/10 in-so-far as it is still an issue. (sorry for a slow respone, making dinner while reading along :) )
<dirbaio[m]>
and there's at least one PR queued with breaking changes, the migration from atomic-polyfill (deprecated) to portable-atomic
<elpiel[m]>
dirbaio[m]: Yes indeed.
<elpiel[m]>
Can't find the feature I was forced to use master revision for but I do remember it was a breaking change.
<elpiel[m]>
Thanks for working on it!🎉🎉🎉
<dirbaio[m]>
which is somewhat overdue :D
<adamgreig[m]>
hayley_gayley[m]: ah, interesting. I don't know if the best plan is to a) rework volatile-register to make something that uses raw pointers internally or b) deprecate volatile-register and suggest its users transition to raw pointers
<dirbaio[m]>
if anyone has fixes or gripes with the API they want fixed before 0.8, now's the time to PR
<adamgreig[m]>
I think right now Derefernceable is not applied to things containing an UnsafeCell, which means in current rustc there won't be any spurious reads, but it's not guaranteed by the language
<adamgreig[m]>
pretend I spelt dereferenceable correctly
<elpiel[m]>
dirbaio: remembered the breaking change. It moves for hash32 to core Hash derive on the maps iirc
<adamgreig[m]>
hayley_gayley: but if you have a particular plan in mind it'd be interesting to hear it for sure, I guess even once you move to raw pointers there's no reason you couldn't have a convenient wrapper like volatile_register... but I haven't given any thought to what it might look like
<dirbaio[m]>
I don't think you can "fix" volatile-register, the whole premise is you use it as fields in structs that mirror the layout of the registers
<dirbaio[m]>
and you need `&`for that
<hayley_gayley[m]>
<adamgreig[m]> "ah, interesting. I don't know if..." <- I think the issue can be resolved by updating documentation/definitions, if lang agrees. Right now any reference to UnsafeCell (or wrappers) are exempt from the "tell LLVM this pointer can be safely dereferenced" rule by rustc atm and has for a while. It's caused issues with atomics too.
<adamgreig[m]>
as in, try and codify the "unsafecells won't be derefrenced" behaviour we have now, thus guaranteeing that volatile_register remains sound?
<dirbaio[m]>
that's the implementation
<hayley_gayley[m]>
adamgreig[m]: yes
<dirbaio[m]>
the memory model doesn't allow it, the current implementation does
pacarito[m] has joined #rust-embedded
<pacarito[m]>
Does anyone keep track of the number of users here over time? Just curious about growth rate.
<adamgreig[m]>
the current memory model doesn't 🤪
<dirbaio[m]>
yeah
<adamgreig[m]>
pacarito: I don't think so, but you can download a JSON dump from matrix.org of every event since the room was created and work it out, I guess
<adamgreig[m]>
I have that json... at home, where I'm not, but it would be interesting to see
<dirbaio[m]>
iirc from the last conversations about this in t-opsem the vibe was that it's not worth adding exceptions in the memory model for this when you already have raw pointers that are perfectly suitable for this task
<dirbaio[m]>
* raw pointers with volatile load/store that are
<adamgreig[m]>
yea, that's the last I recall hearing about it too
<dirbaio[m]>
and there's no inherent advantage in using "& + struct + volatilecell" over "*mut T + volatile load/store"
<adamgreig[m]>
though the problem perhaps still needs solving for atomics, and people still want "volatile atomic" which you can't get atm, so I guess there will be some flux here
<dirbaio[m]>
i'd even say the "write a struct that mirrors layout of regs" is a C-ism that has no place in Rust
<dirbaio[m]>
it made kinda sense in C because C has no methods, so structs were the only way to get ergonomic regs.foo syntax
<dirbaio[m]>
in Rust you can just do methods that do raw pointer maths, you get ergonomic regs.foo() syntax without the volatilecell curse
<adamgreig[m]>
well, regardless, if rust does change the opsem so unsafecell isn't dereferenced then volatile_register would become a definitely-sound way to do mmio if you wanted, even if registers and raw pointers is neater in ways
<dirbaio[m]>
sure
<dirbaio[m]>
but I don't think that'll happen
<dirbaio[m]>
and I don't think it should happen either
<dirbaio[m]>
we don't need it
<dirbaio[m]>
i'd just deprecate volatile_register, vcell, etc
<adamgreig[m]>
we might not, but perhaps for other reasons it will make sense to guarantee this about unsafecell
<adamgreig[m]>
anyway, I guess it's not going to involve changing volatile_register either way
<adamgreig[m]>
the main other thing on the agenda is the cortex-m interrupt-number / moving pacs off c-m/c-m-rt stuff
<adamgreig[m]>
I didn't get around to double checking the compatibility concern though I'm pretty confident it's fine; if so are we happy to release c-m-i-n and get things moved over?
<adamgreig[m]>
and relatedly, if we can simultaneously change pacs to not depend on c-m-rt then this would be the time to do it
<adamgreig[m]>
I don't think there's been much development since the last discussion we had about like #[interrupt(pac::Interrupt)] fn USART0() as a concept though
<adamgreig[m]>
at least it would avoid the weird magic we have now of overlapping names and the macro magically knowing what the interrupt is, but it's still a bit less ergonomic to use...
<dirbaio[m]>
yeah
<dirbaio[m]>
IMO i'd first try to see if there's consensus wrt #[interrupt(pac::Interrupt)] and moving svd2rust etc over to it
<dirbaio[m]>
because if there is, we can make PACs stop depending on both c-m and c-m-rt which is great
<adamgreig[m]>
first before c-m-i-n?
<dirbaio[m]>
kinda "at the same time"
<adamgreig[m]>
I feel like it might still be worth doing even if we only got c-m out of the dependency loop, plus in the worst case we know we could do c-m-rt-interrupt as its own crate
<adamgreig[m]>
yes, I'd like all the things to happen at the same time
<adamgreig[m]>
or certainly all in one svd2rust release
<dirbaio[m]>
i'm not sure if removing only the c-m dep is worth it
<dirbaio[m]>
because c-m, c-m-rt get major-bumped about equally often
<dirbaio[m]>
well, dunno
BenPyeHeThey[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
the extra complexity of adding the c-m-i-n crate is not that much on the other hand
<adamgreig[m]>
I think c-m has the scope for more regular bumping, in that there's a lot more functionality it could deliver and doesn't
<dirbaio[m]>
how does changing #[interrupt] impact RTIC?
<adamgreig[m]>
it might be that they currently bump about as often because they both require such a big upheaval that we do it together
<dirbaio[m]>
true 😅
<adamgreig[m]>
hm, rtic is given the PAC in its init macro, so I think it could place it into #[interrupt] when required?
<adamgreig[m]>
does rtic actually use the c-m-rt macro?
<adamgreig[m]>
ah, you found it quicker than me, yea I had a feeling they didn't
<adamgreig[m]>
so yea, shouldn't be affected so long as the PACs keep exporting the same thing
<dirbaio[m]>
currently pacs reexport the interrupt enum as both Interrupt and interrupt
<dirbaio[m]>
hopefully it doesn't use the lowercase one
<dirbaio[m]>
would be good to removeit
<dirbaio[m]>
s/removeit/remove it/
<adamgreig[m]>
heh
<adamgreig[m]>
ok, i think that's about it for this meeting, was there anything else anyone wanted to discuss?
<dirbaio[m]>
changing it to use the uppercase Interrupt should be "theoretically breaking but not in practice", so maybe doable
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Just a heads-up about the Book item on the agenda. Henk Oordt and I are looking at revisions of the MicroBit version of the book, as we are teaching embedded classes based on it. Would like to talk to the nrf-hal and microbit crate maintainers as well as the Book maintainers at some point if that's convenient.
<bartmassey[m]>
I don't know what the etiquette is here, and definitely don't want to step on any toes.
<JamesMunns[m]>
bartmassey hey, one of the nrf-rs maintainers here. FWIW: I would personally recommend potentially moving from `nrf-hal` to `embassy_nrf`.
<dirbaio[m]>
nrf-hal is not maintained
<JamesMunns[m]>
dirbaio[m]: because this
<JamesMunns[m]>
It's not urgent, what works today will continue to work. But it's no longer actively maintained.
<adamgreig[m]>
shame the new discovery book rewrite used it 😅
<bartmassey[m]>
Is there any interest in nrf-hal being maintained again? Or is the consensus that it's best to move on? Henk and I would be willing to co-maintain nrf-hal if people thought that was a good idea, I think.
<JamesMunns[m]>
embassy_rp does support blocking mode, so the changes from nrf-hal shouldn't be super invasive, IMO? it has a blocking mode, so you don't have to adopt async
<JamesMunns[m]>
bartmassey[m]: imo that effort would be better spent contributing to embassy_nrf, instead of maintaining two parallel crates, but if you do want to maintain it, I'd be happy to add permissions or add ownership, if the other maintainers don't object
<JamesMunns[m]>
embassy_nrf is used widely in production by dirbaio, as well as a few other users I'm privately aware of.
<JamesMunns[m]>
<adamgreig[m]> "ok, i think that's about it..." <- I feel like I need to write a post about "static mut is always bad", mostly just so I can collect all the people who log on to tell me I am wrong
<JamesMunns[m]>
If anyone has opinions about static mut, lemme know, and I'll send you a draft once I write it so you can tell me I'm wrong :D
<adamgreig[m]>
you know where to find me :D
<JamesMunns[m]>
adamgreig[m]: yeah you and dirbaio (and maybe ralfj?) are the folks at the top of mind to review :D
<bartmassey[m]>
OK, I'll look into embassy_nrf and try to figure out whether to move the microbit crate and the Book to it, or to start maintaining nrf-hal. Any advice appreciated. Thanks!
<JamesMunns[m]>
bartmassey[m]: not sure if you've swung by #nrf-rs:matrix.org, that's where we used to be active
<dirbaio[m]>
I love using static mut 😬
<JamesMunns[m]>
dirbaio[m]: yeah and I think it's bad :D
<bartmassey[m]>
Thanks! had not.
<dirbaio[m]>
it is bad
<dirbaio[m]>
but the proposed replacements like UnsyncUnsafeUncheckedCell are equally worse and less ergonomic :D
<JamesMunns[m]>
(for the sake of "always provide an alternative instead of just 'its bad'", I think using UnsafeCell explicitly makes your intent, and likely your case for ensuring soundness, much better)
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
<dirbaio[m]> "iirc from the last conversations..." <- There is a RFC for adding a new type for opting out of derefereciable, so I would say there's interest, specifically since you need & for atomic operations right now.
<dirbaio[m]>
you can't put an unsafecell in a static tho, it's not sync
<dirbaio[m]>
you have to wrap it and unsafe impl Sync for it
<dirbaio[m]>
and anyway, if the WhateverCell you use exposes an "unsafe pls give me &mut" API, then it's equivalent to `static mut`
<dirbaio[m]>
same soundness concerns etc
<JamesMunns[m]>
yeah, I'm advocating for "invent your own Cell that uses unsafe + applicable synchronization to demonstrate soundness", for sure.
<JamesMunns[m]>
it's certainly *not as easy* as static mut, but IMO static mut falls into "all bets are off" very quickly.
<dirbaio[m]>
there's times you DGAF tho
<dirbaio[m]>
like, if your firmware is really single threaded, you're not using interrupts at all
<JamesMunns[m]>
you can violate soundness in a single thread
<JamesMunns[m]>
like, reentrant functions that get &mut to the same data
<dirbaio[m]>
true
<dirbaio[m]>
but so can SyncUnsafeCell
<JamesMunns[m]>
I mean, slippery slope and all that :D
lulf[m] has joined #rust-embedded
<lulf[m]>
<bartmassey[m]> "OK, I'll look into embassy_nrf..." <- Fwiw, if it can be any help/inspiration, I made a embassy-nrf based microbit BSP a while back (just grab anything there that makes sense, it is a bit unmaintained): https://github.com/drogue-iot/drogue-device/tree/main/boards/microbit
<JamesMunns[m]>
but anyway, I like "byo cell" at least nominally because POINTERS imo are harder to "soundness footgun" yourself with, but hey that's why I need to write a blog article about it :p
<bartmassey[m]>
lulf[m]: Well that's cool. I'll take a look for sure. Thanks!
<hayley_gayley[m]>
<thalesfragoso[m]> "There is a RFC for adding a..." <- jumping back in now that I'm done cooking: from what I could find the old borrow-checker special cased unsafeCell, stacked borrows special-case unsafeCell, and treeBorrows will special case UnsafeCell. I tried poking a few people during eurorust and _most_ people seemed to be comfortable with "let's just standardize that unsafeCell opts out" vs. "VolatileCell".
<JamesMunns[m]>
like, I find most of the soundness stuff I've found is "in the between" of the "oh god everything is unsafe, use pointers, be careful", and "everything is safe, I can trust references".
<JamesMunns[m]>
basically: using references in unsafe code is EXTREMELY easy to piss Miri off.
<hayley_gayley[m]>
But in general that discussion seems to have stalled(?) online, so step one would be figuring out where it left off and collecting pro's and cons and then polling the relevant teams
<JamesMunns[m]>
(because reference invalidation, at least in stacked borrows, is extremely easy to trip over, and bam you got yourself UB)
<dirbaio[m]>
hayley_gayley: the issue is a bit more subtle
<dirbaio[m]>
the memory models (stacked borrows, tree borrows) don't even specify what "volatile" means
<dirbaio[m]>
they don't because "volatile" is not a memory access to the "abstract machine"'s memory
<Jonas[m]1>
But I had the impression that it was possible to advertise using Coded PHY on the 3 advertisement channels. I think "extended advertisement" means that it is advertising on the data channels.
<dirbaio[m]>
Jonas[m]1: maybe you're confusing it with the "scan response" data which does go on the data channels
<dirbaio[m]>
dirbaio[m]: that's for "scannable" adv, not "extended" adv
<dirbaio[m]>
dirbaio[m]: I think the main adv data always goes on an adv channel, extended or not
<dirbaio[m]>
dirbaio[m]: not 100% sure tho, you might want to doublecheck with the ble spec
<Jonas[m]1>
dirbaio[m]: ok, you might be right. Thanks a lot for the help!
fu5ha[m] has joined #rust-embedded
<fu5ha[m]>
<dirbaio[m]> "but the proposed replacements..." <- Less ergonomic to force you to think about the bad things you're doing ;p
<dirbaio[m]>
🤣
<dirbaio[m]>
yeah
<dirbaio[m]>
sabotaging the UX of "bad" stuff to steer users away from it
<fu5ha[m]>
Exactly
<fu5ha[m]>
At work in wasm land we also use what I think is James Munns suggestion of basically unsafely implementing sync on top of a single threaded oncerefcell because we have privileged knowledge we are only ever running in a single thread
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
you'd think this would work
<dngrsspookyvisio>
but consider: C++
<dirbaio[m]>
dngrsspookyvisio: > <@dngrs:matrix.org> you'd think this would work
<dirbaio[m]>
> but consider: C++
<dirbaio[m]>
the whole UX of C++ is so thoroughly sabotaged that users are insensitized, so you can't use ux anymore to steer anything :D
<JamesMunns[m]>
I actually side with gankra here
<JamesMunns[m]>
You SHOULD be specific about how you use it, but unsafe SHOULD be more ergonomic than it is today.
<JamesMunns[m]>
We don't need to do "guilt and shame and penance" thing when you use unsafe
<fu5ha[m]>
I've been wanting to make a blog post for some time about "why mutability xor sharing is important even when we are only ever in a single thread". Which has some tie in with why static mut is dangerous even in a single thread
<JamesMunns[m]>
Like you should be CAREFUL, not GUILTY.
<fu5ha[m]>
JamesMunns[m]: Oh absolutely I agree with that.
<JamesMunns[m]>
fu5ha[m]: I think Manish did a good blog post I vaguely remember about this
<dirbaio[m]>
I have a firmware where ALL the functions are unsafe and all data is in static mut 🤣
<fu5ha[m]>
Usage of unsafe should be well considered and fully reasoned, not shamed
<fu5ha[m]>
As of now there are times where we don't even have the fully defined semantics to reason about it though which is a bit unfortunate
<fu5ha[m]>
Thankfully t-opsem is working on it
<fu5ha[m]>
JamesMunns[m]: Yeah I think I've read it, but a while ago. I should read it again. Also the beginning of the tree borrows presentation has a quite nice example
<fu5ha[m]>
For reference: https://youtu.be/zQ76zLXesxA?si=6BmmSE8C5ZPjjPXJ it's a very good presentation about both stacked and then tree borrows and also why a model like one of them is even necessary
jannic[m] has joined #rust-embedded
<jannic[m]>
<dirbaio[m]> "I have a firmware where ALL..." <- Written in C?
<dirbaio[m]>
almost 🤣
<dngrsspookyvisio>
Ruct
<dirbaio[m]>
it's a tiny firmware that reads commands over uart and moves a motor. a few hundreds of lines. no hal, no async, no interrupts.
Guest7221 has left #rust-embedded [Error from remote client]