<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]> "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]>
<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
<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...
<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[>
<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]>
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.
<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]>
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!
<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]>
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
<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
<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.
<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?
<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!
<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!
<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?