00:50 <blaine[m]> Hey all – Is there a "shining" example of an SPI device driver that conforms to embedded-hal 1.0's traits and does both input/output and (ideally) does so with a choice of either sync and async approaches? The drivers in the awesome embedded rust docs (https://github.com/rust-embedded/awesome-embedded-rust?tab=readme-ov-file#driver-crates) are a bit out of date, and I'm not experienced enough to gauge a "good" driver vs a

00:50 <blaine[m]> not-so-good one. If there's a driver that you're proud of or just think is great, I'd love to take a look and learn from the design!

01:09 <M762spr[m]> <blaine[m]> "Hey all – Is there a "shining..." <- I need exactly this! 😅

01:13 <M762spr[m]> specifically I am trying to do a SPI transaction with a builder pattern in my driver...

01:13 <M762spr[m]> You construct the builder with a register ID, set if it is read or write, any additional flags for the device, and then "build"/send it.

01:13 <M762spr[m]> I'm running into some snags though. I don't want to put the SpiBus and CS pin in the builder struct as it would be dropped. I thought I would just pass a reference to each and the buffer in fn send(), but the compiler complains that the associated type 'error' in ...spi::ErrorType must be specified. I'm a little stumped

02:04 <GuineaWheek[m]> how would one stop probe-rs from putting rtt into blocking mode with defmt_rtt?

06:44 <JamesMunns[m]> <GuineaWheek[m]> "how would one stop probe-rs..." <- I didn't think it does that, actually. probe-run used to do that, but I didn't think probe-rs did that yet

06:45 <JamesMunns[m]> JamesMunns[m]: https://github.com/probe-rs/probe-rs/issues/2184

06:45 <JamesMunns[m]> Is the issue to ADD support for that in the future

07:10 <danielb[m]> <JamesMunns[m]> "https://github.com/probe-rs/..."; <- > <@jamesmunns:beeper.com> https://github.com/probe-rs/probe-rs/issues/2184... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BRPtDTvcbmFNYHasaSWPilry>)

07:11 <danielb[m]> * technically, that issue is broader as @tiwalun wants to change mode for all RTT channels (for whatever reason), not just defmt. We switch to blocking by default for defmt, but the change hasn't been released yet. `cargo embed` includes an option to override this, probe-rs does not

07:13 <GuineaWheek[m]> guess we'll have to learn cargo-embed then

07:13 <danielb[m]> why are you so intent on corrupting your own log stream?

07:14 <GuineaWheek[m]> i'd rather the firmware not freeze/potentially set things on fire than have pristine logs

07:15 <JamesMunns[m]> yeah, it's a reasonable flag to have, IMO

07:16 <GuineaWheek[m]> and that fire could be literal (power electronics)

07:16 <JamesMunns[m]> with the rzcobs encoding you can recover from corrupt logs, tho IMO you might be better off dropping the level of those logs in hot loops to TRACE or something, and filtering them out at compile time

07:16 <JamesMunns[m]> you'll still pay the encoding costs (lower than fmt, but still present) if you log but discard

07:17 <JamesMunns[m]> setting the log level to DEBUG means TRACE logs don't even get compiled in at all.

07:17 <JamesMunns[m]> (and so on for all the levels)

07:18 <JamesMunns[m]> but yeah, IMO it should be POSSIBLE to control all those behaviors, it just isn't yet, and "block on logs" is a good default, IMO, as it is more predictable for people.

07:19 <GuineaWheek[m]> that makes sense

07:19 <JamesMunns[m]> Also, not sure what probe you're using, but IIRC daplink and similar are faster at RTT (through probe-rs) than JLinks, so you might get better throughput, or potentially raising your SWD link speed (this might require a shorter or better shielded cable)

07:21 <GuineaWheek[m]> i'll look into that, thanks!

07:22 <GuineaWheek[m]> side note: is there a math library that's inbetween micromath (fast, imprecise, doesn't use processor instructions) and libm (more "correct" but really slow) -- we find ourselves writing wrappers around core::intrinsics to make sure we actually use the single-precision sqrt instruction the cortex-m happens to have

07:22 <GuineaWheek[m]> (for example)

07:23 <GuineaWheek[m]> a lot of the libm routines also tend to use double-precision floats which don't mesh well when you only have single-precision going on

