<flippette[m]>
<barafael[m]> "I have problems with unit..." <- > <@barafael:matrix.org> I have problems with unit tests in my workspace. I have a workspace with two crates - a firmware crate and a library crate. The library crate is `#![cfg_attr... (full message at
<adamgreig[m]>
ok, let's start! fairly small agenda this week I think. only announcement from me is that cortex-m-rt 0.7.5 is finally out, with thanks to everyone who contributed to some bug fixes and new features
<adamgreig[m]>
please give it a go and report any issues!
<adamgreig[m]>
the only other item on the agenda is about https://tweedegolf.github.io/drive-rs/, and I think specifically whether we want to have both it and the a-e-r list in existence or what
<adamgreig[m]>
ah, hi tamme! didn't spot your username
<adamgreig[m]>
great work, it's looking really good!
tamme[m] has joined #rust-embedded
<tamme[m]>
Yes, drive-rs is now in a functional state (can search by text and has categories) :)
<adamgreig[m]>
though the search seems to be weirdly a little bugged for me on firefox, if I add more spaces it eventually narrows down correctly
<tamme[m]>
I guess it could replace awesome embedded Rust if it is ok for the maintainers of that list
<JamesMunns[m]>
I think it could replace the drivers section!
<adamgreig[m]>
if you search "ad9" for example it gets 17 results, many of which don't have "AD9" in their name/description I think, but if you search "ad9 " we get 61 results, then "ad9 " gets just the two AD9xxx drivers
<tamme[m]>
adamgreig[m]: oh that is weird :D I just use an of the shelf fuzzy text search
<tamme[m]>
yeah it seems to not work great with short text input
<dirbaio[m]>
yeah search is weird. I've searched "embassy" and there's ~10 results that have nothing to do with embassy
<adamgreig[m]>
yea, I'm on board with it replacing the drivers section of a-e-r, it's a really nice page and easier to use than the big list
<dirbaio[m]>
* yeah search is weird. I've searched "embassy" and it gives ~10 results that have nothing to do with embassy
<adamgreig[m]>
I think the question is a) can we make sure everything that was on that list ends up here and b) who/where is the underlying list maintained
<adamgreig[m]>
(plus hopefully tweak the fuzziness on search lol)
<tamme[m]>
The drivers are currently added manually in a toml file for each driver, in the long term I want people to just add an drive-rs.toml to their crate to list it. But until we actually know which information is interesting I think it is better to keep all the tomls in one place, so they can all be updated at once if needed.
<tamme[m]>
I also have a CSV file which I regexed together from the old driver section, but it might miss some drivers.
<adamgreig[m]>
if people add drive-rs.toml to their crate to maintain the metadata, do we just need a list of all the crates to include?
<adamgreig[m]>
(eventually)
<tamme[m]>
adamgreig[m]: I think we can then take all reverse dependencies of `embedded-hal` download the latest version and check if they have a `drive-rs.toml`
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Sounds clever. Unless there's some limit to automatically scanning crates.io.
jannic[m] has joined #rust-embedded
<jannic[m]>
Or use a crates.io keyword?
<dirbaio[m]>
instead of drive-rs.toml i'd suggest a [metadata.drive-rs] section in Cargo.toml. One less file, less clutter.
<adamgreig[m]>
I guess "published on crates.io" and "depends on embedded-hal or embedded-hal-async" is a pretty good filter
<tamme[m]>
therealprof[m]: I just use the database dump currently so that should not load crates.io too much
<tamme[m]>
tamme[m]: And since crates are immutable we only need to fetch each crate version once and then can cache it I guess
<jannic[m]>
https://crates.io/data-access shows a few options to access the data. Using the dump sounds like a good choice.
<adamgreig[m]>
I assume this "build the database" operation runs like once a day or two, so even just hitting the "ask crates.io for rev-deps of embedded-hal/embedded-hal-async" might be just as good and save downloading the dump?
<adamgreig[m]>
does the database dump include the metadata in cargo.toml or would we have to download the crate zipfile anyway?
<tamme[m]>
yes, but unfortunately I need the dump anyway to calculate the recent download numbers
<JamesMunns[m]>
(crates io is definitely not a fan of scraping - definitely better to use their APIs or exports)
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
I think once a week is more than enough update frequency for this? Maybe once a month is fine?
<tamme[m]>
yeah currently its just updated once a week via CI (or whenever a PR is merged)
<adamgreig[m]>
JamesMunns[m]: ah yea, I didn't mean to suggest scraping, but an API call for rev-deps. but if the database dump is needed anyway then that's easy
<adamgreig[m]>
so I think that just leaves "are you/tweede happy to maintain it" and "are we happy to point to an external list for drivers instead of maintaining a-e-r's"
<adamgreig[m]>
I guess we can always dump drive-rs back to a list in the future if it turned out to be necessary, and especially if drive-rs ends up being a bit more self-service for driver authors that seems nice anyway
<tamme[m]>
I'm happy to maintain it. I don't think I can do much more in terms of features, but keeping it up should be no problem
<tamme[m]>
and the data should also be reusable even if we decide later to ditch the frontend
<adamgreig[m]>
so you'd want help eventually getting it to parse cargo.toml for the metadata?
<tamme[m]>
For now adding more drivers, would help, and with that also add missing categories, manufacturers etc.
<tamme[m]>
I think parsing the cargo.toml shouldn't be too hard, but I would be happy to colaborate on that :)
<adamgreig[m]>
cool
<adamgreig[m]>
for today then, shall we get the link added at the top of the drivers list in a-e-r with a note like "You can also find many of these drivers here; please consider adding your driver there (link to repo) while we work to port everything across" or such?
<bartmassey[m]>
Somebody remember to PR a note for the new Discovery Book pointing there? Helping new folks find drivers would be good.
<bartmassey[m]>
gtg class. See you folks next week 👋
<adamgreig[m]>
<tamme[m]> "I have a draft PR open for..." <- cool, yea, if you're happy to update the text a bit go ahead, or I can leave a suggested change, then we can merge that
<adamgreig[m]>
ah, and I see jannic suggests mentioning https://github.com/rust-lang/rust/issues/130988: there's some ongoing work to figure out which LLVM feature flags (like fpregs, soft-float etc) result in a changed ABI (and just what all the flags are which rust should support), if anyone is interested or knowledgeable about such things please check it out
<adamgreig[m]>
does anyone have anything else to discuss this week?
<jannic[m]>
Sorry if that ticket was already discussed here. I was busy and didn't read this channel all week.
<adamgreig[m]>
I don't think it was, thanks for the reminder
<tamme[m]>
I will be at RustLab this weekend, giving a talk about getting started with microcontrollers, I'm going to point people towards the discovery book, Rusty Bits and this channel :) If anybody else is there let me know and we can meet up!
<adamgreig[m]>
great, if that's all then we'll call it done here :) thanks everyone!
<JamesMunns[m]>
As a small pre-announcement, I'm working on a tool called Poststation, aimed at making it easier to manage multiple devices, both for prototyping and as a way to make it easier to not worry about embedded comms. It's built on top of postcard-rpc, and I've been working pretty hard on it for the past month or two.
<JamesMunns[m]>
I've started sending out alpha builds to some folks. If anyone is interested in testing it out (currently RP2040 over USB is the main reference target, but I have one user on the RP2350, and any device supported by embassy-usb should work!), please feel free to DM me!
<JamesMunns[m]>
I've been hinting at it, so not a very secret project, but if you use postcard-rpc, or would like tooling that makes it easier to prototype, or build apps/GUIs for connected devices, Poststation might be for you :)
<JamesMunns[m]>
Nope, some overlap wrt features, but the goal is to have a server that can talk to any device over postcard-rpc, and provide a host side API for managing them
<JamesMunns[m]>
With the ability to do the queries from the CLI for "manual poking", as well as have an SDK/API for doing the same from within an application
<JamesMunns[m]>
It also keeps historical data persistent, so you can query information and past messages, even for offline devices.
<JamesMunns[m]>
So, sort of "reverse proxy plus message broker plus service discovery" all in one :)
<therealprof[m]>
Nice. 😄
<JamesMunns[m]>
If your device speaks postcard-rpc, it can automatically discover the full protocol for you, allowing you to "plug and play" devices, even if you don't have the protocol crate handy. Which means you can use super-compact postcard binary data to the device, but get "full fat" JSON messages for easier app dev on the PC side :)
Voyager2Spirit has joined #rust-embedded
Voyager2Spirit has quit [Remote host closed the connection]
Voyager2Spirit has joined #rust-embedded
Voyager2Spirit has quit [Max SendQ exceeded]
Voyager2Spirit has joined #rust-embedded
Voyager2Spirit has quit [Max SendQ exceeded]
Voyager2Spirit has joined #rust-embedded
Voyager2Spirit has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
NebulaForge has joined #rust-embedded
NebulaForge has quit [Max SendQ exceeded]
igiona[m] has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
Alistair[m]1 has quit [Quit: Idle timeout reached: 172800s]