00:21 <holo[m]> <holo[m]> "I have ordered Pico W too and..." <- Will add here that when i tested simple pin switching its working so guessing something with that dht22_pi carate will be not like it should. Will try to recreate it based on some other example

00:22 <holo[m]> holo[m]: https://citizen-stig.github.io/2020/05/17/reading-temperature-sensor-in-rust-using-raspberry-pi-gpio.html

00:22 <holo[m]> holo[m]: its using ither library but will try to make same with rppal

09:00 <M9names[m]> <sample-user-just> "> <@sample-user-just-testing:..." <- Probably! Most of the time when there's an abstraction built around a register there will also be an escape hatch to let you set the bits directly.

09:00 <M9names[m]> Unsure why it's absent here, but most likely it's something that no-one else has needed badly enough to implement (or ask why it's missing).

09:02 <M9names[m]> it's a pretty small change, i would recommend adding it, making a PR and see what the riscv-team think about it

17:04 <Ralph[m]> with the e-h 1.0 release just around the corner i think it'd be good if the `cortex-m` crate would add support for it as well (it currently has e-h 0.2 support for `Delay`). a year ago there was an attempt for it, however the delay-API has been completely revamped since, so i think this PR can just be closed: https://github.com/rust-embedded/... (full message at

17:04 <Ralph[m]> <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WuVzIddjkuxEZaIUQpqZLTpU>)

17:07 <dirbaio[m]> ideally you'd impl delay_ns directly, it's a more accurate if the clock freq is not a divisor of 1_000_000

17:07 <dirbaio[m]> going ns -> us -> cycles rounds a bit more than ns -> cycles

17:08 <dirbaio[m]> (the contract does allow for delaying longer than nedeed, so "ns -> us -> cycles" is correct as long as every step rounds up, just that it could be more precise)

17:08 <dirbaio[m]> (btw did you know you can .div_ceil(1000)? 😄)

17:11 <dirbaio[m]> > the other question would be whether it should migrate from e-h 0.2 to 1.0 (dropping 0.2 support) or whether it should have both in parallel for a while until the ecosystem has migrated

17:11 <dirbaio[m]> in the migration guide I've written that it's recommended to impl both for now. There's the balance between "compat" and "push people to upgrade", yes... but there's *a lot* of 0.2 code out there, I think "compat" is more important for now?

17:11 <dirbaio[m]> https://github.com/rust-embedded/embedded-hal/blob/0e4a3fd08ab919a0b697368305cd3dd926319ed2/docs/migrating-from-0.2-to-1.0.md#supporting-both-02-and-10-in-the-same-hal

17:11 <dirbaio[m]> also implementing both is bakcwards-compatible, we could do it in cortex-m 0.7.x, while upgrading would have to wait for cortex-m 0.8

17:17 <Ralph[m]> <dirbaio[m]> "(btw did you know you can ...." <- i did not! thanks for that - always glad to learn!

17:19 <Ralph[m]> <dirbaio[m]> "ideally you'd impl delay_ns..." <- certainly. this was a quick-and-dirty implementation to get the e-h 1.0 support off the ground for `avr-hal` with the clear hope that someone else will come up with a proper delay implementation for ns which didn't do the detour from ns to us. the current implementations looked a bit too spooky for me to attempt writing a similar one for ns

17:45 <Ralph[m]> dirbaio: there's a small typo in the migration guide but i can't add a comment on the PR as it's in unchanged code:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BIUMnCwGhZoLuKMNBmDOeHnm>)

17:46 <dirbaio[m]> ahh fixed thanks

