00:27 <dygear[m]> Has anyone here used the https://crates.io/crates/enum_dispatch create? Looks like it might solve my problem of having the correct sized data at the cost of a vtable lookup. Not sure how much that would hurt me on an embedded platform. 400,000ns is 0.4ms. But I don't know what CPU that was actually run on. If it's a Threadripper or an Eypc then I don't think that would be a great idea for a RP2040.

04:19 <morfertaw[m]> <morfertaw[m]> "The report I am sending is as..." <- After looking at the source code for the [HidReader](https://github.com/embassy-rs/embassy/blob/e1435195cb90f6298b236255b5248db2706aead7/embassy-usb/src/class/hid.rs#L292-L374) I do not think the [RequestHandler](https://docs.embassy.dev/embassy-usb/git/default/class/hid/trait.RequestHandler.html) has anything to do with writing reports to the host.

05:57 <jannic[m]> dygear: if you ignore the absolute numbers then it's obvious that enum_dispatch is much faster than the alternatives. Which is exactly the point, as it avoids the vtable lookup. However, the difference will also depend on CPU architecture, and I guess it will be much smaller for CPUs without deep pipelines (like on the rp2040). In any case, it should not be slower than dynamic dispatch.

05:57 <jannic[m]> l would worry more about binary size and maintainability, not execution speed. Perhaps even compilation time. Of course, if you want to be sure, measure.

06:19 <milan[m]> does anyone know a good crate alternative to FastLED? (focus on "fast")

06:25 <morfertaw[m]> <morfertaw[m]> "After looking at the source code..." <- I managed to get the reports with ids to work 🎉.

06:25 <morfertaw[m]> morfertaw[m]: I changed the report descriptor to the following.

06:25 <morfertaw[m]> ```

06:25 <morfertaw[m]> ```rust

06:27 <morfertaw[m]> * I changed the report descriptor to the following.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SVHfMhmJSBfnacykntEjQipT>)

06:28 <morfertaw[m]> * I changed the report descriptor to the following.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hBCgbwwernjoxrdITPsSVgSU>)

06:29 <morfertaw[m]> morfertaw[m]: I removed the following part from the keyboard report with report id of 1.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nvDhmfXuGuOlyqdYzHxUying>)

06:32 <morfertaw[m]> morfertaw[m]: Using the original report, shown below, it worked fine when there was no report id even when there were output reports.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ucyXqSuUJFuRPvDDhsmQRyRc>)

06:34 <morfertaw[m]> morfertaw[m]: I can now use the report prepended with an id. Not sure why having output reports with an id did not work. ❔

06:35 <morfertaw[m]> * I managed to get the reports with ids to work. 🎉

