00:15 <braincode[m]> <JamesMunns[m]> I do think we are in need of "someone writes a blog post that clearly explains where cargo/workspaces/rust-analyzer fail for embedded projects", particularly:...

00:15 <braincode[m]> * How to transparently "cargo test" on the host (emulated) vs on-device (HIL?)

03:43 <Ralith> can anyone recommend a good oscilloscope? I'm interested in doing audio-rate analog stuff and maybe some logic analysis; absolutely no idea where to begin looking, but good software support would be nice

03:46 <leftger[m]> Ralith: depends on your budget TBH. Some years back Saleaes were pretty affordable. Now it's just pricey. A decent beginner setup would be a $10 PSOC-based Sigrok-compatible logic analyzer from eBay. On the oscilloscope side of things I've heard not-too-bad things from the $50 offerings on eBay. Something more decent would be springing for a Rigol DHO800 osciloscope.

03:48 <Ralith> they're not typically the same device? can you be a little more specific than "$50 on ebay"?

03:49 <Ralith> re: Rigol, I'm a little surprised to see a self-contained device rather than a little black box with a USB port and some accompanying software

03:51 <leftger[m]> Ralith: Sorry I was off by a bit: It's about $75 some something sampling at ~20MHz but you get a multimeter and a basic signal generator.

03:51 <leftger[m]> https://ebay.us/m/mXMIEM

03:55 <leftger[m]> Ralith: Depends on what you want. Once you have buttons and a screen you'll get much better feedback on whatever you're trying to do. The "little black box" approach is handy if you want to save a bit of money. It all depends on what you want. As for not being the same device they definitely can be. I just got a DHO900 for at least double the price, but it doesn't come with the logic probes. That's another $400.

03:56 <Ralith> interesting, thanks. My immediate goal is doing frequency response analysis on some purely analog audio circuits but it'd be nice to cover future projects.

04:02 <leftger[m]> Ralith: Something I feel tinkerers can learn a lot from is simulation. Here's a way to gain a lot of the insight for basically free:... (full message at <https://catircservices.org/_irc/v1/media/download/AczkrkMPNS2d449Tta6HFdEMfkRq6H5KckESMzyztXJvybY_h3RBWVsft7Sn4JI0IET4elhihCZrYlc7LPQ4qUC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9Xa2pycktVZXd3ekN4WFV0SVFoeGNUcHA>)

04:05 <Ralith> leftger[m]: circuit's already simulated and built, the problem is determining if the actual behavior matches the sim, especially in a potentially noisy environment

07:14 <thejpster[m]> Having back off holiday today. Going to get some Rust stuff done before I head back to work next week.

07:15 <thejpster[m]> If you sent me a DM request recently, I’m getting a 502 trying to join the room.

08:13 <wassasin[m]> <Ralith> can anyone recommend a good oscilloscope? I'm interested in doing audio-rate analog stuff and maybe some logic analysis; absolutely no idea where to begin looking, but good software support would be nice

08:13 <wassasin[m]> If you want to use your scope as a logic analyzer without using the on-board software, I recommend getting something for which extracting the data to a hostmachine is do-able

08:13 <wassasin[m]> Your milage will vary, but a good starting point is https://www.ngscopeclient.org/hardware

08:18 <wassasin[m]> I got a Siglent scope in 2023 but last I checked getting the data out over ethernet was not implemented as far as I could find. I see it now listed for ngscopeclient so I should check it out again

08:18 <wassasin[m]> Using a Saleae a lot, but writing parsers for new protocols is not fun

08:19 <wassasin[m]> * Using a Saleae a lot, but writing parsers for the Saleae GUI is not fun

09:09 <Koen[m]> <Ralith> can anyone recommend a good oscilloscope? I'm interested in doing audio-rate analog stuff and maybe some logic analysis; absolutely no idea where to begin looking, but good software support would be nice

09:09 <Koen[m]> I'm using an 'upgraded' Siglent sds 1104x-e. Sufficient as oscilloscope and simple logic analysis for most things. Uses scpi over usb and ethernet for interfacing. I think I've used it with Pulseview (sigrok) before, most of the time I use the display on the device.

09:10 <Koen[m]> It also has some cursed webinterface which seems to be a VNC session into the device display…

09:21 <wassasin[m]> <Koen[m]> It also has some cursed webinterface which seems to be a VNC session into the device display…

09:21 <wassasin[m]> It also has a remote desktop server running

09:22 <wassasin[m]> I have the Siglent SDS2104X+ but the SCPI over ethernet driver was not working/written