17:55 <Ralph[m]> btw, with [the note discouraging `shared-bus`](https://github.com/rust-embedded/embedded-hal/pull/555/files#diff-98242bdbe25001f862872c9e26459860b67a95ab0bb7d5b675c29a7e7e4afd72R194): should the same be added to the `shared-bus` README with a reference to `embedded-hal-bus` so that `shared-bus` is clearly only for e-h v0.2 while for 1.0 the new crate should be used?

17:58 <dirbaio[m]> and only for i2c. it's [broken for spi](https://github.com/Rahix/shared-bus/issues/23)

17:59 <dirbaio[m]> (there's no way to soundly do spi sharing with the 0.2 traits, because there's no SpiDevice equivalent)

19:17 <PilEghoff[m]> Hey, i'm pretty new to rust (have been at it casually for a year or so), but come from an embedded C background. I just spend forever trying to get defmt to work over usb serial (using defmt-serial) on the rpi-pico to work, and i think im giving up. I wanted to outline my issues here to get some feedback on if what im doing is just too... (full message at

19:17 <PilEghoff[m]> <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yfCRgXiVRSfRwRvDOycHVfaj>)

19:21 <PilEghoff[m]> * usb-serial? Or because i just cant figure out how to set it up correctly? Or is this

19:58 <mameluc[m]> <PilEghoff[m]> "Hey, i'm pretty new to rust (..." <- > <@pileghoff:matrix.org> Hey, i'm pretty new to rust (have been at it casually for a year or so), but come from an embedded C background. I just spend forever trying to get defmt to work over usb serial (using defmt-serial) on the rpi-pico to work, and i think im giving up. I wanted to... (full message at

19:58 <mameluc[m]> <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DHiyviyCSMkvrARarQfFUaQD>)

20:05 <thejpster[m]> I'm looking at a RISC-V FPGA soft-core with some custom CSRs. I see the riscv crate has functions to read some standardised CSRs, but how do I read some extra ones? Do I have to write some custom assembly to do it?

20:07 <Mrestof|someones> Hiii! I just started learning Rust, a month ago I guess. I made some really small projects in past on microcontrollers using C. What would you recommend to read first to try out Rust with embedded? I have one chinese arduino nano board and one STM32F411 board (black pill).

20:11 <JamesSizeland[m]> <PilEghoff[m]> "Hey, i'm pretty new to rust (..." <- > <@pileghoff:matrix.org> Hey, i'm pretty new to rust (have been at it casually for a year or so), but come from an embedded C background. I just spend forever trying to get defmt to work over usb serial (using defmt-serial) on the rpi-pico to work, and i think im giving up... (full message at

20:11 <JamesSizeland[m]> <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pObLjNoAVeXxhOVTDzctaOWB>)

20:15 <JamesSizeland[m]> <Mrestof|someones> "Hiii! I just started learning..." <- I'm new to embedded rust myself, but these have helped me: https://www.espressif.com/en/dev-board/esp32-c3-devkit-rust-1-en this is a good starter, and this https://docs.rust-embedded.org/discovery/microbit/ I'd recommend grabbing hardware to fit the tutorial rather than the other way around.

20:17 <barnabyw[m]> <Mrestof|someones> "Hiii! I just started learning..." <- out of those two boards the STM32-based one is much better supported by rust than AVR afaik. I started out with embedded rust on a STM32F103 and later F411 black pill boards. do you have a debug probe (e.g. st-link or pi pico with picoprobe firmware) for programming and debugging? if not then getting one would be a good next step

20:18 <thejpster[m]> <PilEghoff[m]> "Hey, i'm pretty new to rust (..." <- > <@pileghoff:matrix.org> Hey, i'm pretty new to rust (have been at it casually for a year or so), but come from an embedded C background. I just spend forever trying to get defmt to work over usb serial (using defmt-serial) on the rpi-pico to work, and i think... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GHqjvbWBhzHsTMhBZGvkIwGd>)

20:20 <thejpster[m]> > Or is this just some pain that i have to deal with since the rust embedded ecosystem is still not mature?

20:20 <thejpster[m]> I'm not sure that's fair. I'd love to see someone take a logging framework from Third Party A and then jam it into TinyUSB (from Third Party B), whilst trying to connect that the HAL from the soc manufacturer (Third Party C). Unless your soc manufacturer had done the work for you, you're going to have a hell of a time.

