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
<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"
<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?"
<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?
<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]>
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
<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]>
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