09:22 <Koen[m]> I think I've used it with pulseview, but that's at least 2 years ago

09:23 <wassasin[m]> I'll check again sometime

10:39 <Lumpio-> I want somebody to make a hybrid scope that has an actually good PC interface, but also some twiddly knobs

10:40 <Lumpio-> It's so much easier to adjust settings if you have like 3 knobs than having to clicky the mouse all the time

10:41 <LeandroMarceddu[> <leftger[m]> depends on your budget TBH. Some years back Saleaes were pretty affordable. Now it's just pricey. A decent beginner setup would be a $10 PSOC-based Sigrok-compatible logic analyzer from eBay. On the oscilloscope side of things I've heard not-too-bad things from the $50 offerings on eBay. Something...

10:41 <LeandroMarceddu[> Can confirm. I bought a Rigol DHO924 with the PLA addon and I've been loving it so far. /cc Ralith

10:45 <Lumpio-> Yeah the cheapo PC logic analyzers are totally enough for a lot of things

10:45 <Lumpio-> For just digital logic I don't really need any knobs or displays because there isn't that much to adjust and all the analysis happens on the PC anyways

10:46 <Lumpio-> So a cheapo box with USB on one side and a bunch of pins on another is perfectly good for me

11:02 <mkj[m]> I get annoyed by the fan whine of the DHO924S. maybe alternatives are better?

11:02 <leftger[m]> mkj[m]: Have you tried sticking a Noctua fan in there? 😂

11:02 <mkj[m]> (or I could open it up and put a bigger fan on the outside)

11:14 <LeandroMarceddu[> <mkj[m]> I get annoyed by the fan whine of the DHO924S. maybe alternatives are better?

11:14 <LeandroMarceddu[> This is also true. Luckily I'm less annoyed by it

13:00 <dngrs[m]> I actually drilled a hole in the bottom of my 3d printer and mounted a ryzen fan to replace the tiny stock jet turbine disasters

13:10 <dngrs[m]> in terms of affordable scopes/logic analyzers: Hantek makes USB devices that can do both, and the OpenHantek software is ... okay

13:11 <dngrs[m]> on the other hand you can build a [monstrously powerful logic analyzer](https://www.youtube.com/watch?v=NaSM0-yAvQs) based on the pico 2, if you wanna maximize bang for the buck

13:14 <dngrs[m]> <leftger[m]> Sorry I was off by a bit: It's about $75 some something sampling at ~20MHz but you get a multimeter and a basic signal generator....

13:14 <dngrs[m]> pretty damn sure this is dropshipped off of aliexpress, where you can find it listed for cheaper (as DSO-TC4)

14:55 <RobWells[m]> <dngrs[m]> on the other hand you can build a [monstrously powerful logic analyzer](https://www.youtube.com/watch?v=NaSM0-yAvQs) based on the pico 2, if you wanna maximize bang for the buck

14:55 <RobWells[m]> I got some of these recently, $52.53 delivered to the UK (for 5 boards). It's the first time I'd used a logic analyzer but they've been easy to work with.

14:56 <RobWells[m]> Assembled, I should say, except for the Pico.

15:23 <Mihael[m]> <JamesMunns[m]> if you don't mind running some code, you can always use `core::mem::size_of::<MatterMessageHeader>()` and print it at runtime

15:23 <Mihael[m]> Do you know if i can get the size of the function this way without passing actual arguments into it?

15:24 <dirbaio[m]> what do you mean with "passing actual argumetns"?

15:24 <jason-kairos[m]> isn't that just going to give the size of a function pointer?

15:26 <jason-kairos[m]> better off manually looking at the map file output if you don't need it at runtime

18:28 <RobinMueller[m]> <barafael[m]> James Munns: here I reduced the case to an absolute minimum:...

18:28 <RobinMueller[m]> barafael: James Munns probably probably can help more here.. Concerning the change: the PR made some error handling consistent. Hopefully, only minor adjustments are necessary for this to work again?

18:29 <RobinMueller[m]> s/Munns/Munnsprobably/, s/probably probably//

18:29 <RobinMueller[m]> * barafael: James Munnsprobably can help more here.. Concerning the change: the PR made some error handling more consistent. Hopefully, only minor adjustments are necessary for this to work again?

18:31 <RobinMueller[m]> RobinMueller[m]: [It](https://github.com/jamesmunns/cobs.rs/pull/39) is related to https://github.com/jamesmunns/cobs.rs/issues/27 . perhaps, all that is necessary is to check the length of input data stream to code, and skip decode calls if it is 0?

18:31 <RobinMueller[m]> s/It/The PR/

18:31 <RobinMueller[m]> s/It/The PR/, s/code/decode/

19:33 <RobinMueller[m]> were there some major changes to the --manifest-path argument handling with Cargo? I updated my Rust version, and now have an issue which might be related to cargo not using the .cargo/config.toml inside the folder of the manifest path..

19:35 <RobinMueller[m]> * were there some major changes to the --manifest-path argument handling with cargo build? I updated my Rust version, and now have an issue which might be related to cargo not using the .cargo/config.toml inside the folder of the manifest path..

20:10 <thejpster[m]> From what version to what version?

20:11 <dirbaio[m]> .cargo/config.toml lookup has always been relative to the CWD, never to the manifest path

20:11 <dirbaio[m]> I think

20:12 <RobinMueller[m]> hmm, then why did the CI break (or ever work) 🤔 I'll try to re-produce it, still got some older rust versions lying around

20:18 <RobinMueller[m]> ah that is interesting, it works with 1.88.0, and stops working with 1.89.0.

20:20 <RobWells[m]> This isn't another case of the elf2uf2-rs problem is it? 🫣 ("unrecognized ABI")

20:23 <RobWells[m]> (ELF header change on nightly a couple of months ago, just got released in 1.89)

20:34 <RobinMueller[m]> <dirbaio[m]> .cargo/config.toml lookup has always been relative to the CWD, never to the manifest path

20:34 <RobinMueller[m]> I solved the CI issue in any case, by simply `cd`ing into the test folder. I tried to find some documentation, but did not find anything special about the configuration lookup in combination with `--manifest-path`. Also checked https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-188-2025-06-26, there was one fix related to --manifest-path..

20:35 <RobinMueller[m]> s/188/189/, s/06/08/, s/26/07/

20:35 <RobinMueller[m]> * I solved the CI issue in any case, by simply cding into the test folder. I tried to find some documentation, but did not find anything special about the configuration lookup in combination with --manifest-path. Also checked https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-189-2025-08-07, there was one fix related to --manifest-path, but that should not be related

20:56 <barafael[m]> <RobinMueller[m]> [It](https://github.com/jamesmunns/cobs.rs/pull/39) is related to https://github.com/jamesmunns/cobs.rs/issues/27 . perhaps, all that is necessary is to check the length of input data stream to code, and skip decode calls if it is 0?

20:56 <barafael[m]> when I do that, it works indeed! Thanks, first of all. I wonder if I should have been checking that earlier on?

20:57 <thejpster[m]> <RobinMueller[m]> I solved the CI issue in any case, by simply `cd`ing into the test folder. I tried to find some documentation, but did not find anything special about the configuration lookup in combination with `--manifest-path`. Also checked https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-188-2025-06...

20:57 <thejpster[m]> I see this on both rustc 1.88 and 1.89: https://gist.github.com/thejpster/026e84c668e94d2ea7c9d89168d83d03

20:58 <thejpster[m]> in both cases, being in testbin picks up testbin/.cargo/config.toml and being outside testbin and using --manifest-path testbin/Cargo.toml does not pick up the inner .cargo/config.toml file - only the outer one.

21:08 <thejpster[m]> <RobWells[m]> (ELF header change on nightly a couple of months ago, just got released in 1.89)... (full message at <https://catircservices.org/_irc/v1/media/download/AS4U6jFtSBBGOPWFs4W1bq4xw1_-irv3VgbS1Y_0kWq7wiI_iwRuAJMgVPtbqFaWlvfV0Z8bgMkMClM9XUQc21S_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9VTWluVWZwSFdTc0RqVHhWcFpDRUNUQ0w>)

21:09 <thejpster[m]> and as someone on a team marked as target maintainer, I feel like I should have found out about this change to a target I maintain before it actually got released.

21:11 <RobWells[m]> It seems to be tripping a few people up now that it's in stable, seems to have been introduced in nightly around June-ish (see [this elf2uf2-rs](https://github.com/JoNil/elf2uf2-rs/issues/40)). But what's really confused me is that I don't know that this is a change in Rust. I can't find anything in the ELF generation in the compiler that would have caused this (I was literally just writing a question about it on the internals

21:11 <RobWells[m]> forum).

21:11 <RobWells[m]> * [this elf2uf2-rs issue](https://github.com/JoNil/elf2uf2-rs/issues/40)). But

21:13 <RobWells[m]> So maybe it's a change in the compiler that causes LLVM to mark the binary as being Unix - GNU?

21:15 <thejpster[m]> Have opened https://rust-lang.zulipchat.com/#narrow/channel/242906-t-compiler.2Farm/topic/ELF.20headers

21:15 <thejpster[m]> if I appear to be in a bad mood about it, it's because I literally got back off vacation a couple of hours ago

21:27 <dngrs[m]> suggestion to update the room: https://matrix.org/blog/2025/08/security-release/

21:28 <dngrs[m]> (room v12 support is not yet very widespread tho)

21:32 <thejpster[m]> I'm bisecting to find out where the ELF ABI changed.

21:36 <RobWells[m]> It's also changed for thumbv6m-none-eabi

21:37 <thejpster[m]> bjorn says it is a side-effect of https://github.com/rust-lang/rust/pull/140872, as we now use GNU extensions

21:42 <RobWells[m]> Out of interest, does this have a practical meaning for embedded targets? (Beyond failing the check in elf2uf2-rs.)

21:44 <thejpster[m]> only for people who inspect the ELF headers.

21:44 <thejpster[m]> I suspect probe-rs does not (at least, not the extent of verifying the ABI of the application it is flashing)

21:45 <dirbaio[m]> No meaning at all for embedded, this is just elf2uf2-rs being overly strict. Like "this is the exact abi rustc outputs today, let's just hardcode a check for that"

21:45 <dirbaio[m]> No other tool I've seen is so strict

21:46 <dirbaio[m]> Probe-rs, pyocd, openocd, picotool are unaffected

21:46 <dirbaio[m]> So... 🤷

21:49 <RobWells[m]> In terms of guiding people away from elf2uf2-rs, is it just users of RP chips where it's really in use?

21:49 <dirbaio[m]> Yep

21:49 <RobWells[m]> (I'm just thinking in terms of updating docs for HALs etc)

21:50 <RobWells[m]> Ok great, I'll see about putting in a PR for rp-rs in the morning.

21:50 <thejpster[m]> UF2 is a standard format, but I don't know of any other UF2 enabled bootloaders, ROM or otherwise.

21:50 <thejpster[m]> (it's also a terrible format, packing 256 bytes of useful data into each 512 byte block)

21:51 <dirbaio[m]> There's some nrf boards that come with uf2 bootloader but elf2uf2-rs would explode anyway on those because it also hardcodes the flash address range of the rp2040

21:52 <thejpster[m]> s/terrible/genius depending on your point of view. It believe it's designed to be agnostic as to the order the blocks are written to a virtual disk drive.

21:53 <thejpster[m]> I generally use the official picotool for loading code onto the RP2xxx chips, and happy to recommend likewise now there are prebuilt binaries available (https://github.com/raspberrypi/pico-sdk-tools/releases)

21:53 <dirbaio[m]> Plus it's only on rp that people insist on developing without a debug probe 😂

21:53 <thejpster[m]> (over USB, specifically, obviously you'd use probe-rs over SWD)

21:54 <thejpster[m]> oooh, I don't know. ESP and Arduino both love a serial bootloader.

21:54 <dirbaio[m]> So I'd be surprised if anyone is using elf2uf2-rs on non-rp2040

21:55 <dirbaio[m]> thejpster[m]: Arduino is not a serious platform. Yes esp is kind of an exception, newer ones have built-in USB jtag tho

21:56 <RobWells[m]> thejpster[m]: In terms of recommended usage, are particular flags worth including? The PR I have in for Embassy is just `-x -t elf`

21:57 <RobWells[m]> -v for verify and -u for (partial) update are the others I've seen people use, but to be honestly I just use a probe

21:57 <thejpster[m]> > Arduino is not a serious platform

21:57 <thejpster[m]> I know a lot of serious people who would disagree, but I'm not tugging on that thread today

21:57 <RobWells[m]> * -v for verify and -u for (partial) update are the others I've seen people use, but to be honest I just use a probe

21:58 <thejpster[m]> rp235x-hal-examples/README.md says I used picotool load -u -v -x -t elf target/riscv32imac-unknown-none-elf/debug/blinky

22:03 <dngrs[m]> banging ye olde drum again: I wish we had many more drop in replacements for what makes up the arduino ecosystem

22:49 <LachlanIkeguchi4> What's so special about the Arduino ecosystem?

22:54 <dngrs[m]> it's pretty integrated. They have a serial monitor, a graph data plotting tool, lots of libraries easily installed via IDE, that kind of stuff. Rust has most of the ingredients but lacks integration/QoL