07:27 <sirhcel[m]> <milan[m]> "does anyone know a good crate..." <- Have you checked out the [`smar-leds`](https://crates.io/keywords/smart-leds) universe yet? It contains several drivers using dedicated hardware for driving the leds. I have just worked with ws2812 so far and they are using a fixed timing.

07:27 <sirhcel[m]> > <@m-vz:matrix.org> does anyone know a good crate alternative to FastLED? (focus on "fast")

07:27 <sirhcel[m]> * Have you checked out the [`smar-leds` universe](https://crates.io/keywords/smart-leds) yet? It contains several drivers using dedicated hardware for driving the leds. I have just worked with ws2812 so far and they are using a fixed timing.

08:51 <MathiasKoch[m]> Does anyone know of a thiserror style crate, but for defmt? And if not, has anyone considered creating one?

14:43 <fuse117[m]> I am using a C library (an I2C sensor driver core) in a project. My app occasionally crashes due to an error in the C code. It looks like a null pointer is being dereferenced, but I am not sure. Is it possible to debug such an issue with the probe-rs debugger.

14:47 <JamesMunns[m]> you should be able to use GDB to single step, or set breakpoints, perhaps even conditional breakpoints

15:01 <FreeKill[m]> <fuse117[m]> "I am using a C library (an I2C..." <- I admittedly haven't tried with exactly probe rs, but I've debugged mixed language projects before - and with the source directories set up, everything seamlessly debugged. Have you tried stepping into the c funcs and seen what you get?

15:02 <danielb[m]> probe-rs may or may not work, but I'd love to hear about it - feedback helps us improve

15:04 <RobertJrdens[m]> <MathiasKoch[m]> "Does anyone know of a thiserror..." <- Just the `Display` part or also the `source()` machinery? The latter would be really cool to see on embedded.

15:10 <MathiasKoch[m]> Could settle for the display part, but yeah, the whole thing would be amazing 😅

15:32 <RobertJrdens[m]> <MathiasKoch[m]> "Could settle for the display..." <- The `source()` stuff should work verbatim.

15:32 <RobertJrdens[m]> Somebody should try it! 😉

15:32 <RobertJrdens[m]> And tere's https://lib.rs/crates/platform-switch

16:22 <FreeKill[m]> I can confirm that probe-rs does work debugging into C libs!

16:22 <FreeKill[m]> Including breakpoint

16:22 <FreeKill[m]> * Including breakpoints

16:25 <danielb[m]> FreeKill[m]: thanks, that's good to know, the huge asterisk in my message is that there may be certain compilers and compiler flags that cause hiccups :)

16:26 <FreeKill[m]> I'm sure :P This was linked to a an archive produced by arm-none-eabi-gcc

16:26 <FreeKill[m]> s/a//

16:26 <JamesMunns[m]> danielb[m]: fwiw: I still have experienced that turning off LTO (and using GCC for linking does that implicitly!) makes debugging not cursed

16:27 <JamesMunns[m]> like, all the "debug stuff that makes GDB crash and/or act weird" tends to go away completely with LTO. you still get the "optimized out" stuff, but none of the "gdb segfaulted" or "my traceback is totally messed up"

16:27 <JamesMunns[m]> s/with/without/

16:27 <danielb[m]> JamesMunns[m]: this doesn't help me much as the implementor right now 😅

16:27 <fuse117[m]> FreeKill: can you share that little project?

16:28 <JamesMunns[m]> I think LLVM's LTO just has "preserve debuginfo through optimization transformation" bugs, nothing probers can do (tho GDB could certainly NOT segfault)

16:28 <FreeKill[m]> fuse117[m]: I think that'll confuse you more than anything! I just threw some random nonsense into an existing project i had lying around

16:28 <FreeKill[m]> But the relevant bits are...

16:29 <FreeKill[m]> in main.rs:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AurLwRmxXUVpGPwGqBNaKZbD>)

16:30 <FreeKill[m]> s/// println!("cargo::rustc-link-lib=test")//, s/`arm-none-eabi-ar.exe -rcs libtest.a test.o`/`arm-none-eabi-ar.exe -rcs libtest.a test.o`/

16:30 <danielb[m]> O0 and -g3 gave you "variable optimized out"? 😱

16:31 <danielb[m]> * O0 and -g3 gave you "value optimized out by compiler"? 😱

16:34 <danielb[m]> danielb[m]: James Munns: this is what you mean by ` (and using GCC for linking does that implicitly!)` is it 🤦‍♂️

16:36 <JamesMunns[m]> danielb[m]: uh, maybe not, I meant that AFAIK arm-none-eabi-gcc doesn't participate in LTO (so `lto = true` is more or less ignored), but maybe these days it can.

16:36 <FreeKill[m]> it can :)

16:37 <FreeKill[m]> Or at least flto is an arg you can pass and break things with, cos I've done it 😆

16:37 <JamesMunns[m]> FreeKill[m]: then I was just wrong :D

16:38 <FreeKill[m]> Whether it works or not is another question ;D

16:39 <JamesMunns[m]> That I definitely have no idea about :D

16:40 <FreeKill[m]> This was a discussion at my job, where I suggested pushing more code into modules, separation of concerns etc

16:41 <FreeKill[m]> Was told that they were worried that would lead to poor performance due to the indirection

16:41 <FreeKill[m]> And the looks I got back when I said something like "Isn't that what optimisers are for?" - It's amazing I'm still here today

16:43 <danielb[m]> just don't tell me their answer was "we can't trust optimisers because they miscompiled our code in 1986"

16:43 <FreeKill[m]> 🙃

16:44 <FreeKill[m]> If -O0 was good enough for ada lovelace it's good enough for us

16:50 <avery71[m]> <danielb[m]> "just don't tell me their..." <- Something something on trusting trust by Ken Thompson

