ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<JamesMunns[m]> I actually really think that serialization is a better choice for logging
<JamesMunns[m]> The issue is it doesn't help with panic bloat
jcroisant has quit [Quit: Connection closed for inactivity]
teebuthot[m] has joined #rust-embedded
teebuthot[m] has left #rust-embedded [#rust-embedded]
jcroisant has joined #rust-embedded
<i509vcb[m]> Maybe a little off topic, but the device in question will use Rust firmware so I guess it is lol.
<i509vcb[m]> I am working on (another) debug probe and I've been battling in my head whether I should also add a connector as an alternative for the standard 10-pin cortex connector. But I do want a UART available so another connector would be needed
<i509vcb[m]> rusty-probe does use pads you solder stuff onto, but I'd like something a little less DIYish for that
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
ksvr[m] has joined #rust-embedded
<ksvr[m]> Is there something specific to do, apart from not using std, to do a no std crate?
ian_rees[m] has joined #rust-embedded
<ian_rees[m]> I think just add #![no_std] at the top of your lib.rs
<ian_rees[m]> * I think just add #![no_std] at the top of your lib.rs or main.rs
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
<ian_rees[m]> <i509vcb[m]> Maybe a little off topic, but the device in question will use Rust firmware so I guess it is lol....
<ian_rees[m]> I'm a fan of ye olde 2 row 0.1" headers - can't say I've often felt like a debug probe would really be much better if it were just smaller :)
sroemer has quit [Quit: WeeChat 4.5.2]
MaartendeVries[m has joined #rust-embedded
<MaartendeVries[m> on the topic of defmt: it doesn't typecheck logs that have been disabled by DEFMT_LOG. This has bitten me a couple of times, so I figured I'd fix it: https://github.com/knurling-rs/defmt/pull/974 :)
<MaartendeVries[m> that PR even caught an error in the book section about hints because it wasn't typechecked by CI 😁
doodspav[m] has joined #rust-embedded
<doodspav[m]> Maarten is your name common or am I familiar with your work from somewhere?
<MaartendeVries[m> eh, could be either :p
<MaartendeVries[m> my name is maybe the most common Dutch name, but I haven't seen another one it in the Rust ecosystem yet myself
<MaartendeVries[m> I go by de-vri-es on github and crates.io
<doodspav[m]> You don’t do automotive stuff do you?
<MaartendeVries[m> not particularly, although I use CAN relatively often ^_^
<doodspav[m]> I didn’t know there was a use case for CAN outside of automotive?
<MaartendeVries[m> I work on some automative adjacent stuff, and they adopted CAN probably because of that
<MaartendeVries[m> and some robotic platforms use it, probably for the same reason
<diondokter[m]> Pretty sure there's CAN in industry as well
<MaartendeVries[m> oh yeah, the whole CANopen ecosystem
dngrs[m] has joined #rust-embedded
<dngrs[m]> <MaartendeVries[m> on the topic of defmt: it doesn't typecheck logs that have been disabled by DEFMT_LOG. This has bitten me a couple of times, so I figured I'd fix it: https://github.com/knurling-rs/defmt/pull/974 :)
<dngrs[m]> Great stuff!
LeandroMarceddu[ has joined #rust-embedded
<LeandroMarceddu[> <doodspav[m]> I didn’t know there was a use case for CAN outside of automotive?
<LeandroMarceddu[> It's quite often used in the 3D printer world as well
<TomB[m]> At this point I wonder if CAN won’t go away in favor of 2 wire eth
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]> TIL about setting workspace = true for dependencies in Cargo.toml, and this seems really useful.
<MaartendeVries[m> <TomB[m]> At this point I wonder if CAN won’t go away in favor of 2 wire eth
<MaartendeVries[m> not any time soon, I think, there's still plenty of new projects using it
wassasin[m] has joined #rust-embedded
<wassasin[m]> The cost of 2 wire eth is still very high
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
fard[m] has joined #rust-embedded
<dirbaio[m]> my recommendation would be to not use wasm :P
<wassasin[m]> I wanted to try it out for fun on embedded too, but it never bubbled to the top of my priority queue
<wassasin[m]> I believe the makepad folks have tried to make a minimal wasm runtime without tail recursion
<wassasin[m]> * I believe the makepad folks have tried to make a minimal wasm runtime with only tail recursion
<wassasin[m]> <wassasin[m]> The cost of 2 wire eth is still very high
<wassasin[m]> Oh I now see a RMII transceiver on Mouser for ~1.72EUR, that's OK https://eu.mouser.com/ProductDetail/NXP-Semiconductors/TJA1101BHN-0Z
<JamesMunns[m]> <wassasin[m]> The cost of 2 wire eth is still very high
<JamesMunns[m]> mouser and digikey are dumb and you have to use their share links
<JamesMunns[m]> <wassasin[m]> The cost of 2 wire eth is still very high
<JamesMunns[m]> https://mou.sr/4nQI0ai
<wassasin[m]> For cars a 15m length is OK, but for industrial you want more like 500m. The 10BASE-T1L transceivers are still quite new
okhsunrog[m] has joined #rust-embedded
<okhsunrog[m]> <dirbaio[m]> my recommendation would be to not use wasm :P
<okhsunrog[m]> I think running wasm on MCU is better, then running lisp or js on mcu :D
<okhsunrog[m]> s/then/than/
<dirbaio[m]> yeah
<dirbaio[m]> but why wasm
<dirbaio[m]> any kind of VM or interpreted language is always going to be bloated
<JamesMunns[m]> dirbaio[m]: because Rust is still bad at generating PIC code?
<diondokter[m]> JamesMunns[m]: Yep, that's why I investigated WASM on MCU once too
<JamesMunns[m]> (is PIC code on ESP32 supported, or is that just a cortex-m defect?)
<dirbaio[m]> you don't need PIC if you're dynamically loading one app for one screen.
<i509vcb[m]> My answer to this problem is to banish user code to core 1 on MCXN
<JamesMunns[m]> yeah, I get it, there are a lot of other ways to make things work without an interpreted lang, I have my own hangups on wasm (and scripting languages in general), but hot-loadable code is a thing I wish we had a better story for, even if it is native code. I know it's *possible*, I've done it, it's not particularly pleasant or repeatable
<JamesMunns[m]> the best story today IMO is "pick a fixed RAM location, use a custom linker script, have the OS/host memcpy to the fixed ram location, execute"
<JamesMunns[m]> which is obnoxious because you need to burn RAM for the .text section, instead of pointing it at some arbitrary XIP location in an ext 8M flash, for example
<JamesMunns[m]> (if your XIP periph doesn't support remapping, and if it does, if that doesn't mess with your kernel/host)
<JamesMunns[m]> and even then it's like "just define your own ABI, duh", which you CAN do! It's basically what old mnemos and current neotron does
<JamesMunns[m]> it's just not like... easy to recommend to someone who isn't down for that kind of adventure lol
<JamesMunns[m]> Anyway, if nothing else, I'm saying I totally understand the *appeal* of "just get an interpreter running" as a perceivable goal, even if we think the net outcome is going to be subpar.
<wassasin[m]> Some harness to run a piece of code both on device and in qemu on the host would already be nice
<dirbaio[m]> you can stil use XIP if you choose a fixed address in flash
<dirbaio[m]> it doesn't have to beram
<dirbaio[m]> s/beram/be ram/
<JamesMunns[m]> yeah, it means swapping means overwriting the location, which is fine for "swap once a day", not so much if you want to have different "apps"
<dirbaio[m]> yeah..
thejpster[m] has joined #rust-embedded
<thejpster[m]> hi five on https://github.com/rust-embedded/cortex-ar/pull/44 please. Beta/nightly have changed the formatting of panics, which broke my QEMU based testing.
<thejpster[m]> this is largely how Neotron OS works, except the ABI is a struct full of function pointers
<JamesMunns[m]> yeah, in ergot/mnemos, you'd instead get a ptr to a pair of bbq2 ringbuffers
<thejpster[m]> It would be interesting to compare performance
<thejpster[m]> I heard that Hubris suffers somewhat from memcpy's into and out of kernel space as part of the enforced task isolation. I imagine serialisation is worse. But maybe it's fine.
<JamesMunns[m]> yeah, postcard is *pretty* quick, but memcpy is memcpy. ergot DOES allow for zerocopy ser/de in some cases, especially for large `&[u8]` and `&str` buffers, but I am fairly certain mnemos proper will need to grow some kind of out-of-band Box/Mutex mechanism that allows you to "send ownership" of mapped memory between the kernel and userspace. My reference example is something like a 720p framebuffer: you don't want to be
<JamesMunns[m]> memcpying that to the kernel on every frame, you probably want a pool of 2-3 buffers that you ping-pong ownership of back and forth with the kernel
<JamesMunns[m]> I'm betting for a *remarkable* amount of things you can get away with "true" message passing, but I think there's room for clever "heap like" collections where you can just send a ptr as a message, and have it be enforced by an MMU/MPU.
<JamesMunns[m]> (we're getting firmly into "long term research questions I have about mnemos" tho)
<JamesMunns[m]> that being said: now that I have ergot, I think that might button up the 2.5y diversion of "how to make a good strongly typed network stack", so I might actually get back to mnemos now that THAT yak is finished being shaved
<JamesMunns[m]> (turns out when you decide to make a message passing operating system, you need a good message passing system, and it turns out it took me 2.5y to figure out how to do that in a way that felt acceptable to me.
<JamesMunns[m]> * to me.)
Mihael[m] has joined #rust-embedded
<Mihael[m]> Cloning a channels' sender is practically free right
<JamesMunns[m]> depends on what library/channel you are talking about. In most statically allocated MPSC channels, yes
xnor has quit [Ping timeout: 252 seconds]
xnor has joined #rust-embedded
chrysn[m] has joined #rust-embedded
<chrysn[m]> I'm just on mobile and thus without GitHub access, but could someone add "embedded-cal is soliciting wishlist items for its interface design at https://github.com/lake-rs/embedded-cal/issues/1" to the list?
<chrysn[m]> The audience of this meeting is precisely whom I'd hope to get input from.
<chrysn[m]> IOW: "How have you always wanted to talk to the crypto accelerators built into your chips?"
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> hi @room, meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/849, please add anything you'd like to discuss or announce and we'll start in a few minutes
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]> cargo with multi-target projects has always been a bit of a pain point but i don’t really have a coherent way to lay out just what exactly is wrong with it
<GuineaWheek[m]> i’m surprised the wasm people haven’t already annoyed the cargo people into making it better
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> I think I would like the target and target-cpu to be able to depend on feature flags. Then I could build for a platform rather than just a generic cpu.
<adamgreig[m]> ideally you'd then perhaps get better control over which cpu flags you want to enable too...
<bartmassey[m]> Exactly
<adamgreig[m]> ok, let's begin! no announcements from me, any from anyone else?
<adamgreig[m]> ah, I'll repeat chrysn's call for wishlist items for embedded-cal here: https://github.com/lake-rs/embedded-cal/issues/1
<JamesMunns[m]> If anyone is using bbq2, make sure to update to the latest version to get some soundness fixes, also let me know so I can ask how bbq2 is going :D
<GuineaWheek[m]> workspaces are also extremely underbaked for multiplat targets
<adamgreig[m]> onto the agenda items; for cortex-m i think the plan from last week to do a backport 0.7 release with as many non-breaking changes as possible is still good, just either someone else needs to put that together or I will in proably august
<adamgreig[m]> James Munns: we've had some discussion about making armv8r tier 2 before too, I had promised to get a stabilisation pr written just before i got torpedoed by work, I think it just needs someone to propose it formally and update the target docs
<bartmassey[m]> What are exactly the breaking changes that are currently sitting in the cortex-m repo? Is there a list somewhere?
newam[m] has joined #rust-embedded
<newam[m]> bartmassey[m]: The list is just the git commit history / merged pull-requests.
<adamgreig[m]> would have to check carefully when cherry-picking the commits for the new features and fixes
<adamgreig[m]> but in principle it's two very small things
<adamgreig[m]> worth noting that some of those changes have already been backported - the first breaking change went in when 0.7.4 was out, and 0.7.5, 0.7.6, and 0.7.7 have been released since then...
Foxyloxy has quit [Read error: Connection reset by peer]
<adamgreig[m]> I think it might be logistically simplest to make a commit to master that reverts the breaking changes and bumps the version to 0.7.8 and keep going from there, rather than continue in the 0.7.x branch with more backports, tbh
<adamgreig[m]> since we've also restructured the repo somewhat
<adamgreig[m]> but will take even more careful checking that the result is non-breaking
<bartmassey[m]> Just wondering how breaking the changes will be. Folks seem concerned about big ecosystem updates when they happen. Is this a likely outcome?
<therealprof[m]> AFAIR they're now world shattering breaking like we had before.
<adamgreig[m]> the breakage happens because of a version number change, irregardless of the actual contents of the changes
<adamgreig[m]> I think practically they would be fairly breaking if we do away with the owned singletons yes
<adamgreig[m]> that's why the main focus would be on ensuring that future (breaking) releases can be made without the ecosystem disaster
<adamgreig[m]> I'm not going to have time to deal with any of the remaining triage issues from last week, but they mostly concern changes to cortex-m as well
<JamesMunns[m]> Do we want to see if we can find some of the other cortex-m maintainers to lead the next 0.7 release, to take some load off of you Adam?
<JamesMunns[m]> Since 0.7.x seems lower stakes than taking on the 0.8+ release
<JamesMunns[m]> and/or: try to make sure you have a new/existing buddy for this release to make sure someone else is spun up, if nobody is available to lead this one?
<thejpster[m]> (It’s now team arm rather than team cortex-m)
<thejpster[m]> Let me go fire up the big computer and look at the repo
<adamgreig[m]> i wouldn't mind, if anyone is interested! it's still quite an intimidating release but yea not as bad for 0.7.8
<adamgreig[m]> in theory I think it's just a case of undoing those two minor breaking changes that are in master, changing the version number to 0.7.8, and releasing it, but there's just a bunch of checking to do in the middle
<adamgreig[m]> no semver hack at least
<thejpster[m]> cargo semver-checks is very sad
<adamgreig[m]> is that master to published 0.7.4?
<thejpster[m]> yeah
<adamgreig[m]> how about master to 0.7.7?
<adamgreig[m]> or 0.7.4 to 0.7.7 🙊
<adamgreig[m]> is semver-checks running with a cortex-m target?
<thejpster[m]> 0.7.x branch has one minor fail against 0.7.4 - we marked a function as deprecated
<bartmassey[m]> Looks like mostly module motion? What motivated all the moves? Can they be put off?
<adamgreig[m]> a lot of things it says are missing are still present but cfg-gated to cortex-m
<adamgreig[m]> I suspect it's running for a PC target which in 0.7.4 emitted dummy functions for all asm
<bartmassey[m]> Ah.
<thejpster[m]> oh, ok. Let me try again.
<thejpster[m]> What is the 0.7.x branch?
<adamgreig[m]> that doesn't look too bad otherwise
<adamgreig[m]> 0.7.x branch is the branch that 0.7 releases are made from, so its head is the 0.7.7 release
<thejpster[m]> ok
<thejpster[m]> so master should be "0.8-pre"
<thejpster[m]> to avoid confusion
<thejpster[m]> because it's really not 0.7.4 any more, Dorothy
<adamgreig[m]> correct
<adamgreig[m]> historically we have bumped version numbers only at release time, not pre-empting a release
<adamgreig[m]> but it does leave us in this confusing situation
<thejpster[m]> mmm, cargo semver-checks is trying to enable the std feature
<thejpster[m]> and it's trying to build a dylib 🙃
<adamgreig[m]> I can see that giving slightly confused results
<thejpster[m]> is the 0.7.x branch from before the cortex-m-rt merge?
<adamgreig[m]> yea, I believe so
<thejpster[m]> aye karumba
<JamesMunns[m]> thejpster[m]: there's a couple CLI flags to get it to not try to automatically guess flags
<adamgreig[m]> nothing's ever easy for embedded huh :P
<adamgreig[m]> ok, I have to run for now, thanks for looking into semver-checks though, if we can work out the small set of changes to revert I do think a good 0.7.8 release with some nice improvements like always-inline-asm would be not so hard to do and quite useful
<JamesMunns[m]> Thank you @adamgreig !
<thejpster[m]> because there are a lot of changes. Like now we have eh0 and eh1 features, and before we didn't. And I'm pretty sure taking away trait impls is a breaking change.
<thejpster[m]> also I'm going to have to ping predrag and work out how to run cargo-semver-checks on a no_std crate that cannot be build as a dylib
<thejpster[m]> (or whatever the issue is here)
<thejpster[m]> https://github.com/rust-embedded/cortex-m/pull/605 - deletes the cortex-m crate on master and replaces it with a copy from the 0.7.x branch. We will have to re-apply patches on top of this, but no breaking changes this time please.
<thejpster[m]> Required quite a bit of fiddling to get the old objects to assemble bit-for-bit as they did before, despite being in a sub-folder now.
<thejpster[m]> > error: variables can be used directly in the `format!` string
<thejpster[m]> F U clippy. I hate this lint.
<thejpster[m]> (also, they can't do this in the MSRV)
<dngrs[m]> Would it make sense to augment defmt macros with an allow(this lint) directive?
<thejpster[m]> doesn't help here - it's a format! in a build script (or maybe the xtask)
<dngrs[m]> well, crap.
<thejpster[m]> I have pinned clippy to use the version from the MSRV. It's the only solution I can see.
<thejpster[m]> no new lints = peaceful life for me
<dngrs[m]> Maybe something for the cargo wishlist?
<thejpster[m]> ok, too many hit points. Tapping out for now.
<thejpster[m]> > error: the `cargo::` syntax for build script output instructions was added in Rust 1.77.0, but the minimum supported Rust version of `cortex-m v0.7.7 (/home/jonathan/Documents/github/rust-embedded/cortex-m-master/cortex-m)` is 1.61.
<thejpster[m]> FML
Ralph[m] has joined #rust-embedded
<Ralph[m]> <thejpster[m]> I have pinned clippy to use the version from the MSRV. It's the only solution I can see.... (full message at <https://catircservices.org/_irc/v1/media/download/AQMdteJMTA3yIjIXe6ALBSE7PODcldX_Ciao3X_ZjRTRjiquzdNw_k0_LJPk0XmjC9pyWCoEhU2H9ApHNyHLQru_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9GeVlwQUx5YlJrUENaSGVzc0hCUkhQWXQ>)
<thejpster[m]> apparently not
<thejpster[m]> I think it's green now? Either way, I'm done with it.
<thejpster[m]> No, it's not. We have clippy lints that our MSRV clippy doesn't understand.
<adamgreig[m]> thejpster: you reckon this way is easier than keeping master branch's cortex-m and reverting the breaking changes? there's a bunch of things we definitely want to keep like the inline-asm changes that are quite big iirc
<adamgreig[m]> well, we can see how easily they apply. at least this way it's clearly not breaking!
bozgi[m] has joined #rust-embedded
<bozgi[m]> hi! i am new to embedded, i've for a long time wanted to make a keyboard. I managed to design it and get it manufactured. As a chip I chose Seeed Studio XIAO nRF52840. I can't manage to get it to register a keypress, and even to get a... (full message at