Dario Nieuwenhuis

> So would the intention be to still have separate RtcControl and RtcClock instances, but the former would be set up during embassy_stm32::init and stored in the time_driver::RtcDriver instance, then...

I'd try using u64 and check if code size increases too much or not. I think it shouldn't, if you use LTO then RCC code usually gets optimized very well...

`Hertz` is only to make the public api typesafe, it's fine to internally just use u32/u64. I wouldn't do `BigHertz` or `Hertz` since it doesn't appear in the public api...

`Pipe` is a byte stream, it doesn't make sense to use it with multiple writers for packet-based data. If we wanted to support this we'd have to add something like...

here https://github.com/smoltcp-rs/smoltcp/blob/23697fa766d899fd30241aaf02c4a67efbccd204/src/socket/tcp.rs#L2301-L2310 The TcpSocket methods just get/set state in the struct, and it's `fn dispatch` that sends packets that need to be sent based on the state.

Do not create a Cargo workspace mixing embedded and non-embedded, it simply doesn't work. Keep it as separate crates. For IDE support you can use `linkedProjects` to decide which crate...

@U007D you're running into a different issue: embassy-rp fixes the tick rate to 1Mhz because that's hardcoded in hardware, you can't make the rp2040 timer work at a different freq....

:wave: i'm also interested in this. Took a look at the code, i've ported it to the new PAC here https://github.com/embassy-rs/embassy/tree/nfct Now trying to get it to work... EDIT: Got...

#3552

Yes, this is caused by corruption. One possible cause is unreliable power (power the pico at 5v, not 3v3, and ensure the 5v source provides enough power (1A+). Another is...