00:29 <GrantM11235[m]> I want to run a command line/TUI on an embedded device over serial, are there any existing libraries to help with that? I want something that can handle the escape sequences for backspace and arrow keys

04:52 <dngrs[m]> <GrantM11235[m]> "I want to run a command line/TUI..." <- not exactly what you're looking for but there is https://crates.io/crates/noline

06:51 <FrreJacques[m]> I have a design question:

06:51 <FrreJacques[m]> I've read somewhere that it's a good practice in Rust in general to create destructors freeing ressources.

06:51 <FrreJacques[m]> I wondered if the same holds true in embedded, when something owns a pin. Because the pins are usually physically bounded, I can't see a usecase. But I am a noob so idk.

07:40 <Darius> conceivably your pin could change, eg I2C to GPIO to manually crank SCL to unstick a bus

07:40 <Darius> however.. the destructor is trivial or even nonexistent in that case

08:04 <FrreJacques[m]> So if I have a struct owning the pins, I should provide a destruct method that simply has a signature

08:04 <FrreJacques[m]> `pub fn drop(self)`?

08:05 <JamesMunns[m]> drop is usually the implementation of the Drop trait, usually you have some other name

08:05 <JamesMunns[m]> but yeah, something like `fn release(self) -> Parts` is decently common

08:05 <FrreJacques[m]> Or do I have to return the pin structs?

08:06 <JamesMunns[m]> you'd ideally need to return all the parts, otherwise people need to use unsafe to recreate the parts

08:09 <FrreJacques[m]> Ah, okay so I probably return a touple like (pin1, pin2,...) so the user xan deconstruct it and receives the thing they inputted on creation back.

08:09 <FrreJacques[m]> Is it a good idea to put them in a defined state before returning?

08:10 <JamesMunns[m]> Sort of up to you, worth documenting it either way.

08:13 <FrreJacques[m]> embassy_stm32::gpio provides an initial value for Output. I had the idea that this is stored and can be used, but I think it's of no help, because the ehal trait would not have a method anyways. So I will put them to low and document that. Thanks!

08:59 <FrreJacques[m]> Does anybody know a good introduction to testing in embedded?

08:59 <FrreJacques[m]> I found this here, but don't know how representitive it is:

08:59 <FrreJacques[m]> https://hackaday.io/page/21907-test-driven-embedded-rust-development-tutorial

09:13 <wassasin[m]> Frère Jacques: I use `embedded-hal-mock` to test I2C and SPI based peripheral drivers all the time. For complete applications I think you will bump into practicalities of not having good abstractions over the hardware to properly test. Depends mostly on how complex your application is though

09:19 <FrreJacques[m]> Ah thx. I will have a look on that too.

09:19 <FrreJacques[m]> I think for that driver project it's not absolutely necessary, but I sinply want to learn good practice. And putting something online, linkable to me, I want it to have a reasonable quality.

10:53 <Lumpio-> The effectiveness lf testing hardware drivers against mocks is down to how precisely you can emulate the hardware

10:54 <Lumpio-> Tests like that help to catch cases where something was broken by accident by some changes, but they don't replace tests against the actual hardware

11:33 <thejpster[m]> is anyone around to bounce some questions off? I am not seeing any interrupts fire on Core 1 of my RP2040.

11:58 <thejpster[m]> hmm, I can kick off a SW5 IRQ, so interrupts are running. Maybe the question is, why isn't PIO0 firing IRQ1 on Core 1?

12:00 <thejpster[m]> and I can manually pend a PIO0_IRQ1 so that works. So why isn't my PIO state machine running and firing this IRQ?

12:03 <FrreJacques[m]> <Lumpio-> "The effectiveness lf testing..." <- Yes, testing against other systems and best practice is still some kind of unfamilar to me, not only in this area.

12:03 <FrreJacques[m]> I just want to get into it and maybe have it as some protection against accidentily screwing things up, if I didn't touch it for longer periods.

14:42 <Nate[m]1> Question about unit testing in the no_std environment. I've seen a few conflicting approaches dated from a couple of years ago, but I'm wondering what is the recommended way to write unit tests nowadays?

14:45 <JamesMunns[m]> I think you're going to get a lot of differing opinions

14:47 <JamesMunns[m]> if you want mine:

14:47 <JamesMunns[m]> * test your business logic in CI, use existing abstractions like embedded-hal and embedded-hal-mock to handle the different layers, particularly with things like embassy that have `std` impls, it's not usually terrible. You generally need to split out this layer into a crate so you can test it on the desktop

14:47 <JamesMunns[m]> * test your hardware drivers experimentally with test bins, or instrumentation commands. Hardware usually doesn't change out from under you, so once the driver works, it generally keeps working

14:48 <JamesMunns[m]> I'm not *personally* a big fan of "on device" testing, at least outside of cases like embassy's CI, where they ARE changing the drivers pretty continuously. "end projects" tend to have much less churn, and you can re-run your test bins if you ever need to update hardware drivers to "re-qualify" the stack

14:50 <JamesMunns[m]> (this is for unit testing, at least, hardware in the loop is a slightly different case, but it has a different cost:benefit ratio to consider)

15:14 <Nate[m]1> <JamesMunns[m]> "if you want mine:..." <- I appreciate the input,

19:32 <Ralph[m]> <JamesMunns[m]> "(this is for unit testing, at..." <- does anyone have any input / recommended reading on HIL testing? genuinely interested in this topic as i'll be doing something there in the not-too-distant future.

21:13 <bitts[m]> <Ralph[m]> "does anyone have any input..." <- Ferrous wrote some articles on embedded rust testing (on of which is on HIL). They are from 2021, so not sure if they still are considered good practice or not: https://ferrous-systems.com/blog/tags/embedded-rust-testing/