<dcz[m]>
is there an example of RTIC running on the GD32VF103?
<dcz[m]>
or embassy, for that matter
jasperw- has quit [Server closed connection]
jasperw has joined #rust-embedded
haobogu[m] has joined #rust-embedded
<haobogu[m]>
<Lumpio[m]> Well anyways I'm happy with adding a few lines to my RMK firmware to implement the "standard" RP2040 method - I don't really need RPC for anything else
<haobogu[m]>
There a feature "rp2040_bl" in RMK and after enabling the feature, you can use `Bootloader` key in vial to jump to bootloader
<Lumpio[m]>
Neat, so there's a USB command for it already somewhere in there. Could probably do the same thing feom the command line! I'll look into it once I get my crazy PCBs.
<haobogu[m]>
Ah, that's possible if you can simulate the vial protocol in command line, not very easy tho
RobWells[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHorden has quit [Excess Flood]
AdamHorden has joined #rust-embedded
<chrysn[m]>
<lulf[m]> chrysn: using both here https://github.com/lulf/watchful (but an older rev, so could be there's a regression)
<chrysn[m]>
Great, that did indeed teach me that I have to run client.task() in parallel to my client operations, or they'll just stall. Should have known…
<lulf[m]>
chrysn[m]: Ah, yes. It annoys me a bit to have that extra task there, but haven't really thought about any alternatives. Not well documented either :(. Great that you got it running!
<chrysn[m]>
I have a very similar problem on a different stack too; my best guess as to how to make this error less likely is for a client operation to debug-level (off-by-default) show a note that there is no service task running (yet?), but ideally that'd be after some timeout, and that makes it more complex code than I'm willing to run conditionally on debug_asserts being active.
<chrysn[m]>
(Also, I'm still on trouble 0.1 b/c of other dependencies we're just updating; once I'm on latest/main, I may have actual suggestions and start working with it properly)
edm has quit [Server closed connection]
edm has joined #rust-embedded
NishanthMenon has quit [Server closed connection]
NishanthMenon has joined #rust-embedded
rom4ik has quit [Server closed connection]
rom4ik has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]>
Won’t be coming tonight or next week - doing a late shift for a client
MustafaKK[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<DavidBrown[m]>
To me: "Redesign with clarity and modularity, taking advantage of Rust’s rich type system and error handling." is an exciting part about it. It isn't just "rewrite in rust", but trying to take advantage of being able to have a better design.
glitchy has quit [Remote host closed the connection]
<adamgreig[m]>
so it seems like you could maybe use ergot instead of poststation or postcard-rpc?
<JamesMunns[m]>
I've stolen a lot of the tricks from postcard-rpc and poststation, but sort of taking a bit of a side step to approach it in a more socket-like manner
<adamgreig[m]>
yep i see, nice
<adamgreig[m]>
ok, I think let's talk about heapless 0.9.1 first if you're around sgued, then get to the build-std thing second
<JamesMunns[m]>
yep! today, postcard-rpc is much more stable, but it's kind of a local maximum (strictly point to point, client/server model), where ergot I hope to be a bit more flexible in a lot of ways that people have asked if p-rpc could support (and I could never find a good way to handle)
sgued[m] has joined #rust-embedded
<sgued[m]>
adamgreig[m]: Yep
<sgued[m]>
Heapless 0.9.1 is ready for release, the breaking changes I wanted included are merged, [@zeenix:gnome.org](https://matrix.to/#/@zeenix:gnome.org) and I can release it
zeenix[m] has joined #rust-embedded
<zeenix[m]>
Assuming we have the rights to push tags directly and to crates.io 😊
<adamgreig[m]>
the build-std team have an RFC up at https://github.com/davidtwco/rfcs/pull/2, for now they've asked wg members to review and give feedback on how it would be useful or otherwise for embedded use
<adamgreig[m]>
probably best if we can gather thoughts from everyone here and/or next week and try to summarise them, and in particular please don't post on the RFC itself if you're not a wg member (at this time)
ello has joined #rust-embedded
<adamgreig[m]>
there's not been a ton of time to read through so I think we'll probably want to revisit it next week anyway, but did anyone have points they wanted to discuss about it today?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
It's too huge and arcane for me. I'll never have time to read and understand it. Just reading the background chapter took me an hour.
<therealprof[m]>
Super exciting.
<sgued[m]>
We use build-std at Nitrokey for some builds
<rmsyn[m]>
<adamgreig[m]> probably best if we can gather thoughts from everyone here and/or next week and try to summarise them, and in particular please don't post on the RFC itself if you're not a wg member (at this time)
<rmsyn[m]>
is this for r-e wg members regardless of team?
<adamgreig[m]>
ok, great! I encourage people to give it a look over, it's got a lot of potential to be really useful for embedded projects so it would be good to work out how we'd like it to look while it's still being designed
<adamgreig[m]>
definitely one of those long-standing "gosh it would be nice to have this stable" things
<adamgreig[m]>
any other topics people would like to discuss today?
<sgued[m]>
<sgued[m]> Heapless 0.9.1 is ready for release, the breaking changes I wanted included are merged, [@zeenix:gnome.org](https://matrix.to/#/@zeenix:gnome.org) and I can release it
<sgued[m]>
One thing I forgot to mention, I've written a tiny announcement for the release, that explains the two new major features (View types and LenType).
<sgued[m]>
Does the WG has a place where it would make sense to publish it? Else I'd just put it on ly personal blog.
<sgued[m]>
> <@eluioda:matrix.org> Heapless 0.9.1 is ready for release, the breaking changes I wanted included are merged, [@zeenix:gnome.org](https://matrix.to/#/@zeenix:gnome.org) and I can release it
<sgued[m]>
* One thing I forgot to mention, I'm writting a tiny announcement for the release, explaining the two new major features (View types and LenType).
<sgued[m]>
Does the WG has a place where it would make sense to publish it? Else I'd just put it on ly personal blog.
<bartmassey[m]>
Ideally it would go on some blog on the WG webpage, but I don't think we have anything like that right now.
<adamgreig[m]>
so you're very welcome to open a pr to https://github.com/rust-embedded/blog adding a new post and it will update the page automatically on merge
<bartmassey[m]>
Oh, perfect!
jannic[m] has joined #rust-embedded
<jannic[m]>
I again didn't have time to do as much ticket triaging as I'd like to (why2025 and froscon were great!). Only ticket I have right now is https://github.com/rust-embedded/embedded-hal/pull/669, already had some comments and was updated a month ago and is now waiting for a review.
<adamgreig[m]>
yep, the release notes for the release are also a good spot, depends if you want more of a blog post vibe or what
<adamgreig[m]>
certainly good to link between them
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
ok, if that's all for this week then let's finish there, thanks everyone!
jfsimon has joined #rust-embedded
<cr1901>
I couldn't attend the meeting, but I _am_ working on Rust stuff lol... I'm fighting CI and tests so I can cut a release of msp430-rt
<cr1901>
(I am currently losing it seems)
fjeauntyd[m] has joined #rust-embedded
<fjeauntyd[m]>
<cr1901> I couldn't attend the meeting, but I _am_ working on Rust stuff lol... I'm fighting CI and tests so I can cut a release of msp430-rt
<fjeauntyd[m]>
don't fight the CI. Just let the total failure embrace you. Find clarity in that moment of total failure and total recall
<sgued[m]>
<adamgreig[m]> so you're very welcome to open a pr to https://github.com/rust-embedded/blog adding a new post and it will update the page automatically on merge
<sgued[m]>
It's more a blog post highlighting the main new feature that are not obvious from error messages caused by updating, so I think it has more its place threre than in the release notes.
rainingmessages has quit [Ping timeout: 252 seconds]
rainingmessages1 is now known as rainingmessages
Mathias[m] has joined #rust-embedded
<Mathias[m]>
<DavidBrown[m]> To me: "Redesign with clarity and modularity, taking advantage of Rust’s rich type system and error handling." is an exciting part about it. It isn't just "rewrite in rust", but trying to take advantage of being able to have a better design.
<Mathias[m]>
One part that seems to have been left out of the announcement is that the rust crates have a GitHub *read-only* mirrors at https://github.com/ArmFirmwareCrates (they won't accept PR, you have go through Gerrit, but I think they will look at issues).
<dav1d>
If I want to share a embassy_sync::channel::Channel on multiple threads, I would just Arc it (assuming I have std), right?
Mihael[m] has joined #rust-embedded
<Mihael[m]>
No need to arc
<Mihael[m]>
dav1d: Just share the senders / receivers?
<Mihael[m]>
They're copy and have a very small footprint
<dav1d>
Mihael[m], std::thread::spawn requires 'static, the senders/receivers borrow from the original channel, no?
<dav1d>
spsc would be enough for me, if I could split the channel into an owned receiver/sender pair
<Mihael[m]>
dav1d: Make the channel static and its senders and receivers are static lifetimes
<dav1d>
Mihael[m], okay, that could work, but not if I have a variable amount of threads
<Mihael[m]>
dav1d: Ofcourse it would, why not?
<Mihael[m]>
I assume you have one channel, multiple senders single consumer?
<dav1d>
Mihael[m], for every thread I start I need a new static
<Mihael[m]>
Why so?
<dav1d>
because every pair needs to be separate channel?
<Mihael[m]>
What's the idea / project? Describe it in a few statements
<dav1d>
probably should do it, in this case I just need 2 statics, so that works/isn't that bad
<dav1d>
Mihael[m], 1 or 2 LCD screens, I have an async executor which does all the logic, but the LCD is i2c and I can't make it async, so I wanna move the i2c logic to a separate thread (all esp idf) and send 'commands' to the LCD threads
<Mihael[m]>
Why 2 statics
<dav1d>
So each screen needs its own 'command' channel (aka 2 separate channels -> 2 separate statics)
<Mihael[m]>
Have one static channel where all receivers receive the item
<Mihael[m]>
Then discard if the item was not intended for the speicifc thread
<dav1d>
Mihael[m], that's not how the channel works, it's not broadcast
<dav1d>
Fair, thanks, just looking for a guidance what people recommend, I probably would've just Arc'd it (not necessarily considered the static), because that means I don't need to manage statics. But passing around Sender<'static>/Receiver<'static> is kinda nice
<DavidBrown[m]>
<Mathias[m]> One part that seems to have been left out of the announcement is that the rust crates have a GitHub *read-only* mirrors at https://github.com/ArmFirmwareCrates (they won't accept PR, you have go through Gerrit, but I think they will look at issues).
<DavidBrown[m]>
Most of the trustedfirmware projects work this way. Development is done in gitlab hosted repos with review happening through Gerrit. There's some history behind it, and a few of the projects just use github (OP-TEE, and mcuboot).
<DavidBrown[m]>
I just ended up deciding to commit a bunch of Cargo.lock files to the Rust on Zephyr repo, thanks to the broken cfg-if 1.0.2.
<thejpster[m]>
I sent AArch32 patches to google/arm-gic but I see the RF-A project is explictly AArch64 only. I hope they will keep the AArch32 support, because the NXP S32Z2 is AArch32 (Cortex-R52) but uses the same interrupt controller, and it seems a waste to write the driver twice.
<sypher3[m]>
So this is a general room for any Rust in an embedded use case?
<sypher3[m]>
Oh nvm, found the others.
<DavidBrown[m]>
Maybe someone here has some ideas. In one project I'm working on, the underlying OS does initialization through an array of structs that are linked in the same section. I can make this work by using #[link_section...], and #[used] to make sure the symbol ends up there. The problem is that it seems to only include this if a function in the same module (module, not crate) is referenced. And I'm kind of almost wondering if I'm
<DavidBrown[m]>
just getting lucky. The compiler seems to split the generated code into a large number of separate objects.
<DavidBrown[m]>
Put another way, codegen-units = 1 in the Cargo.toml seems to be sufficient for these to be brought in (at least if something from the crate is referenced), as it does seem to keep the crate from being split into pieces.