20:20 <PilEghoff[m]> thejpster[m]: That would require a debugger (right?), which i left at the office and wont have access to until January.

20:20 <thejpster[m]> PilEghoff[m]: Yeah, fair, RTT requires a debug probe to unobstrusively read your SRAM.

20:21 <thejpster[m]> * take a C-language logging framework

20:21 <barnabyw[m]> <Mrestof|someones> "Hiii! I just started learning..." <- this blog post is a good intro to using rust on black/blue pill boards (though you’ll have to modify it slightly for the F411 rather than the F103), but if I was starting afresh I’d jump straight to using https://embassy.dev/, which has very good support for the 411 and a bunch of examples which will work on it straight away

20:21 <barnabyw[m]> * the F103), https://jonathanklimt.de/electronics/programming/embedded-rust/rust-on-stm32-2/ but if

20:21 <PilEghoff[m]> <mameluc[m]> "> <@pileghoff:matrix.org> Hey, i..." <- I dont doubt that defmt-serial works. But its not compatible with the version of usbd-serial that is compatible with the rp-hal.

20:24 <thejpster[m]> PilEghoff[m]: Looking at the versions on github, defmt-serial and rp2040-hal both use embedded-hal 0.2.7, so they should plug together.

20:24 <PilEghoff[m]> thejpster[m]: The difference is that is usually not something i would ever attempt in C. In C i would uses the vendor provided USB stack and logging framework. I didnt compare it to C, as i know that is apples to oranges, but i think i did things the rust way, and it seems like it just cant really be done without updating a handful of external crates.

20:25 <PilEghoff[m]> <JamesSizeland[m]> "> <@pileghoff:matrix.org> Hey, i..." <- Yeah, left my debugger at work, so i wont have it until January.

20:26 <thejpster[m]> thejpster[m]: it looks like the rp2040 examples use usbd-serial 0.1.1 which also uses embedded-hal (it lists 0.2.2, but that should update to 0.2.7 automatically). They haven't been updated to use usbd-serial 0.2.0

20:27 <PilEghoff[m]> thejpster[m]: Yeah, but rp2040-hal uses usb-serial 0.1.1 which in turn uses embedded-hal 0.2.2

20:28 <thejpster[m]> PilEghoff[m]: I can't immediately see why your use-case wouldn't work, but things will probably get better after embedded-hal 1.0 is released and all the HALs and examples update to use that.

20:30 <PilEghoff[m]> thejpster[m]: I have a hard time remembering exactly what the original issue was. I went through and tried to upgrade the required packages in the crates, and it led me down a rabbit hole. I think it was the embedded-hal version that was incompatible between usbd-serial 0.1.1 and defmt-serial

21:04 <PilEghoff[m]> <thejpster[m]> "I can't immediately see why your..." <- I seem to have been going in circles. The issues was something else completely (i think). I seems that the issue is that defmt-serial requires embedded_hal::blocking::serial::write while usbd-serial provides embedded_hal::serial::Write

21:05 <PilEghoff[m]> PilEghoff[m]: When reading the error message, i missed the differences and assumed mismatched versions of the trait was the culprit.

21:15 <PilEghoff[m]> <PilEghoff[m]> "When reading the error message..." <- Yep. Adding the blocking write trait to the 0.1.1 version of the usbd-serial Serial fixes the compile errors. Now i just need to figure out why it was not added in the first place..

21:39 <thejpster[m]> <PilEghoff[m]> "Yep. Adding the blocking write..." <- You can’t block whilst writing to USB because the main loop needs to handle the interrupt request.

21:43 <thejpster[m]> thejpster[m]: I haven’t looked at the crate but I assume it has some internal RAM buffer the size of a usb packet. You might want to log into a RAM buffer and send it over USB in the background.

23:49 <dirbaio[m]> I'm writing a blog post for embedded-hal 1.0 release

23:50 <dirbaio[m]> the last post on the WG blog was almost 2y ago, lol