07:07 <thejpster[m]> I see cortex-m got a mention here: https://blog.rust-lang.org/2025/07/03/stabilizing-naked-functions/

07:08 <thejpster[m]> It’ll be a while before our MSRV has cfg_if stabilised though.

09:36 <mkj[m]> I'm seeing quite a big performance slowdown 1.87 -> 1.88 in a benchmark doing USB transfers device->host on a stm32h7s3. ~15MB/s on 1.87, ~11MB/s on 1.87. I think the workload is mostly limited by memcpy speed, anyone seen something like that? I'll dig into it next week

09:37 <mkj[m]> similar slowdown across various optimisation levels, though optimisation levels make a big difference too. so that's a bit surprising I guess

09:55 <jason-kairos[m]> maybe related to the size improvements that were noted recently

10:38 <thejpster[m]> is this recompiling host code or device code?

10:43 <mkj[m]> device code. the host side is a kernel driver

10:45 <mkj[m]> s/87/88/

10:49 <mkj[m]> * is a linux kernel driver

11:08 <dngrs[m]> maybe new size/offset causes your binary to run into weird alignment edge cases?

11:11 <mkj[m]> dngrs[m]: yeah, seems like a possibility. that would account for it being consistent across optimisation levels too I guess

11:20 <RoyBuitenhuis[m]> On our softcore project, we generate a SVD file that uses deriveFrom to instantiate mutliple perhipherals of the same kind. svd2rust now generates core::fmt::Debug on these, but as they are type aliasses to the "base" peripheral, I get: conflincing implementation of trait `Debug` for x

11:20 <RoyBuitenhuis[m]> There is no way to disable the generation of this impl, right? How should this case be handled? Just updated from 0.28 to 0.36.1, not sure when this exactly broke, but it worked on 0.28.

11:47 <Emkanea[m]> Not sure if this is a stupid question: eh defines InputPin methods as fallible. Do you bubble Errors up or just unwrap it? For all MCUs I had to deal with this seems reasonable. Do I miss something here?

11:48 <dirbaio[m]> they're fallible to allow for gpio expanders over i2c, usb, etc

11:48 <dirbaio[m]> which is a fairly niche use case

11:48 <dirbaio[m]> as a driver author you can decide whether you want to support it or not

11:50 <Emkanea[m]> Ah this helps! I am writing a board abstraction for my actual board. So here I know it is infallible as I am not using expanders or similiar. Thanks

11:50 <dirbaio[m]> For normal mcu GPIOs, HALs implement them with type Error = Infallible which is an uninhabited type, so at least if you do choose to bubble up the errors it'll compile to nothing when someone uses your drivers with a normal mcu gpio.

11:50 <dirbaio[m]> so theres' no runtime cost or code size downside

11:50 <dirbaio[m]> but yeah it's more code

12:01 <RoyBuitenhuis[m]> <RoyBuitenhuis[m]> "On our softcore project, we..." <- Hmm, the first instance of the deriveFrom uses the same base addr, so the type alias the same. Maybe this is technically just a svd error. Just anoying that it broke here.

12:41 <burrbull[m]> <RoyBuitenhuis[m]> "Hmm, the first instance of the..." <- if you could not find error, open issue in svd2rust repo and attach the SVD

14:36 <Ralph[m]> James Munns: i get the following warning when my test stops while it's executing the drop handlers (i see log output from one of my drop handlers before):... (full message at <https://catircservices.org/_irc/v1/media/download/AVnIoDJe1X9sYvrH8ufC6r-NSfbn0WEZnl-khEfwOv-Vmp0p2vB3JrDgkAiyUGTLV4gn2lX1s3bUAKX3ONe-no2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9McHNKVldxUVdFZFBTS0hkU2JLTWl0cWc>)

14:39 <JamesMunns[m]> Open to a better log message, right now the code doesn't really understand the difference between an "intentional close" and "the sender may have panicked or something and now the channel is closed"

14:39 <JamesMunns[m]> so, you'll get the same worker if whatever is feeding the worker panics, or if you intentionally close the worker.

14:39 <Ralph[m]> ah, so this is always logged and not just some corner case where i'm holding things wrong?