07:23 <JamesMunns[m]> how you're doing it is probably how I'd do it: use intrinsics or inline asm to make my own custom functions. not sure if cortex-m::asm contains those functions

07:24 <JamesMunns[m]> I haven't heard of one, it might be worth making your own crate so we can share with other folks!

07:24 <JamesMunns[m]> https://docs.rs/cortex-m/latest/cortex_m/asm/index.html

07:24 <JamesMunns[m]> I don't see any math intrinsics there

07:25 <GuineaWheek[m]> iirc not all cortex-ms have the single precision fpu

07:25 <GuineaWheek[m]> it'd be interesting to make a math library tailored to say cortex m4f though

07:26 <JamesMunns[m]> idsp is the other one that gets mentioned here

07:26 <JamesMunns[m]> https://docs.rs/idsp/latest/idsp/

07:27 <JamesMunns[m]> it might be more "big picture" than single operations tho? not sure

07:27 <JamesMunns[m]> also also I think there's a wrapper for cortex-m dsp: https://docs.rs/cmsis_dsp/latest/cmsis_dsp/

07:27 <JamesMunns[m]> again, might be more "big picture"

07:30 <GuineaWheek[m]> idsp looks cool

07:30 <JamesMunns[m]> yeah, the stabilizer folks use it pretty heavily

07:30 <GuineaWheek[m]> stabilizer?

07:31 <JamesMunns[m]> https://github.com/quartiq/stabilizer

07:54 <ryan-summers[m]> Feel free to ping me or Robert (@jordens) with questions on idsp :) The whole point of idsp is to be super fast and use architecture intrinsics wherever possible

07:54 <ryan-summers[m]> idsp has largely been optimized for use with the M7F core, but I imagine it should still work quite well on m4

09:31 <thejpster[m]> restarted the Arm target docs update in https://github.com/jonathanpallant/rust/pull/2

09:32 <thejpster[m]> I'll update it later with the target-cpu and target-feature tables. Feel free to send PRs to my branch so we can collate all the changes together and then send an upstream PR.

09:46 <RobertJrdens[m]> <thejpster[m]> "I'll update it later with the..." <- Awesome! Do you plan on adding material from your hackmd on the target-feature stuff as well?

09:55 <thejpster[m]> yes. that's the target-cpu and target-feature tables bit

13:54 <Ecco> Hi! Is it possible to have "cargo test" run tests on the host?

14:06 <JamesMunns[m]> In a `bin` project, probably not, or it would be fairly hacky.

14:06 <JamesMunns[m]> In a `lib` project, definitely!

14:09 <JamesMunns[m]> The general suggestion for testing is to push as much "logic" into a library crate, that isn't hardware specific (e.g. it uses `embedded-hal(-async)` traits and not specific hardware, like `embassy_stm32`), and use something like `embedded-hal-mock` or your own trait impls for testing.

14:09 <dngrs[m]> <JamesMunns[m]> "also also I think there's a..." <- > <@jamesmunns:beeper.com> also also I think there's a wrapper for cortex-m dsp: https://docs.rs/cmsis_dsp/latest/cmsis_dsp/... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cmPlDaGvdxLGRsVyjpEPRsKz>)

14:10 <dngrs[m]> <Ecco> "Hi! Is it possible to have "..." <- this blog post goes into detail: https://ferrous-systems.com/blog/test-embedded-app/

14:10 <JamesMunns[m]> dngrs[m]: I think that's the opposite, that's cargo test on the target :)

