<ryan-summers[m]>
I know I've been waiting for this for a while now, so figured others may find it nice to see :)
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 255 seconds]
pronvis has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]>
Before anyone gets too excited
<M9names[m]>
> We expect to begin offering Arm runners for open source projects by the end of the year
<ryan-summers[m]>
Aw I didn't see that caveat. Thanks for pointing it out
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
pronvis has quit [Ping timeout: 252 seconds]
David[m]12 has quit [Quit: Idle timeout reached: 172800s]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 272 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 246 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
marklanders[m] has joined #rust-embedded
<marklanders[m]>
Hi guys, very dumb question...is there a nice way in no-std rust to use match with an u8 vs an enum?
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
<ryan-summers[m]>
<marklanders[m]> "Hi guys, very dumb question...is..." <- `num-enum` works nicely for this
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 246 seconds]
<marklanders[m]>
<ryan-summers[m]> "`num-enum` works nicely for this" <- Thanks I see it's no std compatible
<marklanders[m]>
can give a look
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 246 seconds]
pronvis has joined #rust-embedded
shalok has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 255 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 272 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
pronvis has joined #rust-embedded
<JamesMunns[m]1>
Just checking if adamgreig is back from EMF :D
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
👀
pronvis has quit [Ping timeout: 268 seconds]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
👋
<adamgreig[m]>
I am, though sadly brought a lurgy back with me so not feeling great
<JamesMunns[m]1>
Need me to run it back?
<adamgreig[m]>
hi @room, meeting time! agenda is https://hackmd.io/WZprvkVoQzWlRyaMjKCO4w, please add anything you'd like to announce or discuss and we'll kick off in a couple minutes!
<therealprof[m]>
So EMF really is what I thought it should be. 😬
almindor[m] has joined #rust-embedded
<almindor[m]>
I'm a bit strapped for time, but I'm in full favour of both the riscv proposals, unsafe for csr writes and fallible instead of panics in riscv
<adamgreig[m]>
one talk I went to was just about doing some random embedded thing but incidentally and of course they were using rust and embedded-graphics :p
<adamgreig[m]>
ok, let's start! no announcements from me, James Munns did you want to say anything about oxidize?
<JamesMunns[m]1>
Nope, just another event, good to see people. Had some interesting chats, not sure if anything actionable, but talked to a lot of people, some from industry there officially/unofficially about the state of things.
<adamgreig[m]>
any other announcements from anyone?
<adamgreig[m]>
sounds good!
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Henk and I are working on the Discovery Book as we speak. Once we have worked things out a bit I will modify the RFC PR and ask for feedback next week.
<adamgreig[m]>
ok, on to the agenda items, I've put the things from last week at the bottom so we can start with the newer bits, James Munns do you want to go first with the leadership council item?
<JamesMunns[m]1>
Sure! Nothing super actionable yet, just attended my first meeting 2 weeks ago, and we have our next meeting at the end of this week.
<JamesMunns[m]1>
One of the first things I'll likely be focusing on is figuring out how groups like the embedded wg fit into the project. This was discussed a bit at RustNL as well, and I plan to carry some of that forwards
<JamesMunns[m]1>
in particular it was proposed that it could make sense to have some part of the EWG join the Rust project, potentially promoting some libraries like the architecture crates and embedded hal to the rust-lang/ project
<JamesMunns[m]1>
That being said, we are a pretty broad team, and IMO largely split into two main components:
<JamesMunns[m]1>
1. Being a place for the widest set of people interested in embedded rust
<JamesMunns[m]1>
2. Maintaining common fundamental pieces of the ecosystem
pronvis has quit [Ping timeout: 256 seconds]
<JamesMunns[m]1>
The Rust project leadership structure is much more focused on groups of people that "maintain code", than groups that "maintain ecosystems": There's not much established for "cross cutting concerns" teams, that the EWG might fit into.
<JamesMunns[m]1>
So: I'll likely try and distill what we talked about at RustNL this week, and add it to the agenda for the leadership council meeting this week. If anyone has opinions on it, I'm happy to chat! I don't think I'll be proposing any action this week, but starting the discussion.
<JamesMunns[m]1>
Since I also represent the other WGs in the Launching Pad, it's also something I'll need to socialize with all of them, to see if there is a common pattern that fits. That being said, EWG and Async WG are certainly the largest and most active groups in that umbrella.
<JamesMunns[m]1>
So: No specific items to discuss, unless anyone has had thoughts since RustNL, but if you're interested in staying tuned let me know and I'll share when I have more to share.
<JamesMunns[m]1>
(that's all I have unless people have comments or questions!)
<adamgreig[m]>
sounds good! consider me interested, happy to discuss or help out (illness permitting, anyway)
<tamme[m]>
I heard from some people they find it hard to start with embedded rust because they need to make choices for buying chips or dev boards but don't know which are supported
pronvis has joined #rust-embedded
<tamme[m]>
now there is awesome embedded Rust, which lists drivers, I took that list and tried to improve on it
adamhott[m] has joined #rust-embedded
<adamhott[m]>
Nice one!
<JamesMunns[m]1>
Very very cool! Any chance to add an "embedded-hal version" and "embedded-hal-async version" supported columns?
<JamesMunns[m]1>
(We definitely need to cull/give love to drivers that are still on 0.2.x, and it would be useful to see which ones support async or not!)
<tamme[m]>
for now the tool can take a CSV with crate name and interface (I2C/SPI/etc) and looks up some info on crates.io
<adamgreig[m]>
you can filter to crates that depend on embedded-hal-async@1.0.0 for example
<tamme[m]>
Yes adding those columns should be easy, the info is already in there
<therealprof[m]>
Very sweet!
<JamesMunns[m]1>
(oh and maybe also group embedded-io embedded-io-async in that?)
<Henk[m]>
Would be cool to get more crates in awesome embedded Rust somehow
<tamme[m]>
But I think the list is not very complete, for now its all drivers in the awesome embedded rust driver list... but for example there are almost no async compatible crates
<JamesMunns[m]1>
one thing to maybe also look at is reverse deps of e-h and e-h-a?
andar1an[m] has joined #rust-embedded
<andar1an[m]>
Cryptography.rs does a nice job of creating a nice static page
<andar1an[m]>
It also shows validation or audits. I dk of something similar would be useful metadata for embedded
<adamgreig[m]>
maybe even badges for e-h 1.0, e-h-a, that sort of thing
<tamme[m]>
My aim for it is to be similar to the digikey shopping experience: Select roughly what you want, like temperature sensor, and then filter the available crates until you got the one you need
<andar1an[m]>
Could that also be used to give feedback on where dev is needed?
<tamme[m]>
I think so, for example you can now see all the crates that do not support e-h 1.0 and start sending PRs to update them
<tamme[m]>
One thing I did not figure out yet is where to store extra information like category, interfaces, sampling rate, resolution... for now its in a CSV which feels not too nice
<adamgreig[m]>
so I guess my question is what you want to do with this: we should at least link to it from the awesome-embedded-rust page, but could it make sense to replace the drivers part of that page entirely?
<tamme[m]>
I think for now its just a prototype, but I would love for it to live on/next-to awesome embedded rust
<adamgreig[m]>
scrolling down a really long README that's split into normal and WIP drivers is not as nice an experience as the web page, and while in theory right now we have good curation of what gets added, we don't have much in the way of updates or ongoing curation after addition
<tamme[m]>
And if that works well we could have a similar one for HALs
<therealprof[m]>
The driver section of aer and the rules around it are a bit dated...
<tamme[m]>
It does not yet contain all the information the readme has, notably I did not manage to copy all the blog post links
<therealprof[m]>
Yeah, the problem is that most of the drivers have been added years ago. Not sure how many of those links are still working and/or relevant.
<adamgreig[m]>
whereas this new page has last-updated, version number, download count, all the useful metadata you want to get an idea for how used it is
<therealprof[m]>
Something that automatically updates from crates io and provides additional details and search/sortability would be much nicer.
<adamgreig[m]>
having an optional link to blog posts and such would be nice too. i don't know if it makes sense to have any sort of "vetting" for what's included?
<andar1an[m]>
Vetting may be nice to make ux better. At least for usability
<tamme[m]>
Yeah I was balancing between, having a list that can be updated via PR or automatically finding them by keywords on crates.io or similar
<therealprof[m]>
Honestly download counts yield a much better picture of what is used and thus usable than any manual process.
<tamme[m]>
I'm also leaning towards vetting
<adamgreig[m]>
maybe you could have a lot of things pulled in automatically but hidden-by-default with a filter based on whether it's been "vetted" i.e. manually approved?
<andar1an[m]>
therealprof[m]: This could indicate demand but not a quality solution though?
<adamgreig[m]>
then at least other crates are discoverable
<therealprof[m]>
Requires someone willing to do the vetting.
<adamgreig[m]>
yea, and some sort of policy for what it means to be vetted
<adamgreig[m]>
and what, do you do it for every release? or just once? or...
<adamgreig[m]>
it's not like the cryptography crates where the vetting is like "this has been security audited" or "this has been formally verified"
<andar1an[m]>
Is there any feedback mechanism? Like how many still used / downloads
<therealprof[m]>
andar1an[m]: Well, a vetted crate doesn't necessarily mean high quality; if people keep on using crates, they can't be that bad.
<adamgreig[m]>
it could be like "someone who wasn't the author tested this and it worked", but that's a lot of work
<JamesMunns[m]1>
andar1an[m]: upvotes to the left :D
<dirbaio[m]>
"must not light your house on fire"
<tamme[m]>
I guess some part of the process needs to be manual, because detecting which interfaces a chip has is hard to automate
<JamesMunns[m]1>
therealprof[m]: quantity is its own quality
<adamgreig[m]>
dirbaio: but what about my driver for the house-setter-on-fire chip :(
<dirbaio[m]>
as long as it's unsafe {} it's ok
<dirbaio[m]>
/// Safety: lights your house on fire
<therealprof[m]>
A better crates.io for our needs would go a long way.
Koen[m] has joined #rust-embedded
<Koen[m]>
Hello! 👋 For UX, what I think would be cool to have, is a column with the chip/component targeted by the driver. Currently this requires looking in the description, but as some descriptions contain an exhaustive list and some contain wildcards (x) in the name (ads1x1x), a simple browser based search doesn't always cut it
<tamme[m]>
I thought about having a count/list for posts mentioning this chip, so you could find chips which were used by others and you could see how they used them
<adamgreig[m]>
yea, some sort of field for the chip targetted sounds nice, though i guess a lot of the time it will be the crate name or some sort of wildcard
<Koen[m]>
A search that would match the ads1x1x driver when entering 'ads1013' in a search field would be awesome!
<tamme[m]>
Koen[m]: Yes, I think that would be better, maybe also manufacturer
<adamgreig[m]>
you could specify a regex for supported chips or something... now you have regex problems lol
<Koen[m]>
Like, that final bit of matching can be done manually by the user I guess, assuming only a handful results remain
jannic[m] has joined #rust-embedded
<jannic[m]>
What about automatically taking content from crates.io, with a manually maintained list of overrides, in case auto-detection gets it wrong? Hoping that the number of needed overrides stays small so it's manageable?
<therealprof[m]>
A lot can actually be inferred from the dependencies.
<tamme[m]>
adamgreig[m]: Could just be a pre aggreed place holder character
<adamgreig[m]>
harder to infer things like manufacturer, protocol, device name, though
<adamgreig[m]>
tamme: sure, that might be better overall, though does mean you'll get some false positives i guess
<therealprof[m]>
embedded-hal 0.2 vs 1.0, cortex-m, risc-v, linux dependencies, etc.
<Koen[m]>
Nah, everything that starts with an 'A' is Analog Devices, everything with a 'B' is from Bosch 😇
<adamgreig[m]>
therealprof: yea, that's easy to get, and this page already lets you filter based on it for example
<therealprof[m]>
Exactly.
<adamgreig[m]>
well, if nothing else I guess this gives you some ideas tamme! if you want to keep prototyping it for now go ahead, but it seems like it would already be great to have a link to it at the top of the drivers section of a-e-r
<therealprof[m]>
I think a lot of crates also might have useful tags...
<tamme[m]>
Thanks for all the ideas and encouraging feedback :) I started adding issues to the repo, feel free to add more if you get more ideas!
<adamgreig[m]>
but yea, if you were interested in having it replace large chunks of a-e-r altogether i think that would be interesting too 👀
<JamesMunns[m]1>
therealprof[m]: If tamme starts suggesting consistent tags that will get you on that list, I think people would be willing to add them :D
<therealprof[m]>
We could encourage crate authors to put relevant keywords in their Cargo.toml.
<JamesMunns[m]1>
Thank you for doing this tamme, it's already so good and I'm excited for it :)
<tamme[m]>
Can you add a custom section to your Cargo.toml? or do you need an extra file for that?
<therealprof[m]>
Right, those keywords might also indicate vendors.
<adamgreig[m]>
yea, having a set of relevant tags (like spi/i2c, accelerometer/barometer/...) that the page knows how to use and categorise based off could be fun
<JamesMunns[m]1>
tamme[m]: There's also a semistandard metadata section
<adamgreig[m]>
do you have to download the whole crate to get that?
<adamgreig[m]>
i was thinking of the keywords attribute but you're only allowed 5, so...
<JamesMunns[m]1>
adamgreig[m]: I think it's in the manifest? I'm not sure...
<andar1an[m]>
Have you seen zola?
<andar1an[m]>
I dk if it can help ease frontend pain. But it is pretty cool
<tamme[m]>
Another alternative would be to have a repo full of toml files each describing a chip/family of chips and which crates support them
<andar1an[m]>
Like hugo but rs
<tamme[m]>
For now its a pretty simple Svelte app, which includes a JSON blob with all the info... supper uggly for now but it works :D
<JamesMunns[m]1>
tamme[m]: I think if you document how you want it done, it'd be easier to PR those things to the various crates
<therealprof[m]>
adamgreig[m]: Yeah, but if we have conventions for the keywords, like vendor:Bosch, model:INA260, interface:I2C then that would go a long way.
<adamgreig[m]>
although given it would then need a new release of each crate, I wouldn't necessarily want to gate the features on having the drivers all do this, so maybe still worth having the manual settings you have now too
<adamgreig[m]>
therealprof: keywords are max 20 chars and very limited set of special chars, so I dunno if it would be a great fit there
<tamme[m]>
The annoying thing if it is part of the crate is, that whenever you want a new field all drivers would need to release a new version
<tamme[m]>
It could also allow both, either you submit a toml via a PR to the list or you put that toml in your crate
<adamgreig[m]>
yea, and a lot of drivers are basically write-once-and-done I think, it's often feasible to basically do the whole thing and publish it and not ever need to touch it again (barring e-h updating to 1.0 anyway 😆)
<adamgreig[m]>
so "new crates can put metadata in manifest and get picked up automatically, existing crates get the metadata added manually" seems like a good compromise
<therealprof[m]>
tamme[m]: Well, yes, but this is best effort and I don't think people that care would mind.
<adamgreig[m]>
let's move on to the other agenda items today, thanks tamme!
<therealprof[m]>
adamgreig[m]: Gotcha, so it's v_Bosch, m_INA260, i_I2C
<adamgreig[m]>
I'm not sure who added the point about cleaning up old/inactive issues, anyone want to chat about that?
<therealprof[m]>
* Gotcha, so it's v\_Bosch, m\_INA260, i\_I2C
<JamesMunns[m]1>
I'll see if I can do this for next week. Just /wg and /embedded-hal to start?
<adamgreig[m]>
"In the European .csv files the separator is a semicolon ';', not a comma." lol
<adamgreig[m]>
yea, seems like a good starting point, and probably at least an hour's worth
<JamesMunns[m]1>
adamgreig[m]: yeah love me some locale based hell
<adamgreig[m]>
we can check on the state of other repos later
<jannic[m]>
Cortex-m also has 82 tickets. So we won't run out of tickets. But let's start with some subset.
<JamesMunns[m]1>
k, I'll have a spreadsheet with some checkboxes for "dibs", "reviewed", "relevant", etc.
<adamgreig[m]>
thanks!
<adamgreig[m]>
ok, I think let's postpone timer trait for now as it's already been discussed a lot and we don't have much time left, and we've already heard about the discovery book
<adamgreig[m]>
I was away all last week and now sick but the c-m-rt release is still high on my radar, hopefully that will be done by next meeting
<adamgreig[m]>
we probably don't have much time to discuss the other points but I did want to highlight that we've been discussing having PACs give safe global write access to MMIO which is the opposite of the proposed "all CSR writes are unsafe" for riscv
<therealprof[m]>
I'm not sure I'll make the next two meetings, have to run an event next week and will be in Korea the week after.
<JamesMunns[m]1>
therealprof[m]: safe travels, and enjoy!
<adamgreig[m]>
it should probably be consistent, though it's not impossible that we end up with "consistently unsafe CSRs in arch crates, unsafe by default but it's a config option in svd2rust, safe by default in chiptool PACs"
<adamgreig[m]>
some of the CSRs really are a lot more obviously desperately unsafe than most PAC registers
<adamgreig[m]>
"yes please swap my stack pointer to a different thing, good luck rust"
<adamgreig[m]>
with PACs I think the only argument is around DMA, and there's a convincing analogy to safe writes to /dev/mem or /proc there
<adamgreig[m]>
but with CSRs on arch crates I'm less convinced...
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
I think the PR wants to leave all registers unsafe by default and then go one by one and swap to safe when there is no clear issues with a particular register
<romancardenas[m]>
Otherwise, having everything unsafe is perhaps safer but less ergonomic
<JamesMunns[m]1>
fwiw the justification of "make it all safe" is that it makes the *other* unsafe stuff easier to see, like accidental DMA bugs or whatever in HALs
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
I think the more appropriate analogy is syscalls or ffi, which are unsafe until proven otherwise
<adamgreig[m]>
cool, if the plan is unsafe by default and selectively safe that sounds good too
<adamgreig[m]>
ok, that's all we have time for this week, thanks everyone!
<adamgreig[m]>
see you next week for issue triage :D