14:39 <JamesMunns[m]> You could drop that to an `info!` level and remove the "this could be bad" log

14:39 <JamesMunns[m]> https://github.com/jamesmunns/postcard-rpc/blob/10a1f6a6697c556eb07d9dec6bfd804e14830c5b/source/postcard-rpc/src/host_client/util.rs#L178-L193

14:40 <JamesMunns[m]> yeah, that log just means "the channel feeding the output worker has closed, and the output worker will stop now"

14:41 <JamesMunns[m]> I guess there's some kind of explicit cancellation, since THAT log is hitting instread of the `cancel_fut` in the async fn above, it means the channel is closing without the user explicitly calling cancel

14:41 <Ralph[m]> ok, i'll send you a PR to change it to info as you suggested if you think that's the way to go.

14:41 <Ralph[m]> alternatively there could be an explicit "i really want to stop you now" API which needs to be called by the consumer to prevent the log entry (e.g. from a custom drop handler of the struct holding the client), but that feels wrong

14:41 <JamesMunns[m]> Ralph[m]: There is one, and you're not hitting it if that log is displayed

14:42 <JamesMunns[m]> https://github.com/jamesmunns/postcard-rpc/blob/10a1f6a6697c556eb07d9dec6bfd804e14830c5b/source/postcard-rpc/src/host_client/util.rs#L160-L176

14:43 <JamesMunns[m]> That log probably happens if you just drop all HostClient instances, which means there are no more producers, which means the consumer is closed

14:44 <JamesMunns[m]> You could add a drop impl to HostContext that calls the explicit stopper I guess, or we could make the log not be as misleading that this could be a "bad" thing, it happens both when things ARE bad, but also when you naturally just drop the last host client.

14:45 <JamesMunns[m]> You could add a drop impl to HostContext that calls the explicit stopper I guess, or we could make the log not be as misleading that this could be a "bad" thing, it happens both when things ARE bad, but also when you naturally just drop the last host client.

14:45 <JamesMunns[m]> edit: it would be a bit of work to do the drop impl, HostContext doesn't have a stopper handle atm, we could add it, but not sure how much value it would bring.

