<JamesMunns[m]>
I might have to run a little early, but did want to mention that I'll be at Embedded World (in a booth!) next year, if anyone else is starting to plan that too :)
<adamgreig[m]>
@room meeting time! I'll be with you in 5 minutes or so but in the meantime feel free to add anything to the agenda
<adamgreig[m]>
Just wrapping up setting fire to the atmosphere...
<JamesMunns[m]>
JamesMunns[m]: Sharing the booth with some other embedded rust friends, but I don't want to spoil it for them, in case they haven't announced it yet (you know who you are if you do want to :D)
James[m] has joined #rust-embedded
<James[m]>
there is a meeting o.O? Im new here
<JamesMunns[m]>
James[m]: yep! Weekly meeting, 8pm on tuesdays, berlin time
therealprof[m] has joined #rust-embedded
<therealprof[m]>
JamesMunns[m]: I guess I need to check my calendar then. 😉
<adamgreig[m]>
ok, all the fires safely extinguished!
<adamgreig[m]>
any other announcements?
<adamgreig[m]>
berkus: it's just here, in chat
berkus[m] has joined #rust-embedded
<berkus[m]>
where's the meeting happening?
<berkus[m]>
ahhh alright
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Save the date: next Rust Embedded Discovery Book Sprint scheduled for January 25.
<bartmassey[m]>
Christmas month etc got in the way, so we put it a ways in the future.
<bartmassey[m]>
That will also give me more time to finish the chapter from the last Sprint 😀
<berkus[m]>
burrbull: the stm32 maintenance thing?
<adamgreig[m]>
ok, no announcements from me this week so let's start on the agenda
<adamgreig[m]>
berkus: stm32-rs is also me, but it's not part of the embedded wg, so really that's a discussion for another place, maybe #stm32-rs:matrix.org or just DM me if you want to help maintenance?
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
📣 embassy-executor v0.6.3 released. Fixes building with the feature `nightly` with the xtensa compiler.
<dirbaio[m]>
(just noticed the readme still stays the on-flash format is not stable... I didn't intend that lol. it's been stable for quite a while, it won't get breaking changes anytime soon)
<dirbaio[m]>
(should probably update it. grrrr)
<adamgreig[m]>
ekv 1.0.1
<adamgreig[m]>
* ekv 1.0.1 🎉
<adamgreig[m]>
shame semver doesn't have 1.0.0-post1
<dirbaio[m]>
1.0.0-oopsie1
<adamgreig[m]>
ok, mabez did you wanna chat about the hal stuff?
mabez[m] has joined #rust-embedded
<mabez[m]>
Sure!
<mabez[m]>
I basically think that HAL authors should make a bit of concerted effort to push driver crates to be updated to eh1.0
<berkus[m]>
Is there a list of crates that need an update?
<mabez[m]>
I understand why these 0.2 impls exist, but if we were happy with eh 0.2 we should have called it 1.0
<mabez[m]>
but we weren't so we shouldn't give it 1.0 status just because it existed for a long time
<mabez[m]>
berkus[m]: It's hard to tell exactly because of the different versions, and some still choosing to support both 0.2 and 1.0 etc, but its somewhat pointless to even look. If there are none, then we can remove the 0.2 impls, if there are some they need to be removed
diondokter[m] has joined #rust-embedded
<diondokter[m]>
mabez[m]: How? Only thing I can think of is cutting support for 0.2 in the HALs
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
Yes exactly
<bartmassey[m]>
What about the crates that critically depend on 0.2 interfaces that were removed for 1.0?
<jessebraham[m]>
Since my complaining led to this conversation (thanks mabez 😁), I'll add that `0.2.7` is nearly 3 years old, `1.0.0` is nearly a year old
<jessebraham[m]>
And at a certain point we need to rip off the band-aid
<mabez[m]>
bartmassey[m]: Those traits were removed for a reason, they're not fit for purpose
<dirbaio[m]>
bartmassey[m]: those most likely didn't work with all hals anyway due to the associated type incompatibilities (which is why the traits were removed)
<mabez[m]>
We won't see 1.0 evolution until 0.2 is dead
<bartmassey[m]>
@mabez: maybe, but folks presumably have built code that works with them somewhere
<jessebraham[m]>
A large number of the traits in the 0.2.x releases frankly were not useful for driver development IMO anyway
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
bartmassey[m]: one possibility could be to localize the traits, if using them for dynamic dispatch or similar
<berkus[m]>
mabez[m]: So i guess the first thing for visibility would be to collect that list somehow and then track updates. Visibility will be come a long way to be able to point at particular maintainers and crates and see their status.
jannic[m] has joined #rust-embedded
<jannic[m]>
mabez[m]: Not necessarily. We just weren't sure enough to call them 1.0.
<diondokter[m]>
Well I'd say that if supporting the old traits hurts the design and maintenance of a HAL then its definitely a candidate for removing.
<berkus[m]>
s/be//
<jessebraham[m]>
diondokter[m]: Continuing to support the old traits just keeps the ecosystem fragmented
<adamgreig[m]>
which in practice meant they're almost never used in driver crates, aiui
<mabez[m]>
If the old 0.2 traits were close to functional, we'd probably fixed them up and put them in 1.0 by now
<dirbaio[m]>
we were (and still are) unsure how to fix, but we were sure 1.0 wouldn't look like that.
<diondokter[m]>
jessebraham[m]: Maybe? Like no one builds new things with 0.2, so the shift will happen regardless
<adamgreig[m]>
so is the problem "lots of drivers still haven't updated to e-h 1.0, but if we can convince HAL authors to remove 0.2 support, HAL users might ask/patch/update drivers to 1.0"?
<adamgreig[m]>
like it's presumably not an issue in itself that HALs have 0.2 support, only in that it means there's less incentive for drivers to update
<jannic[m]>
To easily filter if a driver supports 0.2, 1.0 or both.
<adamgreig[m]>
and it's hard for one HAL to go alone and drop 0.2 support, because if all the other HALs still support it, drivers still don't update and it's just hard for that HAL
<adamgreig[m]>
so ideally most HALs update to remove 0.2 support together, causing drivers to hopefully mostly update?
<mabez[m]>
adamgreig[m]: Exactly, we want to drop it in esp-hal, but it's somewhat pointless if no one else does
<dirbaio[m]>
how many driver authors would update to 1.0 but only if HALs force them to?
<dirbaio[m]>
to me it feels like most drivers are either maintained (in which case they'd update anyway) or unmaintained (in which case they wouldn't be updated no matter what)
<adamgreig[m]>
the unmaintained ones that are still being used might be forked/taken over to provide 1.0 support at that point though
<akshaim[m]>
Anyone working on enabling Embassy for MAX32xx MCU's ? Any resources available on how to get started ?
<diondokter[m]>
There still are HALs that only support 0.2 like the Stm32H7xx
<adamgreig[m]>
berkus: yea, cortex-m should be, I think that's the only one?
<berkus[m]>
adamgreig[m]: there's quite a bunch, embassy-time - is that ours?
<mabez[m]>
but it's more awkward, and I think that's a good thing because it again pushes drivers to be either updated or forked if they're unmaintained
<adamgreig[m]>
if it starts "embassy-" it's a good guess it's not a wg crate 😅
Ralph[m] has joined #rust-embedded
<Ralph[m]>
i think if HALs go ahead and drop support for e-h 0.2 now and release soon(-ish) (say before the end of the year?) you'll get to hear from consumers which so far used a trait which no longer exists. those are probably the people from whom you wouldn't hear anyway until you do such a step.
<Ralph[m]>
and it's not like you're killing a running project with this - they can just stick to the last HAL version which suppports e-h 0.2 until they're ready to upgrade.
<Ralph[m]>
so i'm all in for dropping 0.2 support in the HALs! and IIRC it was even said when 1.0 was released that the parallel support should only be kept up for ~1 year, so that'd fit now
<berkus[m]>
adamgreig[m]: heh, okay
<adamgreig[m]>
cortex-m in master does support eh1 and still eh0.2, but it's unpublished for various annoying reasons
<berkus[m]>
adamgreig[m]: i guess a major version bump and publish shall push it
<berkus[m]>
there's a bunch of stm32 hals not upgraded, these are outside wg but perhaps VEERY popular
<berkus[m]>
so, some critical mass can be gained here
<dirbaio[m]>
if they haven't been updated yet there's probably a reason...
<JamesMunns[m]>
A lot of the stm32 hals are not actively maintained/only lightly maintained
<bartmassey[m]>
My fear is that if we drop 0.2 support before people have moved we will freeze some largeish fraction of the codebase at whatever 0.2 release was last up, rather than encouraging them to upgrade.
<berkus[m]>
there's a thin layer of crates on 1.0.0-alpha or -rc -> these should be super easy to bump?
<diondokter[m]>
mabez[m]: I've not seen this be said explicit, but is it actually burdening esp-hal? I don't know that HAL well. In embassy it seems the cost of having the traits there isn't terribly high, though I'll let Dario be the judge of that
<jessebraham[m]>
diondokter[m]: No, but it's 3 extra dependencies, and extra code that could be deleted
<JamesMunns[m]>
(gotta run, have a nice week y'all!)
burrbull[m] has joined #rust-embedded
<burrbull[m]>
Is it possible to write some "dependabot" which remind driver authors to upgrade?
<jessebraham[m]>
I just don't understand the point of putting all the work into a 1.0.0 release if 0.2.x is going to be treated as equal in quality to it
<mabez[m]>
diondokter[m]: Maintaining the traits is no problem, but why would we do this? It's a 0.2 release of a crate where a 1.0 exists?
<mabez[m]>
If it was a case of supporting 1.0 and 2.0, that's a different story - 0.2 is fundamentally flawed and 1.0 fixes that
<diondokter[m]>
Ok understood. I guess this is really just about costs and benefits.
<adamgreig[m]>
i mean, we'd certainly like people to move to 1.0, and for the traits still in 1.0 i think they're clearly the better option
<berkus[m]>
Is there an "upgrade automation" that can take care of at least some mechanical changes in the upgrade?
<jannic[m]>
The wg could yank all 0.2.x versions :-)
<mabez[m]>
> <@adamgreig:matrix.org> but the wg can't make that happen, at best you can make a pact with some other HAL authors to all drop it together :P
<mabez[m]>
jannic[m]: We could do that too, but I already made enough spicy comments for the day :D
<dirbaio[m]>
jannic[m]: and watch the world burn
<adamgreig[m]>
it's not like yanking it would force drivers to update, lol
<jannic[m]>
dirbaio[m]: At least it would be less disrupting than releasing a broken 0.2.8. (Don't make me think about even more evil alternatives.)
<adamgreig[m]>
😱
<berkus[m]>
jannic[m]: That's evil enough. I approve.
<adamgreig[m]>
0.2.8's build script finds any driver crates on your filesystem and updates and publishes them
danielb[m] has joined #rust-embedded
<danielb[m]>
adamgreig[m]: with chatgpt for extra chaos
<jannic[m]>
Back to topic: At least the WG could make a statement that everybody should upgrade and 0.2 is no longer supported (whatever that would mean).
<adamgreig[m]>
I think that's already the case, right? the hal team could add a note to the readme if they wanted, but I don't know how we'd ensure old driver authors see it
<jannic[m]>
I'd hope that for all drivers that are still maintained, a little nudge might be sufficient to get the author do the update. And for unmaintained crates, whatever we do wouldn't help, short of forking the driver on our own.
<Ralph[m]>
<JamesMunns[m]> "A lot of the stm32 hals are..." <- i wonder whether this would be a good reason to reduce some of the fragmentation of the HALs? i'm probably too far away from this and risk starting a religious war: but why are there so many different HALs, esp. for STM32? maybe focus on one (or 2, if there are good reasons for a different implementation)? e.g. embassy seems to cover all STM32 versions while there are various
<Ralph[m]>
`stm32XYYY-hal`s out there... (note: my only personal experience with STM32 HALs is the `stm32f4xx-hal`, so i can't compare!)
<adamgreig[m]>
none of them are maintained by the wg, they're all independent projects
<adamgreig[m]>
it's kinda like asking why there's so many RTOSs out there when we could all just focus on chibios
<dirbaio[m]>
the reason embassy-stm32 exists is to solve the copypaste/fragmentation in stm32-rs hals
<rmsyn[m]>
jannic[m]: maybe in addition, add a compiler (build script) warning about 0.2 being deprecated in a new point release?
<dirbaio[m]>
and the only other stm32 hal that's neither stm32-rs nor embassy exists because the author dislikes async and ownership
<dirbaio[m]>
* and ownership / typelevel stuff
<JamesMunns[m]>
rmsyn[m]: I'm not sure dep warnings appear in end build
<danielb[m]>
dirbaio[m]: so... the author dislikes Rust?
<danielb[m]>
JamesMunns[m]: they do, esp-hal uses something like that to recommend --release builds
<JamesMunns[m]>
(they only do with local reps)
<dirbaio[m]>
I already asked why not make a single hal in stm32-rs back then before embassy-stm32 existed and the answer I got was "why is this question asked every Tuesday"
<dirbaio[m]>
soooo ... 🤷
<JamesMunns[m]>
s/reps/deps/
<JamesMunns[m]>
danielb[m]: (they only do with local deps)
<jannic[m]>
Driver crates that only support e-h 0.2 could be moved to an "outdated" section in awesome-embedded-rust, and drive-rs could add an appropriately scary icon?
<adamgreig[m]>
oh, yea, we could definitely curate a-e-r and/or drive-rs to help encourage 1.0 use
<adamgreig[m]>
i have to head out now; no objection to us doing something to help encourage 1.0 migration, probably anything in the e-h repo/crates is a topic for an issue/PR on the repo and the hal team can decide?
<mabez[m]>
Overall I think the general consensus is that removing support for 0.2 is a good thing, albeit without it's challenges. I think to start, I'm going to prepare a PR for eh adding a note that we advise HAL authors not to implement the 0.2 traits
<adamgreig[m]>
thanks everyone, see you next week!
<mabez[m]>
s/without/with/, s/ not/_not_/
<dirbaio[m]>
i'm not convinced about removing 0.2 in hals 😅
<dirbaio[m]>
I mean, each hal maintainer can choose what they want for their hal
<dirbaio[m]>
but i'm not sure if i'd do it for embassy
<jessebraham[m]>
"The year is 2054, half of Rust driver still use eh-0.2" 😁
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
In the desktop world with winit we tend to just feature gate the old raw-window-handle crates if those are supported
<dirbaio[m]>
feature-gating adds a speedbump for the users, but doesn't give incentives for the driver maintainers to update
<i509vcb[m]>
Also given you all are at a 1.0 release I wouldn't think there would be so much friction to this
<Ralph[m]>
maybe you could release an e-h 0.2.8 with the only change to 0.2.7 being that it prints a warning during build stating something along the lines of "hey, you're still pulling in an old release of e-h, please check your dependency tree and either update these dependencies or raise an issue with them to update e-h on their side!". this, coupled with HALs & co. disabling e-h 0.2 support by default (feature gated) would help find cases
<Ralph[m]>
where it's still being used (as then it'd also show up in builds of driver crates - of course, that's only useful if said driver is still being built and the logs looked at). the message combined with the speed bump for the user should encourage the user to get the driver updated
<i509vcb[m]>
I propose we gate eh 0.2 behind a `bug_driver_developers_to_update_to_eh_1_0` feature
<burrbull[m]>
<jessebraham[m]> ""The year is 2054, half of..." <- 0.1
<i509vcb[m]>
Although what about abandoned drivers? I assume those just aren't going to be updated unless someone new maintains it
<diondokter[m]>
Oh good question, how fast was 0.1 dropped when 0.2 came out? I don't quite remember
<JamesMunns[m]>
Ralph[m]: We discuss that above, we can't enjoy warnings most users will see.
<JamesMunns[m]>
s/enjoy/emit/
<diondokter[m]>
i509vcb[m]: The argument is that it'd force people to fork it and come with new versions by other people
<mabez[m]>
Each HAL is its own entity outside of the WG, so we can't dictate what they do, I just think we can be a bit more suggestive in the e-h crate itself about what should be supported and what shouldn't (though following semver, this should be quite obvious)
<JamesMunns[m]>
mabez[m]: We could yank all pre 1.0 versions 🙃
<JamesMunns[m]>
Ralph[m]: > Warnings are only shown for path dependencies (that is, those you’re working on locally), so for example warnings printed out in crates.io crates are not emitted by default.
<i509vcb[m]>
Yanking the versions feels a bit like abusing the yanking feature
<jessebraham[m]>
JamesMunns[m]: Can you elaborate on this? I'm not sure I follow. I have a project open right now where package A depends on `esp-hal`, package B depends on package A, and building package B emits the warnings (sorry, private repo, confusing names 😁)
<i509vcb[m]>
It wasn't some huge build error or vulnerability as why it would be yanked
<JamesMunns[m]>
i509vcb[m]: Yeah the /s was for sarcasm, I don't think it's a good idea
<jessebraham[m]>
> <@jamesmunns:beeper.com> We discuss that above, we can't emit warnings most users will see.
<jessebraham[m]>
* Can you elaborate on this? I'm not sure I follow. I have a project open right now where package A depends on `esp-hal`, package B depends on package A, and building package B emits the warning when building in debug (sorry, private repo, confusing names 😁)
<i509vcb[m]>
And element mobile is broken
<JamesMunns[m]>
jessebraham[m]: It only prints for path deps, not cratesio deps
<jannic[m]>
What are the disadvantages of hals supporting e-h 0.2 indefinitely? I see mainly two: Some more complexity (because there are two ways to do the same thing, and hals contain some duplicated code), and fragmentation because new hals or ones that decide to drop 0.2 will no longer work with old drivers.
<jannic[m]>
Dropping support for 0.2 on the other hand will break drivers that didn't update, and causes a different kind of fragmentation due to unmaintained drivers being forked.
<jessebraham[m]>
I don't really get the hesitation, what did people think was going to happen when we published 1.0?
<jannic[m]>
I don't think it's wasted, because new drivers will use 1.0. And nobody works on umaintained drivers by definition. So everyone actually writing drivers benefits from the nicer API of 1.0.
<jessebraham[m]>
Anyway there doesn't seem to be a lot of support for this so I guess we will just keep it
<diondokter[m]>
Well maybe not now. But maybe in a year?
<mabez[m]>
Anyways, I think I'll make the PR regardless, and we can circle back at the next meeting for a resolution
Makarov has quit [Ping timeout: 256 seconds]
<i509vcb[m]>
Trying to interpret what the _POCIx suffixes mean in the place where I'm getting data. I see things like CS1_POCI1 and CS3_CD_POCI3. But the datasheet itself doesn't even recognize the POCI suffixes?
<i509vcb[m]>
There are already dedicated pins for the sck, pico and poci pins
<i509vcb[m]>
* Trying to interpret what the _POCIx suffixes mean in the place where I'm getting data (code generation). I see things like CS1_POCI1 and CS3_CD_POCI3. But the datasheet itself doesn't even recognize the POCI suffixes?
<i509vcb[m]>
The register names slightly mention this but still provide no info
<cr1901>
At least in I2C world, controller/peripheral are now the official terms used in the technical specification.
<JamesMunns[m]>
<dirbaio[m]> "^ and this is why the master/..." <- I thought your policy was "whatever the silicon vendor says, goes" :p
<dirbaio[m]>
Yep, that doesn't mean I like it when the vendor does rename it :D
<cr1901>
The goalposts have been moved to "the vendors should've never made that change, b/c it confuses people".
<dirbaio[m]>
I'm not setting any goalposts, I'm just sharing my opinion
<cr1901>
Which, Oh Freakin' Well... I've always been uncomfortable with how much you've dug into defending M/S dirbaio[m]
<dirbaio[m]>
Sorry for sharing opinions.
<i509vcb[m]>
brand new hardware in the case of the mspm0
<i509vcb[m]>
there is no old name this time
<dirbaio[m]>
to clarify my opinionon the master/slave naming:
<dirbaio[m]>
- I do agree master/slave names are bad due to the connotations they have.
<dirbaio[m]>
- I do use alternative names when there's no downside. For example the Embassy repo uses `main` branch, not `master.
<dirbaio[m]>
- I do think the controller/peripheral names are bad as well, because "peripheral" already had an established meaning in embedded. I'd have preferred something like initiator/target.
<dirbaio[m]>
now, what I DO take issue with is people insisting on renaming in HALs where EVERYTHING ELSE about the chip (datasheets, C libs, SVDs) uses the master/slave names.
<dirbaio[m]>
because inconsistent naming is worse than bad naming
<cr1901>
I use the M/S thing as a litmus test... generally, I _don't_ think it does much in the long term. But the terminology was wrong then and it's wrong now.
<cr1901>
If ppl resist a small change like that, how should I predict they react to having to make more difficult moral changes? And as for inconsistent naming, that's a battle already lost.
<dirbaio[m]>
but at least we can hope to have consistency within a single chip
<dirbaio[m]>
a lot of people pick a chip for a project and stay for months working with just that chip
<dirbaio[m]>
inconsistency between datasheets and rustdocs is much more visible because you jump between them multiple times a day, while you jump between different vendors / chip families much more rarely.
<dirbaio[m]>
For example this is why embassy-nrf calls i2c "twi", even if it's a stupid name. Because Nordic calls it twi.
<dirbaio[m]>
It's a bad name, but at least it's consistent.
<cr1901>
I guess file under "unfortunate/waiting for response from vendor".
<dirbaio[m]>
if mspm0 docs use controller/peripheral for spi then hell yea it makes sense for the rust call to use controller/peripheral.
<dirbaio[m]>
s/call/hal/
<dirbaio[m]>
it's still a bad name, now for different reasons, but ... 🤷
<dirbaio[m]>
consistency
<i509vcb[m]>
At least it isn't UART TX and RX
<cr1901>
MSPM0 is probably new enough that it honors the I2C spec as-is