05:28 <Emkanea[m]> Looking for some advice: I am writing a crate implementing basic operations to monitor a lithium ion battery (BMS safety functions). I want the monitoring to be generic to I can use different integer types (u32,i32,u16 etc.). I can specify all required trait bounds by hand (T: PartialOrd+Eq+Add etc.) or use the num-traits crate with the Num trait. Ofc I want to keep dependencies low and was a bit reluctant to add a dependency for

05:28 <Emkanea[m]> something that basic. What is your experience? Is num-traits a okish dependency? Not sure if there is consensus on something like that :)

05:39 <Emkanea[m]> Also had to notice that Num doesnt give you PartialOrd and I havent found a crate like "primitive-integers". What is the best practice to define Num + PartialOrd? Define own super trait that combines Num + PartialOrd? make all bounds explicit?

08:46 <ryan-summers[m]> <Emkanea[m]> "Looking for some advice: I am..." <- In general, I wouldn't be hesitant to include dependencies myself. My personal experience is that dependency avoidance comes from C/C++ languages, where dependency management is really painful. In rust it's quite easy and doesn't come with a ton of drawbacks imo, and I often use things like `num-traits` for simple tasks like this\

08:46 <ryan-summers[m]> There's other opinions on this subject for sure though :) In my experience, I haven't seen any downside to using external deps outside of slightly more maintenance costs later down the line

08:48 <wassasin[m]> With one of my current projects there is a strong aversion to adding dependencies because everything needs to pass cargo vet.

08:50 <sourcebox[m]> num-traits is quite common and safe to use. It doesn't blow up the dependency tree since it has only one optional dependency: libm.

08:50 <ryan-summers[m]> Yeah I'd say this is largely driven by your project requirements (i.e. do you need supply chain security, cyber security requirements, etc.), some of which will be driven by the application field or your orgs policies

09:06 <JamesMunns[m]> General reminder, if you DO enjoy using embedded rust, and have had a good experience, please write articles, give conf talks, do podcast chats about it!

09:06 <JamesMunns[m]> Context: https://bsky.app/profile/jamesmunns.com/post/3lsxthtaobc2n

09:06 <JamesMunns[m]> If folks who ARE familiar with embedded rust don't write articles, folks who aren't will.

09:09 <JamesMunns[m]> This is not to say "don't write about things that aren't great", there are still things to improve for sure! But it's a shame to have folks who are not active users write the narrative about what the experience using Rust is like.

10:56 <Emkanea[m]> Thanks for the feedback. I guess I use num-traits and extend it with copy + PartialOrd in my own "PrimitiveInteger" trait. Or is there something similiar already as a dependency that somebody knows of?

11:20 <thejpster[m]> Good news! There's a whole Rust Embedded conference where people talk about how they are getting on with writing Embedded Rust for industrial applications. Please come and watch the talks, and if you can't please watch the talks on catch-up and toot/skeet/blog about the talks too.

12:00 <Ralph[m]> interesting read on BLE security (some smartwatch got hacked by a security researcher due to poor implementation): https://blog.syss.com/posts/bluetooth-analysis-coros-pace-3/

12:00 <Ralph[m]> i only skimmed the blog post but it seems to range from "didn't use secure feature of BLE" (e.g. requiring pairing & bonding) to NULL pointer derefs & out-of-bound reads.

12:00 <Ralph[m]> at least for the latter you could claim that they can't happen with safe rust 🙂