14:51 <Ralph[m]> <JamesMunns[m]> "That log probably happens if you..." <- yeah, my struct has a single entry: `client: HostClient<WireError>,`... (full message at <https://catircservices.org/_irc/v1/media/download/AfmROBHdPhXNWGTnHsW0YtWbk61gzqrN8PyHHznApartKOvx7V39XBC7Sx75m_nYuy8Sx6rbD79-QbsRYp8oGrK_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9pVlpwT3ppR0lSV3l3dHNDbGZnbmJURVg>)

14:52 <JamesMunns[m]> The HostContext is shared between the instances of the HostClient (and maybe the worker tasks? if so: then a drop impl won't help since the worker tasks will still hold it).

14:52 <JamesMunns[m]> That stopper can be called by a method on the HostClient

14:53 <JamesMunns[m]> https://docs.rs/postcard-rpc/latest/postcard_rpc/host_client/struct.HostClient.html#method.close

14:57 <Ralph[m]> JamesMunns[m]: ah, so i should just add an `impl Drop` for my own `struct` and call that there?

14:57 <Ralph[m]> sorry, i missed that!

14:58 <JamesMunns[m]> You could, but you shouldn't have to :)

14:58 <JamesMunns[m]> I'd probably say the easiest fix is to just drop the `warn!` to an `info!` and just say "worker task is closing", and remove this "this might be bad" part

14:59 <JamesMunns[m]> We don't really need to do a lot more, things automatically get cleaned up, regardless of why the client handles are gone (natural drop or panic)

14:59 <thejpster[m]> new release of derive-mmio just came out - fixes a soundness issue where an API should have been unsafe but wasn't.

15:06 <thejpster[m]> I've been using derive-mmio (and bitbybit) to write a new PAC/HAL for use in a safety-critical system and next time I find a new chip, I might just use it instead of finding my way through bugs in SVD files.

15:07 <Ralph[m]> <JamesMunns[m]> "You could drop that to an `info!..." <- done: https://github.com/jamesmunns/postcard-rpc/pull/126

15:07 <Ralph[m]> (no need for an immediate release from my side)

15:20 <nerwalt[m]> Are there any tools to monitor/profile stack usage in embedded Rust? If so, what is recommended?

15:56 <Kert[m]> <nerwalt[m]> "Are there any tools to monitor/..." <- I just added stack usage tests in one of my projects. In short: https://github.com/kaidokert/picojson-rs/blob/main/avr_demo/src/stack_measurement.rs

15:56 <Kert[m]> Watermarking

15:56 <Kert[m]> Kert[m]: Same principle works on Cortex-M and anywhere else of course. On host, one of the tricks is to run your test suite in a separate thread that has a fixed stack allocation, and watermark it

15:57 <Kert[m]> Kert[m]: Test results here: https://kaidokert.github.io/picojson-rs/

15:59 <nerwalt[m]> Kert[m]: Thanks for sharing. I have read about watermarking and have been thinking about using it, but was curious to know if there were other ways.

16:00 <Kert[m]> nerwalt[m]: In theory, there are analysis tools as well that figure out the max depth. I still would trust watermarking in a real world test :) call it superstition

16:02 <nerwalt[m]> Kert[m]: the idea is pretty simple. im going to use your stack_measurements module to see what i get

16:04 <Kert[m]> nerwalt[m]: I have a cortex-m version as well somewhere, i don't think it's in public repo but i can push it somewhere

16:04 <nerwalt[m]> Kert[m]: if you can, that would be great. im working on cortex-ms

16:06 <firefrommoonligh> nerwalt[m]: V interesting. I'm hitting RAM and flash issues RN, and this might help. I'm using a low-mem STM32 variant for this (oops), and have USB/LoRA/UART buffers, as well as in-mem storage that is hitting the limit

16:06 <firefrommoonligh> firefrommoonligh: And had to optimize the bin in cargo.toml for size to not overflow the flash

16:06 <Kert[m]> nerwalt[m]: i'll get to it late tonight, will ping back here

16:06 <firefrommoonligh> Kert[m]: (The answer here btw, is get a higher-memory stm32 variant, but tools like you posted will help!)

16:11 <k3ma[m]> Hello, I'm new to Micro Controllers and embedded and running through the discovery embedded book. I think I'm having trouble with flashing my micro::bit. I'm following the steps in outlined in the book, and ran through about 5 times now making sure everything is followed, but when I check the source code using `layout src my code that should be flashed over isn't showing.

17:02 <Kin-o-matix[m]> <thejpster[m]> "I've been using derive-mmio (and..." <- I take it you have to manually write out the registers and blocks then though?

17:29 <sourcebox[m]> I'm just trying to get the initial startup of the dual-core STM32MP1 working. So far, I have individual startup code for the cores in .s files. I can sucessfully boot into separate main functions for each core. What I want achieve is starting the second core via a closure like done with ESP32 or RP2040/RP2350. But I have not found any way yet to sucessfully move the closure with all captures to the second core.

17:30 <sourcebox[m]> I already tried to do it the way it is done in esp-hal here: https://github.com/esp-rs/esp-hal/blob/b2c3b1d9bb7a8a992efc75e64dbf07ecd22aacd0/esp-hal/src/soc/esp32s3/cpu_control.rs#L271

17:32 <sourcebox[m]> But for whatever reason, the compiler removes the code of the entry function because it is not called directly.

17:32 <sourcebox[m]> That's obvious, but how can it work on ESP32 then?

17:33 <JamesMunns[m]> linker script KEEP directives, probably?

17:34 <sourcebox[m]> But it's a closure, which doen't have a dedicated symbol name.

17:36 <JamesMunns[m]> I mean a KEEP directive for the entry point

17:36 <sourcebox[m]> The entry point is not optimized away.

17:37 <JamesMunns[m]> You're saying the entry points are both preserved, but the closure that you directly call in rust code IS optimized away?

17:37 <JamesMunns[m]> Are you seeing that with a linker error or something?

17:38 <sourcebox[m]> With entry function, I mean the closure function passed to start_app_core.

17:38 <sourcebox[m]> This contains the code that should be executed on the second core.

17:38 <JamesMunns[m]> can you paste the error message that you see?

17:39 <sourcebox[m]> There's no error messages, I just can't find the code in the assembly dump anymore.

17:39 <JamesMunns[m]> Simple closures often get inlined at their call site

17:39 <JamesMunns[m]> it's probably not *gone*, just *optimized* somewhere else.

17:40 <sourcebox[m]> And therefore, the rest of the magic done in this esp-hal function doen't work anymore.

17:41 <sourcebox[m]> I can search for what the code is doing, and it's not there anymore. Even with inlining, that would be the case.

17:41 <JamesMunns[m]> Gotcha, I must not understand what is going on then, sorry!

17:42 <sourcebox[m]> I know this whole thing is somewhat complicated.

17:44 <sourcebox[m]> The other approach I tried is what is done in the RP HALs, but there's another drawback: since they use a generic function as entry point, it can not be reached from the startup code anymore because these type of functions have to be name-mangled.

17:47 <sourcebox[m]> What's done there is this: https://github.com/embassy-rs/embassy/blob/c511d166cdde76fc985f6531eae2bf1ffb461589/embassy-rp/src/multicore.rs#L162

17:48 <sourcebox[m]> At then of core1_startup there's a call to entry(), so my guess is, the compiler will get it and the code remains.

17:49 <sourcebox[m]> But as I said, this function is not reachable from the asm startup code.

17:50 <sourcebox[m]> Also, there has to be some arguments passed that the startup code does not have.

17:58 <thejpster[m]> <Kin-o-matix[m]> "I take it you have to manually..." <- Yes. I estimate they only took 15% of the effort. You look at the register map in the data sheet and type out all the names. Then any you really care about you replace the u32 with a bitbybit bitfield struct describing all the bit fields.

17:59 <Kin-o-matix[m]> this kind of suggests there's an issue if you go to aarch64 with a lot of the existing methods https://github.com/google/safe-mmio

18:00 <Kin-o-matix[m]> this is just marketing by google to sell me on a crate they'll abandon in 3 months?

18:04 <Kin-o-matix[m]> maybe I'll try this for gpio on mcxn, the register blocks are silly simple

18:06 <Kin-o-matix[m]> thejpster: do you feel derive-mmio kind of helps with the safety process then by avoiding the vast quantities of code the tools generate from svds? reviewing the large amount of code svd tools seem to produce for correctness seems like a drag to be honest, can't help but think some bit position issue will turn up and waste a ton of time

18:25 <thejpster[m]> Yes. And once I’m done it’s easy to go in and remove what I’m not using.

18:25 <thejpster[m]> I lost one hour because bitbybit::bitfield let me overlap fields, and I have an issue open to add an option to make that a compile failure. The cross checking between the bit offsets and the field size helps you get it mostly right.

18:26 <thejpster[m]> <Kin-o-matix[m]> "this kind of suggests there's an..." <- Only if you use a hypervisor - LLVM sometimes emits an instruction that is architecturally hard to emulate in EL3.

18:27 <thejpster[m]> The main difference is I give you functions you can see in the docs and they give you a macro! to do field projection. Kind of weird both projects started at about the same time.

18:29 <thejpster[m]> Here’s a fully worked example you can run: https://github.com/ferrous-systems/rust-training/blob/main/example-code/qemu-common/src/cmsdk_uart/basic.rs

18:30 <thejpster[m]> It uses bitflags but I’m going to change it to use bitbybit bit fields because they are just better.

18:47 <WoodrowDouglass[> Hello. I'd like to use some development tools written in rust to develop some bitbake packages. Can meta-rust-bin build native dev-tools?

19:11 <TomB[m]> <thejpster[m]> "Here’s a fully worked example..." <- This looks very C like, looks nice

20:40 <WoodrowDouglass[> <WoodrowDouglass[> "Hello. I'd like to use some..." <- Turns out if i just write my package like normal, and add `BBCLASSEXTEND="native"`, it all just comes out in the wash

23:55 <AstraKernel[m]> <k3ma[m]> "Hello, I'm new to Micro Controll..." <- In which section you are in. Are you getting any error. Can you provide a screenshot