04:09 <re_irc> <jkelleyrtp> I'm struggling with getting vscode/rust-analyzer to work properly with my embedded projects. Does anyone have a working configuration? The issue i'm specifically facing is outlined here: https://github.com/rust-lang/rust-analyzer/issues/11982

04:12 <re_irc> <newam> jkelleyrtp: https://github.com/newAM/stm32wl-lightswitch-demo/blob/main/.vscode/settings.json

04:12 <re_irc> That's what works for me.

04:14 <re_irc> <jkelleyrtp> newam: Does RA properly check examples? I'm not getting any warnings even when using that configuration

04:15 <re_irc> <newam> Examples I am not sure about. I do get warnings for binaries / libraries though

04:18 <re_irc> <jkelleyrtp> newam: Ah, bins work for me but not examples. There's an issue on RA but it looks like I'm the one who originally made it (https://github.com/rust-lang/rust-analyzer/issues/10934)

04:21 <re_irc> <jkelleyrtp> Ah - looks like you can manually override cargo to include examples

04:21 <re_irc> "rust-analyzer.checkOnSave.extraArgs": [

04:21 <re_irc> "--examples",

04:21 <re_irc> ],

09:24 <re_irc> <heksa> halfbit: Our lab has lots of Zynq's and PYNQs and we do some Rust things. The PYNQ has a Cortex-A9, and I made a Rust module for an embedded intro course two years back: https://blogs.tuni.fi/cs/unit/cross-compiling-rust-to-run-on-pynq-z1/. I feel like I was probably a total newbie back then and it's all hacks, but it fits the definition of "Rust on Cortex-A9", and all source should be on GitHub.

09:25 <re_irc> <heksa> I did get the general feeling that support was pretty non-existent back then. I haven't heard of many updates but I guess cross-compiling is slightly easier now in general.

09:25 <re_irc> <K900> They're pretty boring ARM cores overall

09:26 <re_irc> <K900> And you're going to need a custom HAL for whatever is running on the FPGA part anyway

09:26 <re_irc> <heksa> We also have those Zynq's but we use official Xilinx tooling for the main logic, and put our RISC-V (and Rust) on the FPGA soft logic instead.

09:29 <re_irc> <K900> You could also just run Linux on the ARM part

09:29 <re_irc> <K900> If you don't need hard RT

09:29 <re_irc> <K900> Then it just becomes, well, Linux

09:30 <re_irc> <K900> And hard RT stuff is probably better off being on the FPGA side

11:27 <re_irc> <Chris [pwnOrbitals]> Anyone knows some good crates to control GDB from Rust ? I'd like to have a test rig that has some Rust on the host controlling and influencing the Rust code on target

12:25 <re_irc> <ryan-summers> Perhaps take a look at probe-run's on-target tester? I don't think it uses GDB, but rather uses probe-rs to manually manipulate the target via the debug probe to run unit tests on hardware

14:24 <re_irc> <Chris [pwnOrbitals]> great idea ! looks like it fits what I'm looking for

14:24 <re_irc> <Chris [pwnOrbitals]> thanks :)

18:15 <re_irc> <MathiasKoch> Does anyone have a reasonable implementation of async Read/Write on either rtt channels or defmt frames? blocking std::io::Read/Write could also have interest

18:23 <re_irc> <Noah> doesn't probe-rs-rtt implement Read/Write?

18:24 <re_irc> <MathiasKoch> Nope.. I was a bit surprised as well

18:24 <re_irc> <MathiasKoch> Would have made so much sense

18:25 <re_irc> <MathiasKoch> Might be due to the core requirement of "pub fn read(&self, core: &mut Core, buf: &mut [u8])"?

18:25 <re_irc> <MathiasKoch> +argument

18:26 <re_irc> <newam> it used to in a previous version, now it doesn't because the core argument got added

18:26 <re_irc> <MathiasKoch> I guess something like this should be okay for a sync version?

18:26 <re_irc> impl Read for UpChannel {

18:26 <re_irc> fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> {

18:26 <re_irc> let mut core = self.session.lock()?.core(0)?;

18:26 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/b35af7a41b5762d44f01dc7e6aa1a237ebf10e1d0b3d5930c5deeda70a1eff7f (9 lines)

18:30 <re_irc> <MathiasKoch> Is there an easy way to get an "AsyncRead" from "std::io::Read"?