<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.
<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.
<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?
<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 :)
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?
<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
<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]>
<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]