16:51 <JamesMunns[m]> avery71[m]: yeah, I can count on one finger the times that an optimizer has bitten me in Rust (and it didn't even happen to me - it was the opt-level=z bug we put out a bulletin for), and I'd bet more than a fair share of "optimizer bugs" reported by users turned out to be sparkling UB :D

16:58 <mali[m]> So ferroscene shares everything upstream with the rust toolchain, is that right?

16:58 <JamesMunns[m]> yep, (afaik - I wasn't involved with the impl) it's basically "just" a rolling release distro with accessories (qualification steps and documentation)

16:59 <JamesMunns[m]> err, maybe not rolling release - it trails the upstream project, but aims to track it 1:1, not maintain external patchsets

16:59 <JamesMunns[m]> but on a slower release cadence (not sure what they are targeting)

16:59 <mali[m]> I assume that it can only track with a delay, right?

17:01 <JamesMunns[m]> yep, tho iirc (again, very outdated not implementer knowledge), not THAT much of a delay, probably not live, but not like "years ago" trail. Dunno what's public for that, I'm sure they'd be happy to talk if you contact them tho

17:01 <mali[m]> I see.

17:02 <mali[m]> Although their toolchain is ISO26262, does not mean that rustc is.

17:02 <mali[m]> You must use ferroscene to ensure that.

17:03 <JamesMunns[m]> that being said, if your company DOES do safety critical, it is VERY common to snapshot a compiler version for the lifetime of the project (or snapshot one midway). so you might get very close to live at the start of a project, and then keep that.

17:03 <JamesMunns[m]> mali[m]: yep, or basically re-impl all their qualification work on your own. Which is not intractable, they did it, and I think HighTec did too? but you probably wouldn't WANT to do it (and it'd probably be cheaper to just pay for ferrocene unless your company does that kind of stuff on the regular)

17:04 <JamesMunns[m]> qualification is a lot of QA and due diligence and long term support and proactive maintenance.

17:04 <mali[m]> So it matches their business model, right? You can have the latest toolchain anytime, but if you want to freeze, then you must contribute

17:05 <JamesMunns[m]> not sure if I track what you mean

17:06 <mali[m]> Argh, maybe sth that I overheard erroneously.

17:07 <JamesMunns[m]> again - probably better to ask any details to them, I'm enthusiastic about their work, but totally uninvolved, and I don't want anyone to take my current understanding for objective truth, esp if I'm out of the loop or plans have changed.

17:07 <JamesMunns[m]> afaik, the model is still "you pay them", dunno if they charge "per version" or "per seat" or "per qualified project" or some mix of those (all are common for various qualified toolchains)

17:07 <mali[m]> I thought that the latest toolchain is available to check, but earlier releases require a licence

17:07 <JamesMunns[m]> I think you can use their artifacts for trial, but that doesn't get you license to use them for real releases

17:08 <JamesMunns[m]> like, you need to license their material when you go to your regulator and say "here's all of our paperwork, appendix A is the paperwork and qualification for the compiler we used for this project"

17:08 <mali[m]> Yeah, of course.

17:09 <mali[m]> Really a great thing to have.

17:10 <JamesMunns[m]> like, informally, I think you can just use it, as a "try before you buy".

17:10 <JamesMunns[m]> For example, companies like Solid Sands prepare qualification toolkits for snapshots of compilers like LLVM or GCC, so you could use the same version, but that doesn't get you "credit" for having validated that compiler for your specific use cases (unless you pay them)

17:10 <JamesMunns[m]> * or GCC (for C/C++), so

17:12 <mali[m]> Thanks James Munns this will help a lot when I pitch it to the company.

17:13 <mali[m]> Kids are taking the house down now tho, gotta go.

17:19 <fuse117[m]> FreeKill: can you share the Test configuration in your launch.json

17:50 <fuse117[m]> FreeKill: thanks for sharing. i have the probe-rs debugger catching exceptions in my C lib. the issue now is that all the variables are listed as `< <value optimized away by compiler, out of scope, or dropped> >`. your image appears to show the same

17:50 <fuse117[m]> any attempt to inspect the variables kills the session too

18:01 <FreeKill[m]> yeah i dont think i can inspect variables

18:02 <FreeKill[m]> with cortex-debug (gdb) i can

18:03 <fuse117[m]> i am looking into cortex-debug right now

18:04 <fuse117[m]> i love troubleshooting intermittent errors inside code i didn't write... and code i may not even continue to use as im only evaluating a new sensor

18:10 <danielb[m]> hmm can you folks get me a .elf and a coredump of the whole RAM and ROM address ranges?

18:11 <danielb[m]> in the Debug Console you can type something like dump 0x20000000 0x3000 0x0 11200 out.coredump

18:17 <danielb[m]> s//`/, s//` (where 0x3000 is the size of my device's RAM, and 11200 is the size of the binary)/

18:30 <FreeKill[m]> that command doesnt do anything for me in probe-rs?

18:30 <danielb[m]> mm let me double-check quick, maybe there's a difference between the cli and the debug console :/

18:32 <danielb[m]> should work :/

18:34 <FreeKill[m]> let me update

18:43 <FreeKill[m]> yep just a version thing

19:00 <FreeKill[m]> fuse117: updating probe has also fixed seeing C vars

19:00 <FreeKill[m]> for me

19:01 <FreeKill[m]> (0.23.0)

19:16 <FreeKill[m]> One day I should really follow through and learn how probe-rs does anything, because the fact you can get vars out of c code blows my tiny mind

19:24 <fuse117[m]> i just updated and still can not view vars

20:22 <PhilMarkgraf[m]> Is there a Matrix channel for defmt?

20:23 <dirbaio[m]> #knurling:matrix.org

20:23 <dirbaio[m]> but it's not active at all

20:26 <PhilMarkgraf[m]> dirbaio[m]: Wow! Not for nearly a year. In that case, where is the best place to ask questions about defmt? Here?

20:27 <dirbaio[m]> here I guess

20:27 <dirbaio[m]> or if you want to ask / tell the actual maintainers something, github probably

23:10 <cr1901> Does anyone know a no-alloc stack usage monitor that can do something as simple as "print the stack usage to a Write sink"?

23:14 <cr1901> https://docs.rs/cortex-m/0.7.7/cortex_m/register/psp/index.html Oh, right, I can do this

23:42 <PhilMarkgraf[m]> Is there a way to specify where memory.x is located? Our project uses workspaces, which wants the memory.x at the root of the workspace. But we need two of the projects in directories within the workspace to have different memory maps. (And I would rather not split them into two workspaces.)