14:11 <dngrs[m]> (imho needing two nested workspaces is indicative of cargo needing some improvements, but that's another discussion…)

14:11 <dngrs[m]> JamesMunns[m]: it has a section on host testing

14:11 <JamesMunns[m]> ah, that's true!

14:12 <JamesMunns[m]> also, I forget how long postcard has been around. I was a little surprised they were mentioning it in that blog post :p

14:13 <dngrs[m]> it would've been clearer if I had said "this blog post discusses a thorough approach for testing an embedded project - target-only, host-only and with host-target communication"

14:28 <dngrs[m]> I do wonder about the nested workspaces thing though. Are we stuck in a local maximum with cargo?

14:33 <thejpster[m]> OK I think I'm done: https://github.com/jonathanpallant/rust/pull/2

14:33 <thejpster[m]> I really hope I'm done.

14:38 <JamesMunns[m]> <dngrs[m]> "I do wonder about the nested..." <- IMO cargo workspaces really don't handle multiple *kinds* of targets well at all. I think there are some things that are in progress now (like the nightly cargo features we use in mnemos) that *improves* that, but tbh it's an edge of the tool that doesn't work well.

14:39 <JamesMunns[m]> it should be better, but I think someone needs to explain HOW it could be better, what needs to be done to get there, and how to avoid any currently tools (incl R-A and cargo extensions), and then do that work

14:39 <dngrs[m]> Glad to hear there's some progress tho

14:40 <dngrs[m]> Yeah...

14:40 <JamesMunns[m]> it's not IMPOSSIBLE (afaik), it's just a lot of work to get there, and IMO, I think you'd lose a lot of benefits of workspaces to begin with (since you need to recompile deps for multiple targets anyway!)

14:40 <dngrs[m]> Maybe have a hackmd or GH issue where we collect pain points?

14:41 <JamesMunns[m]> That, and `cargo` is pretty bad in the "People Who Have Loud Opinions" to "People Who Maintain and Make Improvements" ratio, historically

14:41 <JamesMunns[m]> s/People/Users/

14:41 <JamesMunns[m]> (might be better in recent years, I think RF is possibly paying maintainers? not sure tho)

14:41 <dngrs[m]> Hmrngh.

14:41 <dngrs[m]> Ok maybe something for an upcoming agenda..

14:42 <JamesMunns[m]> Honestly, like many things, it's "will someone/some people show up and have energy for a (positive) fight and make it happen"

14:42 <JamesMunns[m]> cargo needs a few heroes, for sure :)

14:43 <dngrs[m]> Yeah, I'm not against working doing that myself

14:44 <dngrs[m]> But not if I'm the only one interested

14:44 <dngrs[m]> I'll bring it up in some ewg meeting I guess

14:44 <JamesMunns[m]> I'd like it to work (waves hands) nebulously better for multiple targets! let me give you some notes I have

14:46 <JamesMunns[m]> https://github.com/jamesmunns/bad-workspace/commits/main/

14:46 <JamesMunns[m]> step by step "how setting up a multiarch workspace usually fails"

14:47 <JamesMunns[m]> IIRC this highlights the "shared dep with mutually exclusive features", but I think it also touches on some other issues that are potentially work-around-able

14:47 <dngrs[m]> Sweet, thanks!

16:25 <feerless[m]> Hello, I am pretty new to embedded and new to rust. I have done some embedded in C. Do I need to take any rust specific aspects into account when selecting MCs, etc

16:25 <feerless[m]> Is it safe to assume that if C was able to compile for the MC, then rust will do the same?

16:29 <Benn[m]> I'm also fairly new to doing embedded in rust, but the answer seems to be "there's support for a lot of MCUs, but its not guaranteed". also just because your MCU is supported, doesn't mean your particular board is defined. I'm currently translating the pin assignments from an arduino board to rust for a supported MCU (nRF52840 MCU, board is a XIAO BLE). it sure seems to work, there's just extra C-spelunking to make it work

16:32 <JamesMunns[m]> In general, if the MCU is `cortex-m`, Rust will probably handle it. If it's `risc-v`, it'll PROBABLY work. Otherwise, if `clang` specifically can support it (e.g. LLVM based, not GCC based?), there's a good chance Rust CAN support it, but it might be some work.

16:32 <JamesMunns[m]> The next step is "are there drivers for this chip", which will take some more searching.

16:34 <Lumpio[m]> The real problem with pin mappings is board manufacturers being "helpful" and coming up with arbitrary pin naming schemes instead of just using, you know, the actual pin names on the chip (anything that starts with A and ends with rduino is often pretty egregious about this)

16:34 <Benn[m]> ^ yeah this. having to delve through several header/source files to find what the actual mapping to the underlying pin is actually called is "Fun"

16:35 <feerless[m]> can't you just look at the data sheet?

