01:16 <esden[cis]> Hey, I am working on an embedded driver crate that is using embedded-io-async. I also need to be able to await with timeout and deadline within the driver crate. Is there a generic API for that because me using embassy-time for that is not really portable and also results in compilation issues. Is there some good way to achieve this, or maybe someone already did a similar thing?

08:14 <mameluc[m]> <esden[cis]> "Hey, I am working on an embedded..." <- there is embedded-hal-async::DelayNs, then you can pass in a delay implementation to your driver

11:14 <dirbaio[m]> with [this PR](https://github.com/rust-lang/rust/pull/128440), `static_cell::make_static!` now works again 🥳

12:48 <diondokter[m]> <dirbaio[m]> "with [this PR](https://github...." <- Nice! Seems like a good step

12:49 <diondokter[m]> <esden[cis]> "Hey, I am working on an embedded..." <- The way you can do this is by using the DelayNS trait and running it together with the Io trait in a select statement

13:56 <diondokter[m]> I tried grabbing a U3 dev board from the STM booth at Embedded World. Apparently I was too late and they had none left. Seems like embassy support will have to wait 😅

14:01 <diondokter[m]> The U3 is pretty cool though! It can support a VCore of 0.65 volts

14:41 <matt-rodgers[m]> <diondokter[m]> "I tried grabbing a U3 dev..." <- I picked one up yesterday, would be interested to have a go at getting embassy running on it but I'm not sure where to start. Any pointers, or links to any documentation that might help?

14:43 <diondokter[m]> matt-rodgers[m]: Not sure how much documentation there is.... (full message at <https://catircservices.org/_irc/v1/media/download/ARbLoxpbUgb1MDFOPbYqK7JAo5075M6fHuIaT_sJYRK0SA3ZAEjACbvvOq3jMMsaWgtYo_oNFmtnyJMs-LhgA6q_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9yWkdDWE90RHBNa0NqbWFPbkFPSGRYSUM>)

14:43 <diondokter[m]> I did it a year ago for the U0

14:43 <diondokter[m]> (with some help of Dario)

14:49 <matt-rodgers[m]> The metadata crate is this one right? https://github.com/embassy-rs/stm32-data

14:49 <matt-rodgers[m]> I'll give it a go when I have a chance

14:50 <diondokter[m]> Yeah

14:51 <diondokter[m]> matt-rodgers[m]: > <@matt-rodgers:matrix.org> The metadata crate is this one right? https://github.com/embassy-rs/stm32-data... (full message at <https://catircservices.org/_irc/v1/media/download/AdUVXmGIh2zhvU1QEBhNia5D-GDvQYsOTJn5qHhclCu2oKM1BvREZ5U3LVzKSJ1Vg04b9DqF8ijVzEVu0t1H_6O_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9PVVVrT3JFd1dGeW1oV2lBQ25UaHVCT2I>)

15:54 <JamesMunns[m]> <diondokter[m]> "The U3 is pretty cool though! It..." <- That's fun because thats the voltage of a single solar cell

17:12 <pvdrz[m]> hey dirbaio. I'll be the Ferrous Systems person helping on the heapless stabilization process. japaric sent you and Markus an email a few minutes ago

17:47 <thejpster[m]> Has anyone tried the MAX32690?

17:47 <thejpster[m]> https://www.analog.com/en/products/max32690.html

17:47 <thejpster[m]> M4F plus BLE plus RISC-V co-pro

18:22 <Ralph[m]> <pvdrz[m]> "hey dirbaio. I'll be the Ferrous..." <- heapless is getting stabilized? now that's some great news! 2025 will be the year of v1.0.0, now that defmt has announced it and you just spilled the beans on heapless 🥳

18:22 <Ralph[m]> thanks a lot to ferrous systems for pushing this stabilisation effort!

18:25 <spikespaz[m]> I have added `build.target = "aarch64-unknown-linux-gnu"` in `.cargo/config.toml`, and now when I run `cargo doc` (which should build docs for the cross target) I see:... (full message at <https://catircservices.org/_irc/v1/media/download/AaJ0LX7DDuWg1RxlkveRxCiSehdIDzXQY4NalNXn1s0og3_D9tRu13yYQUtQ0l5eMxLO2rSJrmYTw9zxwMRNNne_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9uUEhBd2JHd2NRandaTmVMVEJjdnFCZHA>)

19:53 <alvidrezluke[m]> Has anyone had any success with using STM32 External Memory loader to flash a Rust generated .elf with the STM boot project? The H7RS series has such little flash memory that I need to flash it with a bootloader and there don't seem to be any pre done or example rust solutions that work on external memory. I've been working on translating the bootloader manually but if there is an easier way for this prototype I def want to

19:53 <alvidrezluke[m]> use that lol.

20:51 <vollbrecht[m]> rust compiler team is thinking about [new target naming rules](https://github.com/rust-lang/compiler-team/issues/850). Maybe interesting for some folks to go into the discussion. [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Basic.20target.20naming.20rules.20compiler-team.23850) stream is here

21:10 <ivmarkov[m]> xtensaesp32s3-espressif-espidf?

21:10 <ivmarkov[m]> <vollbrecht[m]> "rust compiler team is thinking..." <- Hmmmm is `esp32*` in his suggestion a subarch or an eabi? I think maybe a subarch and then his new proposals are also not quite right? If esp32/esp32s2/esp32s3 are subarxhs of xtensa, then maybe

21:11 <ivmarkov[m]> * Hmmmm is

21:11 <ivmarkov[m]> esp32* in his suggestion a subarch or an abi? I think maybe a subarch and then his new proposals are also not quite right? If esp32/esp32s2/esp32s3 are subarxhs of xtensa, then maybe

21:11 <ivmarkov[m]> xtensaesp32s3-espressif-espidf?

21:11 <ivmarkov[m]> * Hmmmm is

21:11 <ivmarkov[m]> esp32* in his suggestion a subarch or an abi? I think maybe a subarch and then his new proposals are also not quite right? If esp32/esp32s2/esp32s3 are subarchs of xtensa, then maybe

21:11 <ivmarkov[m]> xtensaesp32s3-espressif-espidf?

21:12 <ivmarkov[m]> A bit mouthful, but riscv32imahfc is just as mouthful

21:21 <vollbrecht[m]> esp32 / s2 / s3 all uses the xtensa lx7 variant of the core right? Not sure out of my head in what "externsion instruction" they differ, but that would be abi difference right?

21:23 <vollbrecht[m]> currently "esp32" is just used to codify as a opaque name that specific set abi right? Since technically the arch is the same on all 3

21:41 <TomB[m]> I wish xtensa were that simple... https://github.com/zephyrproject-rtos/sdk-ng/tree/main/overlays

21:41 <TomB[m]> riscv options look simple in comparison, https://github.com/zephyrproject-rtos/sdk-ng/blob/main/overlays/xtensa_espressif_esp32s3/newlib/newlib/libc/sys/xtensa/include/xtensa/config/core-isa.h

21:43 <TomB[m]> there's also different ABIs for the architecture... which make it even more fun?

21:52 <vollbrecht[m]> yeah my abi statement was a bit short, i meant abi and "extra hardware features". Almost every architecture has some additional "hardware features", and that is not considered subarchitecture right? Like your intel x86 cpu that has VT-x feature. The feature itself comes with extra instructions added to x86 right? Same would be for extra xtensa specific stuff.

22:00 <TomB[m]> I guess it depends on how you look at xtensa, yes there's generations (lx6/lx7) and isa extensions for certain use cases (hifi/fusion) but there's also core isa options as you can see in the isa header there. Its maybe noteable that for zephyr we have a toolchain specific to each and every xtensa variant... its kind of a hassle but how its seemingly done 🤷

22:02 <TomB[m]> * xtensa variant without any hint that they happen to be lx6 or lx7... its

22:04 <vollbrecht[m]> historically it was also split in esp-idf sdk in the gcc toolchain, though they unified it 2 years ago into one, so at least you can at least technically live with one variant. Still need to provide the right flags into the toolchain :D

22:05 <vollbrecht[m]> s/at least//

22:05 <TomB[m]> I mean the very first #define for gcc and xtensa is.... XCHAL_HAVE_BE (is this instance big endian?) https://github.com/zephyrproject-rtos/sdk-ng/blob/main/overlays/xtensa_espressif_esp32s3/gcc/include/xtensa-config.h#L29

22:05 <TomB[m]> doesn't that just say it all right there?