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
tafa has quit [Quit: ZNC - https://znc.in]
sigmaris has quit [Ping timeout: 268 seconds]
sigmaris has joined #rust-embedded
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]> i'm writing a bootloader and when my bootloader starts a loaded firmware, probe-rs isn't very happy about the new firmware taking over RTT:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/obyIosWJqRHdklrsnfWSJXzm>)
Noah[m] has joined #rust-embedded
<Noah[m]> Is there a way to define a runner per binary?
<JamesMunns[m]> <Noah[m]> "Is there a way to define a..." <- I don't *think* so, runner cfg is per target or per cfg according to the docs:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zEqdoDrNMRKpUfYQoKPxhSrd>)
<JamesMunns[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> I don't *think* so, runner cfg is per target or per cfg according to the docs:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zwoPUtLPSbZtEEetPgnlMVIo>)
dragos_p[m] has joined #rust-embedded
<dragos_p[m]> Hey, does anyone have any experience with rust for the feather m0 express? I'm trying to do development for it on WSL and after flashing the usb echo example of the atsamd crate, windows doesn't recognize the device anymore.
<Noah[m]> <JamesMunns[m]> "I don't *think* so, runner cfg..." <- > <@jamesmunns:beeper.com> I don't *think* so, runner cfg is per target or per cfg according to the docs:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NtFGHNBnHjOSYNjmPoyxvbAQ>)
<JamesMunns[m]> Yeah, at that point, probably better to shell out to a small wrapper script or program
<JamesMunns[m]> not sure how much ENV context is passed to runners tho
<birdistheword99[> <GuineaWheek[m]> "i'm writing a bootloader and..." <- > <@guineawheek:matrix.org> i'm writing a bootloader and when my bootloader starts a loaded firmware, probe-rs isn't very happy about the new firmware taking over RTT:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xmGBsZcnlpTbmxaWgQhvqRUB>)
<Noah[m]> <JamesMunns[m]> "Yeah, at that point, probably..." <- yeah, I really despise scripts though :/ it's so wonky everytime we say "oh, just a small script" :D and writing a full wrapper means also cargo parsing etc :/ I think runner with some metadata from somewehere would really be best :) I will try some.
<Noah[m]> Do you know if cfg(test) works by any chance? because feature does not work.
<Noah[m]> * chance? because cfg(feature, * feature = "") does not, * not work.e
<JamesMunns[m]> No idea offhand
<Noah[m]> I will runn some tests :) Thanks a lot!
yruama_lairba[m] has quit [Quit: Idle timeout reached: 172800s]
chedra[m] has joined #rust-embedded
<chedra[m]> Hello there, are there any good resources on how to start implementing using embedded-hal? I can't find any on the github page. I'm completely new to rust embedded development and came here because I want to use an RC522 (RFID reader) with my Pi5. I found [this library](https://docs.rs/mfrc522/latest/mfrc522/) which says:... (full message at
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> <chedra[m]> "Hello there, are there any..." <- > <@chedra:matrix.org> Hello there, are there any good resources on how to start implementing using embedded-hal? I can't find any on the github page. I'm completely new to rust embedded development and came here because I want to use an RC522 (RFID reader) with my Pi5. I found [this... (full message at
<ryan-summers[m]> There might be the equivalent of linux-embedded-hal for raspberry-pis, but I´m not sure
<ryan-summers[m]> Ah, the rppal should actually implement the embedded-hal traits for you
<ryan-summers[m]> Looks like you need to enable the embedded-hal feature of rppal
<JamesMunns[m]> ryan-summers[m]: yep, rppal is pretty much that
<ryan-summers[m]> Do we actually point users to embedded-hal-bus for a SpiDevice implementation given a SpiBus? I don´t see it in the docs anywhere
<JamesMunns[m]> e
<JamesMunns[m]> If we can link it in more places, I'm for it
<ryan-summers[m]> Yeah but it isn´t even really related to sharing a bus? Or is there a default SpiDevice implementation for SpiBus?
<JamesMunns[m]> people do miss it
<chedra[m]> Okay, thanks already for the replies.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/gvNSMMgGPozLHHThUTDDvHKB>)
<ryan-summers[m]> chedra[m]: > <@chedra:matrix.org> Okay, thanks already for the replies.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rMpLdyYMMtRpPtHyoBSYyuWz>)
<chedra[m]> So I could do something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/lEzJeBHejGuKKUmBOXBnSmsk>)
<chedra[m]> * So I could do something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cQnVhXoGJwKAQkXeCLmefYYU>)
<ryan-summers[m]> But what you have likely works fine as well? I think it depends on whether or not the CS/n pin is built in to the SPI object or not
<JamesMunns[m]> <chedra[m]> "Okay, thanks already for the..." <- > <@chedra:matrix.org> Okay, thanks already for the replies.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zCuRyPCoKLQanIljmiOCVBXO>)
phycrax[m] has joined #rust-embedded
<chedra[m]> <JamesMunns[m]> "> <@chedra:matrix.org> Okay..." <- I see, thanks for the clarification.
psukys has left #rust-embedded [Textual IRC Client: www.textualapp.com]
CassieWoods[m] has joined #rust-embedded
<CassieWoods[m]> We're Sorry for this random approach... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RnBwSpbmUylBVkzMNLlauTvH>)
<CassieWoods[m]> We're Sorry for this random approach... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BOqvTFHDFlCmTZpgAORRYUTy>)
Flix[m] has joined #rust-embedded
<Flix[m]> Moderator? adamgreig
CassieWoods[m] has left #rust-embedded [#rust-embedded]
ManuelHatzl[m] has joined #rust-embedded
<ryan-summers[m]> <ManuelHatzl[m]> "Hi embedded-wg,..." <- > <@mhatzl:matrix.org> Hi embedded-wg,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/suxvvhAwXjzoRjmDSzEHJVsT>)
pandau has joined #rust-embedded
<ManuelHatzl[m]> ryan-summers[m]: yes I have. Unfortunately using probe-rs is not possible, because most Infineon chips are confidential and do not provide a debug interface.
<ManuelHatzl[m]> defmt is possible, because logging could be done over UART for example.
<ryan-summers[m]> Yeah but I assume there´s some method to interract with memory for flashing, and you could add a probe-rs adapter to support it internally? Just a thought though, thatś a real problem if theyŕe not arm/riscv
t-moe[m] has joined #rust-embedded
<t-moe[m]> Hi Manuel,
<t-moe[m]> What about creating a own test macro (similar to tokio::test), that when run on x86 does nothing special, and otherwise flashes the device, runs the test, and reports the result back? Surely this is beyond the current scope of embedded-test or defmt-test but I think this could work as as a workaround, without modifying cargo/rustc ?
<t-moe[m]> embedded-test author here.
<t-moe[m]> ah wait, you need to crosscompile. shoot.
<t-moe[m]> * crosscompile. shoot. Never mind ;)
<t-moe[m]> * to crosscompile in between. shoot., * . shoot. Never mind ;)
<ManuelHatzl[m]> <ryan-summers[m]> "Yeah but I assume there´s some..." <- Flashing is done through special instructions and during testing it is not possible to interact with the memory via a debug interface.
<ManuelHatzl[m]> but even if probe-rs could be adapted to work, the main problem with the proc-macro and harness would remain :/
<t-moe[m]> * ah wait, you need to crosscompile in between. that could be complicated but possible in theory...
<birdistheword99[> t-moe[m]: > <@t-moe:matrix.org> Hi Manuel,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qtWDJQfJTNXxSUIeWfiBeggo>)
<t-moe[m]> cargo mandates that each integration test (file) is compiled into its own binary. But you can run them one-by-one by typing "cargo test" no? Embedded-test is no different than defmt-test in that regard
pandau has quit [Quit: Client closed]
<t-moe[m]> * cargo mandates that each integration test (file) is compiled into its own binary. But you can run them one-by-one by typing "cargo test" no? Embedded-test is no different than defmt-test in that regard
<t-moe[m]> Using defmt-test / embedded-test for unit-testing seems wrong, because yes, they both emit a main symbol per `defmt::tests`/`embedded_test::tests` macro. So having multiple such files inside of src would lead to a linker error.
<birdistheword99[> Sorry, probably a badly worded question. In std rust, you can place unit tests in any of the files, like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PyHWphvwWBRUDodRYbAfdDpv>)
<ManuelHatzl[m]> <t-moe[m]> "Hi Manuel,..." <- > <@t-moe:matrix.org> Hi Manuel,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cxQcGOTZwSzyxQDWHcefZEHx>)
<birdistheword99[> <t-moe[m]> "cargo mandates that each..." <- > <@t-moe:matrix.org> cargo mandates that each integration test (file) is compiled into its own binary. But you can run them one-by-one by typing "cargo test" no? Embedded-test is no different than defmt-test in that regard
<birdistheword99[> > Using defmt-test / embedded-test for unit-testing seems wrong, because yes, they both emit a main symbol per `defmt::tests`/`embedded_test::tests` macro. So having multiple such files inside of src would lead to a linker error.
<birdistheword99[> Ah sorry, your edit answers my question, thanks!
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<t-moe[m]> <ManuelHatzl[m]> "> <@t-moe:matrix.org> Hi Manuel,..." <- > <@mhatzl:matrix.org> you mean a custom proc-macro per test function?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YhFDewIJBrXyPmXpxYlUWLRy>)
pronvis has joined #rust-embedded
<t-moe[m]> I'm happy to put a bit more thought into the idea listed above^^ at some later point, but maybe we should move this discussion to a github issue on the working group? Feel free to copy/paste stuff^
<t-moe[m]> Anyways. I think I understand what you aim to achieve, and afaik there is currently no quick way to do this, due to the issues you've listed.
<ManuelHatzl[m]> t-moe[m]: > <@t-moe:matrix.org> Anyways. I think I understand what you aim to achieve, and afaik there is currently no quick way to do this, due to the issues you've listed.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/TxMoVGHWpjDKfjhCmEdAIcHk>)
<ManuelHatzl[m]> <ManuelHatzl[m]> "> <@t-moe:matrix.org> Anyways. I..." <- > <@mhatzl:matrix.org> thanks for the guide :)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZYIBvDiuJumBiEdYVgeRsCHJ>)
<t-moe[m]> ManuelHatzl[m]: Thanks. Subscribed.
<t-moe[m]> Whats your timeline on this?
<t-moe[m]> I'm currently busy with a client, but I might find time later this year to work more on improving embedded testing.....
juliand[m] has joined #rust-embedded
<juliand[m]> <ManuelHatzl[m]> "Hi embedded-wg,..." <- > <@mhatzl:matrix.org> Hi embedded-wg,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wPkLvDOtEfXjphlIHXQwcchw>)
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> There's the riscv-rt crate, which does a thing. I haven't looked at it in huge detail, but it does support one level of named interrupts, albeit with a different syntax and semantics.
<bartmassey[m]> I appear to be a member of the Resources team according to the docs, but can't close this issue https://github.com/rust-embedded/discovery/issues/578 . Suggestions? Apologies for my Github confusion.
<vollbrecht[m]> its already closed?
<bartmassey[m]> Oh, it looks like the author closed it now.
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
<bartmassey[m]> But would still like to know what's up…
<JamesMunns[m]> bartmassey that teams PR needs to get merged
<JamesMunns[m]> permissions are automatically given by the admin bots
<bartmassey[m]> Ah. Thanks
<AlexKoz[m]> I won’t be long. I’m in UTC+4 now.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> hi @room , meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/773, please add any announcements or topics you'd like to discuss, and we'll start in a few minutes
rmsyn[m] has joined #rust-embedded
<rmsyn[m]> :wave:
<cr1901> adamgreig[m]: I'm sorta here, but have a headache, so read only mode for me (if I don't try to rest) lol
<adamgreig[m]> nw, rest up!
<cr1901> Also, last weeks msg still applies. Still making progress :D! Thanks!
<bartmassey[m]> Am adding Discovery Book stuff to agenda. One moment please…
thejpster[m] has joined #rust-embedded
<thejpster[m]> <ithinuel> "I have no clue why it’d fail..." <- You may be on an M0 which doesn’t have CAS atomics, only load store.
<adamgreig[m]> cool, let's begin! only one announcement from me, svdtools 0.3.17 is now out with a small tweak to html generation
<adamgreig[m]> any other announcements from anyone?
<bartmassey[m]> Yeah, good progress on Discovery Book. See the comment in the minutes https://github.com/rust-embedded/wg/discussions/773#discussioncomment-10001485
<bartmassey[m]> I'm still planning a Book Sprint for some weekend soon, with the likely topic to add chapters for RTIC and Embassy stuff. Sounds good?
<JamesMunns[m]> Lemme know when it is, happy to help if I can!
<adamgreig[m]> cool, let's press on with the items and we'll get to discovery then
<adamgreig[m]> James Munns: I guess no update on the cortex-m missing linker script detection atm, it sounds like we just need someone to play around and see if it can be done non-intrusively and then make a pr?
<JamesMunns[m]> (lots of matrix lag here, not sure what's up) But no update! Just wanted to propose the idea if it hadn't been thought of before. Agree it's ripe for a prototype!
<adamgreig[m]> cool
<adamgreig[m]> on the risc-v fallible functions item romancardenas posted an update in https://github.com/rust-embedded/riscv/blob/77b692fd4216ab1f16831cab8bd86b86ea3c27f8/riscv-pac/src/result.rs
<AlexKoz[m]> <adamgreig[m]> "any other announcements from..." <- My [kinda proposal](https://github.com/rust-embedded/wg/discussions/773#discussioncomment-9988046) about inability to use target json spec files in case of somewhere inside the build-pipeline build script that baking c-deps or binding. Also same problem cases for crates like autocfg.
<AlexKoz[m]> So we definitely need more env from cargo, that describes target better.
<adamgreig[m]> I suppose notably the error enum comes from riscv-pac rather than riscv, which seems funny at first but I suppose if the hope is for riscv-pac to not need many breaking changes compared to riscv then it will help with ecosystem stability?
<adamgreig[m]> wow yea, my phone vs my desktop are getting wildly different message lag
<adamgreig[m]> well this will make discussion a bit tricky 😆
therealprof[m] has joined #rust-embedded
<therealprof[m]> Hm, seems okay here.
<adamgreig[m]> James Munns: is the link to the accepted ideas broken in your comment about rfc3614?
<JamesMunns[m]> adamgreig[m]: will fix it!
<rmsyn[m]> the `result` module was originally in `riscv`, but moved to `riscv-pac` for the stability purposes already mentioned. with it being re-exported, downstream users should not notice the difference
<JamesMunns[m]> JamesMunns[m]: looks like they re-organized, https://rust-lang.github.io/rust-project-goals/2024h2/ is the overall link
ejpcmac[m] has joined #rust-embedded
<ejpcmac[m]> adamgreig[m]: Same here, had to restart my homeserver because it was stuck on PostgreSQL requests. Seems better now.
<adamgreig[m]> cool
<adamgreig[m]> James Munns: do you want to discuss the project goals?
<rmsyn[m]> believe @romancardenas wants feedback from the WG and `cortex-m` team: https://github.com/rust-embedded/riscv/pull/222#issuecomment-2210511689
<JamesMunns[m]> We've got some months before the next "selection process", starting Oct 1 and ending Dec, this is likely also a place where we can rally support (volunteer hours, potential funding, rust project/compiler/lang feedback)
<rmsyn[m]> if @romancardenas is around, maybe they could take over from here?
<JamesMunns[m]> I don't have anything else particularly actionable here, there is just ongoing discussion of project goals at the Foundation + Council level, so it seems to be a "well received" focus point, that we are welcome to participate in, as a WG :)
romancardenas[m] has joined #rust-embedded
<romancardenas[m]> Sorry I just connected!
<bartmassey[m]> I'd maybe possibly like to add a Project Goal around preserving the ability to use global mutable statics? I know this is controversial, but my personal opinion is that making them effectively unusable because of increasingly fancy memory models is not a great way forward for the Project, especially for the embedded folks. We'd have to work out the specifics of what we wanted, but things like breaking the ability to take a
<bartmassey[m]> mutable reference to a global static in unsafe code seem especially vexing to me. Thoughts?
<adamgreig[m]> James Munns: perhaps worth a dedicated issue thread on the wg, and we could have a meeting focussed on putting together or refining ideas?
<bartmassey[m]> Maybe this meeting is not the right place to discuss this. If not, somebody suggest a plan? Or is it easy to just veto the idea now? 😀
<JamesMunns[m]> bartmassey[m]: I disagree with this, but let's discuss after the meeting, this is a yak shaving black hole :)
<JamesMunns[m]> adamgreig[m]: Sounds good! I'll make an issue to track it
<JamesMunns[m]> JamesMunns[m]: oh wow that's convenient: https://github.com/rust-embedded/wg/issues/775
<adamgreig[m]> fun
<adamgreig[m]> cool, let's have that issue open and we can schedule a meeting for it
<adamgreig[m]> romancardenas: sorry, I missed you wanted to discuss that point, want to talk about it now?
<bartmassey[m]> I thought I remembered an issue like that. Sorry for noising up the discussion. Thanks!
<therealprof[m]> JamesMunns[m]: How did you do this?
<JamesMunns[m]> therealprof[m]: You can click the `...` on a discussion topic and click "make issue"
<bartmassey[m]> Huh. Good to know
<therealprof[m]> Nice.
<romancardenas[m]> The only thing I wanted to discuss is to get into an agreement with cortex-m so we get a similar error interface. We can do it offline in the PR if you want
<therealprof[m]> <bartmassey[m]> "I'd maybe possibly like to add a..." <- There have been a number of alternatives proposed in various threads in the Rust project around this. However I haven't seen any attempts trying those out and a verdict of: yes, that'd do.
<romancardenas[m]> Also, a review from the hal team or someone with experience developing these kinds of interfaces is appreciated :)
<adamgreig[m]> romancardenas[m]: I guess that might be best. at first glance it looks very sensible but until someone's started to put together the c-m version it will be hard to know exactly how it should look
<JamesMunns[m]> therealprof[m]: Wrote up some quick thoughts here: https://github.com/rust-embedded/wg/issues/775#issuecomment-2218385982, happy to discuss after the meeting (or maybe in another venue).
<romancardenas[m]> adamgreig[m]: Let me know if you miss any error variant or things like this. I'll try to do an RFC for cortex-m as soon as I get some spare time and we can continue the discussion there.
<AlexKoz[m]> Простите что встреваю. I need some advice and suggestions from WG for [this](https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$naJophtT302BuOUUcP9hFdJhJdXEkJCJ3DbulIkDiDI?via=matrix.org&via=catircservices.org&via=tchncs.de).... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/oktotlSMRGseGQTmDPwQcptY>)
<ejpcmac[m]> JamesMunns[m]: Happy to discuss as well after the meeting as I think I have a very strange use-case for `static mut`.
<JamesMunns[m]> ejpcmac[m]: I might have to duck out right after the meeting to take care of dinner and taking the dog for a walk, but feel free to drop some info, or we can make a new room to discuss or something if a bunch of people want to discuss.
<JamesMunns[m]> Alex Koz. I think your proposal is reasonable! I'm not sure if we can give any guidance, but I think also jumping on to Zulip might be a good place to have a more informal chat with the T-Cargo folks, who might be able to give you better guidance!
<JamesMunns[m]> JamesMunns[m]: I think we are the right *users* of the kinds of APIs you are proposing, but you might get better feedback from the Cargo team, who will have to own the implementation!
m5zs7k has quit [Quit: m5zs7k]
<adamgreig[m]> sorry, the lag is making it a bit hard to stay on top of things, but it sounds like we can move on, Alex Koz. did you want to discuss your cargo proposal?
<JamesMunns[m]> JamesMunns[m]: I think the right next steps are:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bpCQQbladFTxtgYKfvqsmvJy>)
m5zs7k has joined #rust-embedded
<AlexKoz[m]> JamesMunns[m]: Thanks! All ways points to zulip. 🤷🏻‍♂️
<AlexKoz[m]> adamgreig[m]: Definitely yes 👍🏻
<JamesMunns[m]> https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo might be a good place to mention your proposal, and mention that you are open to discuss it, and actively want feedback, especially if there is something experimental that could be implemented! They are usually pretty busy, but if the proposal is clear, and you are willing to do the work, they are usually responsive in my experience!
<JamesMunns[m]> AlexKoz[m]: > <@fzzr:matrix.org> Main questions for my is... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tGtBePUwtHTucbNMSWsEyzbW>)
<AlexKoz[m]> JamesMunns[m]: Thank you so much! You all.
<AlexKoz[m]> I’ll do it tomorrow.
<AlexKoz[m]> ❤️‍🔥
<adamgreig[m]> 🤷 I seem to be getting everything many minutes late, hopefully james' advice is good for now!
<AlexKoz[m]> > <@jamesmunns:beeper.com> Sorry for "yet another chat program", but I am happy to help the conversation if I can, and suggest any names of things! Feel free to @ me when you make a thread :)
<AlexKoz[m]> * Thank you so much! You all.
I’ll do it tomorrow. I’m in UTC+4.
❤️‍🔥
<adamgreig[m]> bartmassey: wanna talk about disco book stuff to wrap us up? your two open issues?
<bartmassey[m]> James Munns: How do you want to do discussion for the Project Goals issues? Someplace here? (Thanks for your kind and patient comments. Appreciated.)
<bartmassey[m]> Sure!
<bartmassey[m]> <bartmassey[m]> "Yeah, good progress on Discovery..." <- Sorry, getting lost in the discussion thread.
<bartmassey[m]> One sec
<JamesMunns[m]> Gauging interest for people who want to talk about static mut, could you please react with ✋ to this message if you want to talk about it? Deciding if I should make a side room
<bartmassey[m]> So #1 code mixed in with the book. It's kind of a mess, but also works well. I plan to make all code quoted in the book include instead of copy-paste, which complicates the problem.
<bartmassey[m]> Any clever suggestions are appreciated.
<bartmassey[m]> I think #2 is out-of-scope for this meeting, probably. I'll bug you folks here after I've explored a bit more
<JamesMunns[m]> Might be worth pinging thejpster, I know Ferrous has some tooling for including code samples? It might not be mdbook based though
<bartmassey[m]> Will look into that. Mdbook's include is used for some of the code samples already: it's just a question of making sure that whatever path is included is accessible at the time the book is built. My fear is that I'll end up using git submodule and nobody wants that 😀
<bartmassey[m]> Anyway, looks like Matrix is borked and we're out of time and I have another meeting. Ping me here and/or post an issue on the new repo if you have thoughts. Thanks!
<rmsyn[m]> :wave: thanks all
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> Some interesting thing: There might be improvements to the async ram bloat soon :D
<JamesMunns[m]> I made a room, #wg-embedded-static-mut:matrix.org if anyone wants to talk static mut
<JamesMunns[m]> (invited the people who raised their hands)
<adamgreig[m]> great, the last 10 minutes of messages just arrived at once lol
<adamgreig[m]> thanks everyone, I guess that will have to do for today!
pronvis has quit [Ping timeout: 264 seconds]
<AlexKoz[m]> [@jamesmunns:beeper.com](https://matrix.to/#/@jamesmunns:beeper.com), I see [cargo-build-integration](https://rust-lang.zulipchat.com/#narrow/stream/334885-t-cargo.2Fbuild-integration) thread. I’m not sure, but maybe it’s worth writing there?
kenny has quit [Ping timeout: 256 seconds]
kenny has joined #rust-embedded
AlexandervanSaas has joined #rust-embedded
<AlexandervanSaas> Hi folks, is there a way to parse defmt logs received over rtt back to the structs I used to generate the logs? I'm logging out some data and I want to write the data to a file for analysis.
<AlexandervanSaas> I guess my question boils down to how can I get the raw defmt logs so I can parse them myself using defmt-parser? It's just a one-time thing so this seems the easiest way to get my data without setting up a separate logging pipeline.
<thejpster[m]> defmt-rtt sends logs over RTT so any RTT viewer will work. Or you could hack probe-rs to dump the raw stream somewhere before it goes into the defmt decoder.
<JamesMunns[m]> You could probably use postcard/serde json core + rtt-target instead of defmt, if you want to deserialize instead of parse
<JamesMunns[m]> s//-/, s//-/
<AlexandervanSaas> I see probe-run has a json output feature
<JamesMunns[m]> AlexandervanSaas: Does that actually give you structured data? Or just a text output decoded?
<thejpster[m]> You won’t get the struct back - objects are serialised using the derived Format impl and I suspect that is lossy to some degree.
<AlexandervanSaas> JamesMunns[m]: Idk, I haven't tried it. Is probe-run still usable?
<thejpster[m]> If you really want structures but not as text, I’d use postcard and serde as James suggested, or memcpy them to the output stream and write a parser that extracts DWARF from the ELF to decode them. Which is exactly what your debugger does.
<AlexandervanSaas> I was hoping for a quick and dirty solution but postcard is probably the best solution
<JamesMunns[m]> (I am interested in supporting postcard-rpc over rtt for the record)
<JamesMunns[m]> That needs some *stuff* to be possible now, tho. But one way postcard should Just Work.
<JamesMunns[m]> s//-/
<JamesMunns[m]> I also sort of want to smash together postcard, tracing, and defmt to make a logging interface you can use with any T: Serialize instead of Debug or Format, and get it back out the other side on the host
<JamesMunns[m]> This is "just an idea" today tho :D
<AlexandervanSaas> That would be awesome.
<JamesMunns[m]> JamesMunns[m]: If you feel like building that, I can give you all my notes (or actually write them down)
<JamesMunns[m]> JamesMunns[m]: If not I'll get to it eventually :D
<AlexandervanSaas> Sounds cool but I have to pass
<bartmassey[m]> In the Discovery Book we currently refer more "advanced" users to https://github.com/rust-embedded/cortex-m-quickstart . Is this still a good idea? If so, should we do some maintenance on that repo?