ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
stuw1 has quit [Ping timeout: 264 seconds]
<PhilMarkgraf[m]> Are you segregating the test-only dependencies into [dev-dependencies] in your Cargo.toml file?
<PhilMarkgraf[m]> I'm not a fan of TDDing driver code, as you get into being a simulator writer. (If there is NO hardware to test, simulating it in TDD+mock can be valuable.)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZkpRLNlBTTsXbsIxWzcCqCPZ>)
<PhilMarkgraf[m]> * I'm not a fan of TDDing driver code, as you get into being a simulator writer. (If there is NO hardware to test, simulating it in TDD+mock can be valuable.) I'd much rather build test-automation around the HIL test-stand to get coverage on the drivers.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MyPRPMccjYFfRIhiuSMspouQ>)
<M9names[m]> Sorry, are you implying it's only tdd if you're using mocks?
<M9names[m]> Surely you can do tdd against hil and it's still tdd.
notgull has quit [Ping timeout: 264 seconds]
<PhilMarkgraf[m]> Can you move the non-hardware stuff into a separate directory, and separate each into a different "workspace" using their Cargo.toml files.
<PhilMarkgraf[m]> Ferrous did a blog on how to do this. Let me find it.
<PhilMarkgraf[m]> * find it... here we are... https://ferrous-systems., * .com/blog/test-embedded-app/
<PhilMarkgraf[m]> I am using this in my project and I have a mix of my embedded application, several embedded test applications, the hil test-stand software (workstation) and several factory/debug software items (workstation)... all in one repository. The only content I've put in "other" repositories are drivers that we have open-sourced.
stuw1 has joined #rust-embedded
<PhilMarkgraf[m]> hadez: The workspaces are not that hard. I promise. And they do a great job of segregating your testable code from your embedded code.
<PhilMarkgraf[m]> * hadez: The workspaces are not that hard. I promise. And they do a great job of segregating your testable code from your embedded code.
<PhilMarkgraf[m]> I do not know of another working solution for what we are trying to do with TDD for embedded.
cmaiolino2 has quit [Quit: WeeChat 4.0.4]
IlPalazzo-ojiisa has joined #rust-embedded
djdisodo[m] has joined #rust-embedded
<djdisodo[m]> here's my async usart driver for avr(atmega328p supported)
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<thejpster[m]> does anyone have a good example of using usb-device (e.g. in conjunction with usbd-serial or usbd-hid) that doesn't involve the use of static mut? It looks like UsbBusAllocator is !Sync, which seems like it should limit its use as a global variable.
<thejpster[m]> But I think using static mut bypasses that?
<thejpster[m]> (static FOO: *const u8 = std::ptr::null(); is a build error but static mut FOO: *const u8 = std::ptr::null(); is not)
<thejpster[m]> it looks tricky to wrap in a c-s Mutex because the Usb Serial device needs to hold a reference to the UsbBusAllocator, so you have to make sure it doesn't move? Or rather, it looks like it holds a &AtomicPtr - not sure what that's about.
<Lumpio[m]> Yeah that thing was obviously designed by somebody new to Rust and not very good at it yet. It should get an architectural rewrite.
zyxy has joined #rust-embedded
<thejpster[m]> The bus allocator is a static inside fn main, and the device, serial and hid objects bounce via a Mutex<RefCell<Option<foo>>> into a static mut Option<Foo> in the interrupt.
<thejpster[m]> Score one for static-mut support inside interrupts and fn main, otherwise this would be a lot messier.
zyxy has left #rust-embedded [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
<Lumpio[m]> (N.b. the new to Rust and not very good at it person was me years ago)
<mameluc[m]> can I get defmt output and debug at the same time with vscode + GDB?
<dirbaio[m]> cargo-embed can do that
<dirbaio[m]> alternatively the probe-rs-debugger vscode extension can do it, but it's not gdb
<thejpster[m]> I think probe-rs can also start a GDB server?
<mameluc[m]> hmm maybe I am not even running GDB
<mameluc[m]> this is using DAP
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
<mameluc[m]> ah those are different
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Client Quit]
<thejpster[m]> hardest thing in computer science
<Ecco> Do you guys know why there would be a "nmagic" linker flag in use in Embassy?
<JamesMunns[m]> Uh, that has to do with "sections not multiples of 4K" or something
<JamesMunns[m]> the defmt-template explained it, gimme a sec
<Ecco> Oh wow
<Ecco> Thanks!!
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiis1 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Remote host closed the connection]
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
<Ecco> Hmm, weird: I don't get any defmt message when running with probe-rs, yet I *do* get panic messages through panic-probe
Foxyloxy has quit [Remote host closed the connection]
<dirbaio[m]> probably missing DEFMT_LOG=trace when compilingr
<dirbaio[m]> * probably missing DEFMT_LOG=trace when compiling
<Ecco> oh, ok, thanks
Foxyloxy has joined #rust-embedded
<Ecco> (indeed, that's what it was. Thanks again!)
<thejpster[m]> I made some types to hide the Mutex<RefCell<Option<T>>> bait-and-switch dance from the user>
<thejpster[m]> s/</\</, s/</\</, s/</\</
<dirbaio[m]> embassy-usb/embassy-nrf removes the awkward UsbBusAllocator btw, you no longer need globals
<thejpster[m]> In exchange for bind_interrupts! (not sure what that does), and losing support for the 802.15.4 radio.
<dirbaio[m]> > In exchange for bind_interrupts! (not sure what that does),
<dirbaio[m]> allows the HAL to handle the interrupt for you. I wouldn't say it's a bad thing 🙃
<dirbaio[m]> > and losing support for the 802.15.4 radio.
<dirbaio[m]> PRs welcome 🙃
lch361[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> i gotta pick my battles here
<Ecco> I need to pass a 32-bit aligned pointer to a C library. How would you guys generate this in Rust?
<Ecco> I'm thinking about a static [u32], but I'm not ever sure this would be 32-bit aligned
<dirbaio[m]> the compiler automatically aligns u32's to 32bits for you, yes
<Ecco> Is this documneted somewhere?
<Ecco> (I mean, it sounds like the safe thing to be doing, but I'm just being curious here)
<JamesMunns[m]> Rust references and slices are always guaranteed to be aligned
<dirbaio[m]> it's some "inherent" property of the u32 type, it has an align of 4
<dirbaio[m]> i'm not sure where it's actually documented, that's a very good question 🤣
<Ecco> I've found std::mem::align_of_val, which works for me: I can add a compile-time assertion
<dirbaio[m]> ah right there in that doucment, nice
<dirbaio[m]> > Most primitives are generally aligned to their size, although this is platform-specific behavior. In particular, on x86 u64 and f64 are only aligned to 32 bits.
<thejpster[m]> In the target spec, with a big magic string that LLVM knows how to parse
<Ecco> If the compiler ever changes its mind, then I'd get a useful error :)
<Ecco> Yeah, so I guess the static assert is definitely the best option :)
<Ecco> dang, that's… ugly :-D
<thejpster[m]> you can also throw it in a struct and mark it align(4) or something
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> <thejpster[m]> "you can also throw it in a..." <- Note that structs and primitives are not required to have the same layout esp at FFI unless you mark them as transparent
<JamesMunns[m]> well, sorry, the LAYOUT is probably the same, the ABI is not required to be the same, AFAIK
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
elpiel[m] has quit [Quit: Idle timeout reached: 172800s]
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco> I'm writing a Rust wrapper around a library written by ST. This library expects some statically allocated buffers whose size depend on some parameters. I'd like to provide my wrapper with those *compile-time constant* parameters so the wrapper can allocate the needed buffers. How can I provide a crate with some compile-time constants?
IlPalazzo-ojiisa has joined #rust-embedded
<GrantM11235[m]> <Ecco> "I'm writing a Rust wrapper..." <- There isn't really a good way to do it, but there are a few messy options. Embassy uses a cargo feature for each possible value https://github.com/embassy-rs/embassy/blob/fb22b46ebb40c16e35c651c0dacf810126856927/embassy-executor/Cargo.toml#L105
<GrantM11235[m]> You can also pass an ENV variable at compile time
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco> Thanks GrantM11235!
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
emerent has quit [Ping timeout: 264 seconds]
emerent has joined #rust-embedded
JomerDev[m] has joined #rust-embedded
<JomerDev[m]> Hello. I'm trying to get a pico to work with the raspi probe and probe-rs. I have everything connected as shown in the pico docs and the probe seems to be connected. However no breakpoints are triggered nor does any code change I do make it to the pico after a reload. Even just using the embassy blinky example doesn't seem to have any effect on the pico, even though the build runs fine
jannic[m] has joined #rust-embedded
<jannic[m]> What exact command do you run? Is there any error message?
<JomerDev[m]> I run it through vscodes debugger with a launch.json file. No error message I can see, no output in the serial monitor but the debug console does show DAP commands being sent and responses being received
<JomerDev[m]> I also just saw that while the DAP commands are sent and received (implying a connection) the memory view in vscode says that no debugger is connected
innegatives_ has quit [Quit: Connection closed for inactivity]
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
<mameluc[m]> <JomerDev[m]> "Hello. I'm trying to get a..." <- what is reload in this context?
<JomerDev[m]> Either reloading the debugger via the vscode ui or fully restarting the debugger
<mameluc[m]> pressing the little round arrow just resets the chip afaik
<mameluc[m]> pressing stop and then f5 launches build again
<JomerDev[m]> I am now a little further where sometimes the breakpoints work, however if I comment in the code I know is crashing and want to debug no breakpoint is triggered
<mameluc[m]> if the code is not the same on screen as in flash the debugger will get confused
<JomerDev[m]> As far as I can tell it flashes fine, I've seen no errors to suggest otherwise
<M9names[m]> maybe try adding https://docs.rs/cortex-m/latest/cortex_m/asm/fn.bkpt.html# where you want to stop instead of trying to add a breakpoint dynamically?
<M9names[m]> compiler optimisations often don't leave much code behind for your debugger to put a breakpoint at
<JomerDev[m]> M9names[m]: > <@9names:matrix.org> maybe try adding https://docs.rs/cortex-m/latest/cortex_m/asm/fn.bkpt.html# where you want to stop instead of trying to add a breakpoint dynamically?
<JomerDev[m]> I've added a breakpoint to literally the first line, e.g. `let mut p = embassy_rp::init(Default::default());`
<JomerDev[m]> > compiler optimisations often don't leave much code behind for your debugger to put a breakpoint at
<M9names[m]> also worth noting that you should probably disable LTO, as it makes breakpoint debugging very painful
<M9names[m]> Jomer Dev: that code *still* might not be there. try adding it to the function instead (usually putting on on the same line as the function name or open brace is sufficient)
<mameluc[m]> JomerDev[m]: in my experience that has never failed, also vscode will move the breakpoint if it is not possible to break there I think. At least it should stop somewhere
<JomerDev[m]> Alright, adding the asm breakpoint helped, also I apparently need to disconnect and reconnect the pico every time before flashing for it to actually take the new build
<mameluc[m]> this button won't flash new binaries
innegatives_ has joined #rust-embedded
<JomerDev[m]> Ok, I've gotten a little further, by adding a breakpoint to the hard fault handler I can at least see the call stack of where it crashed 😅
<JomerDev[m]> Note, an embassy sync pipe writer with a CriticalSectionRawMutex does not work well with a (slightly modified) defmt-serial
timokrgr[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]> don't know what to say: my experience is not your experience
<mameluc[m]> I get that notification in the corner but the breakpoint "falls down" to the next place it can be. Maybe it is bc I have very unoptimized dev builds
<mameluc[m]> idk what the defaults are
<mameluc[m]> <M9names[m]> "breakpoint_not_placed.png" <- ah I get exactly this if I put it on an empty line or in the "global" space outside fns
<M9names[m]> with opt-level 0 i can put it nearly anywhere. with lto=off and opt-level=1 some lines can't be used, and it does not place a breakpoint anywhere if it fails
<M9names[m]> at least, for me. maybe i'm just lucky with software
<M9names[m]> opt-level 0 is the default for profile.dev, and that also turns off all lto. i find that it's completely unusable for firmware, so i always override it.
<M9names[m]> * unusable for my firmware, so
<GrantM11235[m]> The embassy macro and the fact that it is an async fn might also be causing some problems for the debugger
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]