16:35 <Benn[m]> at least in my case, the board doesn't have a datasheet for how they've assigned the nRF52 pins, and the nRF52 lets you do whatever you want

16:36 <Benn[m]> for the qspi interface, nordic has some recommendations, but lets you use whatever pins you want, really

16:36 <Benn[m]> so the nrf52-dk (development kit) qspi pinout is different from my board

16:38 <dngrs[m]> don't you just love it when chip pin 27 is GPIO4 is board pin 15

16:38 <dirbaio[m]> pin mapping is usually in the board's documentation, either in text form in some datasheet/manual or in schematics.

16:39 <dirbaio[m]> if it's completely undocumented except in C code it's a problem of bad documentation.

16:39 <Benn[m]> it is in the schematic, the C code is just easier to read

16:40 <Benn[m]> also since that's from the code people are using, i trust it more than a document that is not executed

16:40 <dirbaio[m]> i've never had to read C code to figure out pinouts for many stm32 and nrf boards 🤷

16:41 <feerless[m]> what is a good JTAG capable programmer. I hate how the one I have right now won't let me debug

16:42 <Benn[m]> there actually is a decent pinout spreadsheet for this board, i just missed it somehow

17:40 <LiamRosenfeld[m]> Hi! I have been using the ssd1306 crate on 0.7 for a while now. However, once I updated to 0.8, it now longer draws properly. It is drawing strangely (the top left corner is in the middle of the display with the overflow wrapping). Has anyone else run into this issue. And if so, how did you fix it?

17:40 <LiamRosenfeld[m]> * Hi! I have been using the ssd1306 crate pinned to 0.7 for a while now. However, once I updated to 0.8, it now longer draws properly. It is drawing strangely (the top left corner is in the middle of the display with the overflow wrapping). Has anyone else run into this issue. And if so, how did you fix it?

17:46 <LiamRosenfeld[m]> * Hi! I have been using the ssd1306 crate pinned to 0.7 for a while now. However, once I updated to 0.8, it now longer draws properly. It is drawing strangely (the top left corner is in the middle of the display with the overflow wrapping). Has anyone else run into this issue. And if so, how did you fix it? I'm just drawing bitmaps onto the display.

21:24 <slabity[m]> So I'm still learning how to use `embassy` effectively and I'm struggling with how to handle defining tasks to handle hardware functions. For example, I have this awful function signature here: `async fn adc_task(i2c: i2c::I2c<'static, peripherals::I2C1, i2c::Blocking>, mut interrupt: gpio::Input<'static, peripherals::PIN_13>)`

21:24 <slabity[m]> This technically works, but I really don't like that I'm explicitly saying it *needs* to take `I2C1` and `PIN_13`. But if I make it a generic then it complains that task functions cannot take generics.

21:29 <slabity[m]> I can technically pass the I2C and interrupt pins as an AnyPin, but then I need to do the setup for that completely in the task itself and I'm not sure how to handle errors in that situation.

21:31 <slabity[m]> And not sure if I can technically even do that with the I2C pins as AnyPin can't implement the SclPin or SdaPin traits required to set that up

21:33 <dirbaio[m]> for the gpio you can use AnyPin

21:33 <dirbaio[m]> in embassy-rp git master the generic param for the pin is completely removed, it's `Input<'static>` now.

21:34 <dirbaio[m]> and the plan is to get rid of more generics in the future

21:34 <dirbaio[m]> for example i2c will be just `I2c<'static, Blocking>`

21:34 <slabity[m]> Oh, well that's convenient

21:34 <dirbaio[m]> so tldr yes: we know the generics are not great :P

21:35 <dirbaio[m]> there's some work alreayd started on removing them... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KkeWhOuAFgyRAYWMStVikCTY>)

21:35 <dirbaio[m]> but it'll take a while 🫠

21:35 <dirbaio[m]> in the meantime you'll have to write `I2c<'static, I2C1, Blocking>`

21:36 <dirbaio[m]> you can use type aliases to "centralize" all the peripheral definitions in a single place if you want to

21:36 <dirbaio[m]> or there's https://github.com/adamgreig/assign-resources

21:36 <slabity[m]> Fair enough. I am just glad I wasn't crazy and creating awful abominations of function signatures.

21:36 <slabity[m]> I can definitely use the master branch