ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<dygear[m]> Has anyone here used the 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.
<morfertaw[m]> <morfertaw[m]> "The report I am sending is as..." <- After looking at the source code for the [HidReader]( I do not think the [RequestHandler]( has anything to do with writing reports to the host.
<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.
<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.
milan[m] has joined #rust-embedded
<milan[m]> does anyone know a good crate alternative to FastLED? (focus on "fast")
<morfertaw[m]> <morfertaw[m]> "After looking at the source code..." <- I managed to get the reports with ids to work 🎉.
<morfertaw[m]> morfertaw[m]: I changed the report descriptor to the following.
<morfertaw[m]> ```
<morfertaw[m]> ```rust
<morfertaw[m]> * I changed the report descriptor to the following.... (full message at <>)
<morfertaw[m]> * I changed the report descriptor to the following.... (full message at <>)
<morfertaw[m]> morfertaw[m]: I removed the following part from the keyboard report with report id of 1.... (full message at <>)
<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 <>)
<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. ❔
<morfertaw[m]> * I managed to get the reports with ids to work. 🎉
<sirhcel[m]> <milan[m]> "does anyone know a good crate..." <- Have you checked out the [`smar-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.
<sirhcel[m]> > <> does anyone know a good crate alternative to FastLED? (focus on "fast")
<sirhcel[m]> * Have you checked out the [`smar-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.
MathiasKoch[m] has joined #rust-embedded
<MathiasKoch[m]> Does anyone know of a thiserror style crate, but for defmt? And if not, has anyone considered creating one?
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
alexmoon[m] has quit [Quit: Idle timeout reached: 172800s]
badyjoke[m] has quit [Quit: Idle timeout reached: 172800s]
AtleoS has joined #rust-embedded
fuse117[m] has joined #rust-embedded
<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.
<JamesMunns[m]> you should be able to use GDB to single step, or set breakpoints, perhaps even conditional breakpoints
FreeKill[m] has joined #rust-embedded
<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?
danielb[m] has joined #rust-embedded
<danielb[m]> probe-rs may or may not work, but I'd love to hear about it - feedback helps us improve
RobertJrdens[m] has joined #rust-embedded
<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.
<MathiasKoch[m]> Could settle for the display part, but yeah, the whole thing would be amazing 😅
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<RobertJrdens[m]> <MathiasKoch[m]> "Could settle for the display..." <- The `source()` stuff should work verbatim.
<RobertJrdens[m]> Somebody should try it! 😉
<RobertJrdens[m]> And tere's
<FreeKill[m]> I can confirm that probe-rs does work debugging into C libs!
<FreeKill[m]> Including breakpoint
<FreeKill[m]> * Including breakpoints
<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 :)
<FreeKill[m]> I'm sure :P This was linked to a an archive produced by arm-none-eabi-gcc
<FreeKill[m]> s/a//
<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
<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"
<JamesMunns[m]> s/with/without/
<danielb[m]> JamesMunns[m]: this doesn't help me much as the implementor right now 😅
<fuse117[m]> FreeKill: can you share that little project?
<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)
<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
<FreeKill[m]> But the relevant bits are...
<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`/
<danielb[m]> O0 and -g3 gave you "variable optimized out"? 😱
<danielb[m]> * O0 and -g3 gave you "value optimized out by compiler"? 😱
<danielb[m]> danielb[m]: James Munns: this is what you mean by ` (and using GCC for linking does that implicitly!)` is it 🤦‍♂️
<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.
<FreeKill[m]> it can :)
<FreeKill[m]> Or at least flto is an arg you can pass and break things with, cos I've done it 😆
<JamesMunns[m]> FreeKill[m]: then I was just wrong :D
<FreeKill[m]> Whether it works or not is another question ;D
<JamesMunns[m]> That I definitely have no idea about :D
<FreeKill[m]> This was a discussion at my job, where I suggested pushing more code into modules, separation of concerns etc
<FreeKill[m]> Was told that they were worried that would lead to poor performance due to the indirection
<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
<danielb[m]> just don't tell me their answer was "we can't trust optimisers because they miscompiled our code in 1986"
<FreeKill[m]> 🙃
<FreeKill[m]> If -O0 was good enough for ada lovelace it's good enough for us
<avery71[m]> <danielb[m]> "just don't tell me their..." <- Something something on trusting trust by Ken Thompson
<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
mali[m] has joined #rust-embedded
<mali[m]> So ferroscene shares everything upstream with the rust toolchain, is that right?
<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)
<JamesMunns[m]> err, maybe not rolling release - it trails the upstream project, but aims to track it 1:1, not maintain external patchsets
<JamesMunns[m]> but on a slower release cadence (not sure what they are targeting)
<mali[m]> I assume that it can only track with a delay, right?
<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
<mali[m]> I see.
<mali[m]> Although their toolchain is ISO26262, does not mean that rustc is.
<mali[m]> You must use ferroscene to ensure that.
<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.
<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)
<JamesMunns[m]> qualification is a lot of QA and due diligence and long term support and proactive maintenance.
<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
<JamesMunns[m]> not sure if I track what you mean
<mali[m]> Argh, maybe sth that I overheard erroneously.
<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.
<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)
<mali[m]> I thought that the latest toolchain is available to check, but earlier releases require a licence
<JamesMunns[m]> I think you can use their artifacts for trial, but that doesn't get you license to use them for real releases
<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"
<mali[m]> Yeah, of course.
<mali[m]> Really a great thing to have.
<JamesMunns[m]> like, informally, I think you can just use it, as a "try before you buy".
<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)
<JamesMunns[m]> * or GCC (for C/C++), so
<mali[m]> Thanks James Munns this will help a lot when I pitch it to the company.
<mali[m]> Kids are taking the house down now tho, gotta go.
<fuse117[m]> FreeKill: can you share the Test configuration in your launch.json
<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
<fuse117[m]> any attempt to inspect the variables kills the session too
<FreeKill[m]> yeah i dont think i can inspect variables
<FreeKill[m]> with cortex-debug (gdb) i can
<fuse117[m]> i am looking into cortex-debug right now
<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
<danielb[m]> hmm can you folks get me a .elf and a coredump of the whole RAM and ROM address ranges?
<danielb[m]> in the Debug Console you can type something like dump 0x20000000 0x3000 0x0 11200 out.coredump
<danielb[m]> s//`/, s//` (where 0x3000 is the size of my device's RAM, and 11200 is the size of the binary)/
<FreeKill[m]> that command doesnt do anything for me in probe-rs?
<danielb[m]> mm let me double-check quick, maybe there's a difference between the cli and the debug console :/
<danielb[m]> should work :/
AtleoS has quit [Ping timeout: 246 seconds]
<FreeKill[m]> let me update
<FreeKill[m]> yep just a version thing
<FreeKill[m]> fuse117: updating probe has also fixed seeing C vars
<FreeKill[m]> for me
<FreeKill[m]> (0.23.0)
<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
<fuse117[m]> i just updated and still can not view vars
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]> Is there a Matrix channel for defmt?
<dirbaio[m]> but it's not active at all
<PhilMarkgraf[m]> dirbaio[m]: Wow! Not for nearly a year. In that case, where is the best place to ask questions about defmt? Here?
<dirbaio[m]> here I guess
<dirbaio[m]> or if you want to ask / tell the actual maintainers something, github probably
Foxyloxy has quit [Quit: Textual IRC Client:]
Foxyloxy has joined #rust-embedded
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy has quit [Quit: Textual IRC Client:]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Quit: Textual IRC Client:]
Foxyloxy has joined #rust-embedded
KurtisDinelle[m] has quit [Quit: Idle timeout reached: 172800s]
<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"?
<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.)