12:16 <sirhcel[m]> <JamesMunns[m]> "General reminder, if you DO..." <- > <@jamesmunns:beeper.com> General reminder, if you DO enjoy using embedded rust, and have had a good experience, please write articles, give conf talks, do podcast chats about it!... (full message at

12:16 <sirhcel[m]> <https://catircservices.org/_irc/v1/media/download/Ac6-E_Lv5fM939gOP8LTG5S9ER0PvyI6o5oC5R39mUcvN3WZCyqiebc5IWCrMfxRimqBMpiUwlQ72hn7WfAaWA6_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy92VG5rY2hGZ0RUQXVJaEJqeVpUT0xUUGs>)

12:18 <sirhcel[m]> I followed rust-weeks advice to leave my comfort zone and submitted the proposal for a talk about integrating rust into bare metal c microcontroller firmware at embedded software engineering symposium in december.

12:57 <thejpster[m]> TIL that the FT232R USB to Serial chip will, by design, continue to send you up to 3 more bytes once you've raised your RTS output (its CTS input). This makes it nigh-on impossible to use with an MCU UART that only has a single byte buffer.

13:03 <JamesMunns[m]> <sirhcel[m]> "> <@jamesmunns:beeper.com..." <- You mean positive ones? Honestly: any way you can share your experience is good. What you were surprised by, what tools you used, how you did things, what helped or slowed you down along the way

13:10 <firefrommoonligh> <Emkanea[m]> "Looking for some advice: I am..." <- num_traits gets a free pass in every crate I use, embedded and non

13:10 <firefrommoonligh> This includes 128K flash/32K ram MCUs

13:11 <firefrommoonligh> Hard to find a project where I don't want something it provides, e.g. trig, rounding, abs

13:12 <firefrommoonligh> Also note that num_traits' only dependency in these cases is libm, which it needs. When evaluating if bringing in a dep is worth it, this is one of the things I look for; that it's not bringing in a tree of its own

13:13 <firefrommoonligh> * Also note that num_traits' only dependency in these cases is libm, which it needs. When evaluating if bringing in a dep is worth it, this is one of the things I look for; that it's not bringing in a tree of its own. (edit: As SourceBox said)

13:18 <firefrommoonligh> s/crate/firmware/, s/use, embedded and non/write./

13:27 <sourcebox[m]> I think beside of the security aspects of Rust, which are obvious, a big plus is the tooling. That's really underestimated and probably not even known to most C developers.

13:29 <sourcebox[m]> I have to work on an ESP32 project in C/C++ right now and put a good amount of work to setup VS Code with clangd to get it near to the experience of RA.

13:30 <sourcebox[m]> And still it's not even there because clangd shows other warnings/errors than the xtensa gcc.

13:31 <JamesMunns[m]> That sounds like a good thing to write about!

13:32 <sourcebox[m]> I mean, with Rust I just fire up VS Code or Zed or whatever editor with RA support (e.g.Emacs) and shit just works without any hassle.

13:34 <firefrommoonligh> Concur. One if it's strongest points. E.g. how easy it is to compile/flash etc

13:36 <sourcebox[m]> And then we have tools like probe-rs or espflash. Thing is that even someone that I collaborate with at this project uses espflash when doing his C stuff.

13:37 <sourcebox[m]> I would say that Rust allows to develop these tools much quicker than anything else.

13:41 <sourcebox[m]> I remember when I first tried to get RTT running with OpenOCD. It's so much easier with probe-rs now.

13:43 <thejpster[m]> <thejpster[m]> "TIL that the FT232R USB to..." <- production_line.gif: I guess we're doing DMA now

13:56 <Ralph[m]> i was looking for a paper comparing rust for firmware development against other (established) programming languages (i want (need?) something to cite for my "rust is better!" statement in my thesis to argue... (full message at <https://catircservices.org/_irc/v1/media/download/AcR6cHgOHnZXitmqcgEDQ0CJYirhLFpaAa9rurd_mQGAxk0k3hyrmDRLWzHX5LBRxEiRv7nEpFyEgA1ZDwcRqm2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9aemZGTUZaeEpMWENWbVFXVmRQRHFKV3Y>)

13:56 <Ralph[m]> maybe also of interest: i also found this paper for a comparison of different frameworks & RTOS in rust: https://www.mdpi.com/1424-8220/24/17/5818

13:56 <Ralph[m]> (unless i missed this: i think it'd be cool if the authors of such papers would be present in this room and also announce when they publish their papers!)

14:24 <sourcebox[m]> Btw. maybe it's interesting to know how much low-level code a project uses overall. In my cases it's often only a small amount of the whole codebase, the largest part is the business logic. And that is where Rust really shines and speeds up development.

14:29 <sourcebox[m]> It now allows me things like running a simulation of the device on the desktop or even in the browser using WASM. And it's relatively easy to set these things up compared to C++ (which I already did about 10y ago with a lot of pain).

14:31 <Ralph[m]> sourcebox[m]: now that'd be a cool story to read/hear/see a blog post (or paper or talk) about!

14:32 <sourcebox[m]> Problem is, that I can't really talk about that right now.

14:32 <sourcebox[m]> Maybe later on when the project is in production.

14:34 <sourcebox[m]> I think firefrommoonlight did already something with egui, which I'm also using for the user interface.

14:34 <sourcebox[m]> So you compile egui to WASM.

14:35 <firefrommoonligh> So, you will find that a big obstacle to that OSS stuff is only one part of the picture. For example, my main embedded project RN is for work, and it's proprietary/on a sensitive topic

14:35 <firefrommoonligh> Correct sourcebox : I use EGUI for many non-embedded projects. PC applications

14:36 <firefrommoonligh> Actually... one of those applications is making PC applications that interacts with embedded devices on USB (Configure them ,view their status or data), so there is an overlap there.

14:36 <firefrommoonligh> I think Slint is doing some good stuff for actual Embedded GUI, but I haven't used it

14:37 <sourcebox[m]> I thought of using egui for the simulator.

14:38 <firefrommoonligh> <sourcebox[m]> "Btw. maybe it's interesting to..." <- I tend to (And I think this is common) silo the low-level code into libs. Whether that's a lib I pulled off crates, or wrote myself, the actual applications and firmwares will be mostly *business logic*.

14:38 <sourcebox[m]> If your business logic is separate, then you can just use it on different targets.

14:40 <sourcebox[m]> In my case it's mainly dsp code, but the simply fact that it gives the same results on every platform without UB is a big thing.

14:40 <sourcebox[m]> s/simply/simple/

14:40 <firefrommoonligh> Yea; code sharing between embedded/non-embedded is nice

14:41 <firefrommoonligh> And doing it in a portable way can require careful design. E.g. if you don't want to duplicate a struct between the PC and embedded side, you have to set up the common lib in a way so you won't have problems like the PC program trying to pull in defmt, a HAL etc.

14:43 <sourcebox[m]> Yes, it requires to put in some thoughts. But in comparison to do this with CMake etc. it's way easier.

15:28 <Ralph[m]> is there somewhere a list of embedded targets which are (well) supported by rust? i can't find one either on https://github.com/rust-embedded/awesome-embedded-rust or the rust book.... (full message at <https://catircservices.org/_irc/v1/media/download/AWQDtsFDq91VioF-tzbJ68YKnT6AHH6zGcFpIDFSQ4Sc5tR_3uoKDDcHRk2TyNtVNvHdp771PrdFfb9pEV-J5GG_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9aa1B3d09jRHFIamZBTWFqUlFKdU1QY3M>)

15:42 <okhsunrog[m]> <Ralph[m]> "is there somewhere a list of..." <- That's cortex-m, risc-v and xtensa (espressif chips), nothing else has this level of support

15:44 <Ralph[m]> okhsunrog[m]: AFAIK cortex-a & cortex-r now also have support ([cortex-ar](https://github.com/rust-embedded/cortex-ar); nb: the short description shown on GitHub on the right only mentions Cortex-R, i guess that needs updating?).

15:44 <Ralph[m]> i'm (sort-of) aware of this list. i'm just not aware of anywhere where this is written down and linked to.

15:44 <JamesMunns[m]> msp430 has reasonable support :D

15:45 <Ralph[m]> ah, and that one. see: there are more 🙂

15:45 <Ralph[m]> what i'm looking for is a place where they're all linked to. do we have something like this? if not: could we have something like this and if yes: where? (awesome e-r? book?)

15:45 <Ralph[m]> i'll happily provide a PR with the ones i'm aware of (which, as it seems, is most likely an incomplete list - but it'd be a start)

15:46 <JamesMunns[m]> is there: if you can't find it, probably not

15:46 <JamesMunns[m]> where: idk open to suggestions

15:46 <JamesMunns[m]> could we: definitely

15:47 <sourcebox[m]> Is there some kind of landing page for anyone interested in embedded Rust?

15:47 <Ralph[m]> JamesMunns[m]: i never claimed that i'm good at searching 😉

15:47 <Ralph[m]> or maybe it's just well hidden and needs to be linked from somewhere more visible

15:47 <JamesMunns[m]> sourcebox[m]: I think that would be a very good thing to have!

15:48 <Ralph[m]> sourcebox[m]: pick your choice:... (full message at <https://catircservices.org/_irc/v1/media/download/AV4gzjCKvx5eWjEc3YKjUvXsfSB0ijKPHNDB-DUk7U2TnuuO8gLFAyH0PBC_5PErLKy5E2hApdmyS84NDkFVDei_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9GWlNLVmZwRVNya0lreHdBRmNWb2taSHc>)

15:49 <sourcebox[m]> I could imagine that this page offers some entry points for product developers, hardware manufacturers and library authors.

15:50 <JamesMunns[m]> Please don't wait for approval to go write that:

15:50 <JamesMunns[m]> * if you write it, we'll find a home for it

15:50 <JamesMunns[m]> * if you write part of it, others can help improve/finish it

15:53 <sourcebox[m]> Are the sources of https://rust-embedded.org/ in some repo?

15:53 <JamesMunns[m]> not sure!

15:54 <sourcebox[m]> Maybe this? https://github.com/rust-embedded/rust-embedded-www

15:55 <JamesMunns[m]> looks right!

15:56 <sourcebox[m]> I have no real idea how to start that, but maybe a tool like Zola can be useful to maintain it.

15:57 <JamesMunns[m]> I'd worry about content over format probably! Just making some markdown text to start can probably be a reasonable place

16:03 <sourcebox[m]> That's correct but a little bit of "design" rather than these long lists would maybe attract people a bit more.

16:05 <sourcebox[m]> Btw. where do you want to collect this list?

16:06 <JamesMunns[m]> I'd say make it wherever you want (gh repo, gist, whatever), then share it here whenever you want feedback!

16:11 <sourcebox[m]> I've not worked with Gists yet. Are they suitable for that purpose or even better than a regular repo?

16:11 <JamesMunns[m]> it's just "what if instead of a repo, just a single file"

16:11 <JamesMunns[m]> it's useful for notes, not if you want to have multiple files really

16:12 <sourcebox[m]> But you can edit them in the brwoser?

16:12 <JamesMunns[m]> the owner can, yes

16:14 <sourcebox[m]> imo we need an easy way to edit this list by several people which are here in the chat so that we can update it as we talk.

16:15 <JamesMunns[m]> hackmd?

16:15 <sourcebox[m]> That needs an account, I guess.

16:17 <sourcebox[m]> Not that this is a major problem, just because I would assume most people here are already logged into GH most of the time.

16:25 <Ralph[m]> <sourcebox[m]> "I have no real idea how to start..." <- i'd suggest just using GitHub pages with some template. that way you can just use markdown files and compile it to a page. it costs nothing and is very accessible.

16:25 <Ralph[m]> though of course many other things exist which you can use as well and host with GH pages

16:28 <sourcebox[m]> The idea using Zola is because some other projects do it and it basically compiles Markdown files. Example: https://bevy.org/

16:29 <firefrommoonligh> Probe-RS question. When you get this, is there a way, e.g. in a config file, to tell it to always use the STLink?

16:29 <JamesMunns[m]> you can pass --probe with some of that info, or set that in some env var

16:30 <JamesMunns[m]> I think you need to modify your runner config, or maybe cargo r -- --probe ...

16:32 <Ralph[m]> <JamesMunns[m]> "Please don't wait for approval..." <- done: https://github.com/rust-embedded/awesome-embedded-rust/pull/489

16:32 <firefrommoonligh> Nailed it! works with the 2 dashes. Ty! This did it:

16:32 <firefrommoonligh> `cargo r --release -- --probe 0483:374e:0032002C5553500720393256`

16:34 <JamesMunns[m]> fwiw: passing `--` to cargo run passes all following args to the runner (or if you don't have a runner, to the executable to be run)

16:35 <JamesMunns[m]> so on the desktop, `cargo run -- --help` is the same as:

16:35 <JamesMunns[m]> `cargo build && ./target/debug/my_bin --help` or so

16:36 <firefrommoonligh> Nice. Learnign new things

16:49 <sirhcel[m]> <JamesMunns[m]> "You mean positive ones? Honestly..." <- No, i meant a negative example. I don‘t find the time to check what‘s wrong on the internet and the rust channels on matrix are my echo chamber and i know of the list you are compiling.

16:49 <sirhcel[m]> I have the other points on my agenda.

16:54 <sourcebox[m]> FYI, I will put some notes down locally in Obsidian first. Let's see how far I get with that.

16:55 <JamesMunns[m]> <JamesMunns[m]> "You mean positive ones? Honestly..." <- I really don't want to name and shame. I'll send it to you privately if you DM me, but:

16:55 <JamesMunns[m]> * The fix is not shaming people for articles I don't like

16:55 <JamesMunns[m]> * The fix is getting more articles that ARE helpful to folks interested in Rust out there.

17:04 <sourcebox[m]> Is there already some document directed to chip manufacturers?

17:06 <Ralph[m]> from what i can tell (from my echo chamber in this channel) using `postcard` & `postcard-rpc` is _very_ common (or even the de-facto standard?) in embedded rust (at least when communicating via USB). does anyone (James Munns?) by any chance have a link to back up this bold statement of mine?

17:06 <Ralph[m]> i couldn't find a single paper discussing it and also no post or website really talking about it, comparing it to other options. does something like this exist?

17:06 <Ralph[m]> it'd be great if someone who uses postcard / postcard-rpc in a product would do a write-up about it! (and i'm sure James wouldn't mind the ad 😀)

17:07 <Ralph[m]> sourcebox[m]: i think this is a start (there was some discussion around this lately): https://github.com/rust-embedded/embedonomicon/pull/99

17:07 <JamesMunns[m]> lots of folks use postcard, postcard-rpc is getting more common but much less common than "something custom on top of postcard"

17:08 <JamesMunns[m]> lots of people do what I did before postcard-rpc:

17:08 <JamesMunns[m]> Make one big enum going "to the mcu", make one big enum coming "from the mcu", then just do postcard with those enums in and out

17:08 <JamesMunns[m]> which is fine, but has all the edge cases that postcard-rpc tries to avoid :)

17:11 <Ralph[m]> ah, interesting that there's still that much hand-rolling!

17:11 <Ralph[m]> even something saying "postcard is used a lot" would already help 🙂

17:11 <Ralph[m]> i guess one reason to not use postcard-rpc is that it's mostly limited to using embassy-usb (i.e. anything else anyway needs hand-rolling unless someone were to upstream support for it)

17:12 <JamesMunns[m]> postcard has a lot of downloads, they aren't all embedded tho: https://crates.io/crates/postcard

17:12 <vollbrecht[m]> my not so scientific way of "is this used professionally" is to look at the crates.io download chart.

17:12 <vollbrecht[m]> Check out postcard :D

17:12 <vollbrecht[m]> and check that its used from Mo-Fr :D

17:13 <JamesMunns[m]> Ralph[m]: fwiw: all of the traits to impl your own anything are public, you could do something non-embassy-usb anywhere even if I don't merge it :p

17:13 <vollbrecht[m]> James was faster :D

17:13 <JamesMunns[m]> vollbrecht[m]: Serious Business Crate

17:13 <Ralph[m]> vollbrecht[m]: i guess that is actually a good metric 😄👍️

17:14 <Ralph[m]> JamesMunns[m]: certainly. i'm just guessing as to why postcard-rpc might be less used (besides "it wasn't around when the project got started")

17:15 <JamesMunns[m]> * it's WAY newer (like 7 years vs 1 year)

17:15 <JamesMunns[m]> * it's way more opinionated (specific to mostly embedded comms)

17:15 <JamesMunns[m]> (imo)

17:54 <dngrs[m]> <Ralph[m]> "now that'd be a cool story to..." <- I gave a talk about using WASM for embedded projects: https://www.youtube.com/watch?v=Z_8v9V2GTrg

17:54 <dngrs[m]> simulation was something I intended to mention but I ran out of time; I do have a web simulator for my mad science project [trenchcoat](https://github.com/spookyvision/trenchcoat)

17:54 <dngrs[m]> s/for/in/, s/Z_8v9V2GTrg/Z\_8v9V2GTrg/