05:45 <re_irc> <@fyl2xp1:matrix.org> Hi everyone! I'm looking for a small sized board to control some LED strips over Ethernet or Wifi.

05:45 <re_irc> <@fyl2xp1:matrix.org> I've been looking through https://github.com/rust-embedded/awesome-embedded-rust trying to assemble a list board that are reported to work with Rust. Before I continue this tedious task I wanted to hear if you have any recommendation at hand:

05:45 <re_irc> <@fyl2xp1:matrix.org> - On-board Ethernet or Wifi support

05:45 <re_irc> <@fyl2xp1:matrix.org> - 5 outputs for bit-banging

05:45 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/61d34377f1ff242e1cc7c99e413ec1eb9ae5a62f36a114d75923d17d15dd4b4c (7 lines)

08:19 <re_irc> <@davidgoodenough:matrix.org> fyl2xp1: esp32 boards fit the bill. Both ethernet and WiFi support on chip but ethernet not always exposed. Rust support coming on in leaps and bounds, cheap and readily available.

11:05 <re_irc> <@ryan-summers:matrix.org> The stm32h7xx series with external PHY (e.g. LAN8274 or something like that) works pretty well - I believe there's a nucleo board with it all set up

11:05 <re_irc> <@ryan-summers:matrix.org> esp32 support is less than stm32 parts imo, since the xtensa core requires a custom rustc

12:07 <re_irc> <@korken89:matrix.org> ryan-summers:matrix.org: NUCLEO-H743ZI2 is the one

12:31 <re_irc> <@davidgoodenough:matrix.org> ryan-summers: there is also a risc-v esp32 which uses stock rust

12:31 <re_irc> <@ryan-summers:matrix.org> Is risc-v support up to the level of cortex-m yet? I haven't played at all with riscv cores

13:10 <re_irc> <@firefrommoonlight:matrix.org> Had anyone made a high-level timer API for stm32 that doesn't use macros? Going to try later today, and have a few ideas. Looking to differentiate as basic, GP 32-bit, basic 16-bit, and advanced

13:10 <re_irc> <@davidgoodenough:matrix.org> I think that all the rust embedded targets are still evolving judging by this discussion group. There is an esp rs group on

13:11 <re_irc> <@davidgoodenough:matrix.org> You might want to ask there if it has what you need

13:18 <re_irc> <@ryan-summers:matrix.org> My main point here is that cortex-m is relatively mature at this point (I am aware of multiple products shipping using various processors), but I've seen a lot of recent work in regards to riscv and esp32 support, so I'm hesitant to direct a newcomer to those architectures

13:19 <re_irc> <@ryan-summers:matrix.org> Yeah, they're all continuously evolving, but some processors have a larger userbase + wider, more stable support at this point. I'm somewhat ignorant on the current state of cores outside of ARM though

13:23 <re_irc> <@firefrommoonlight:matrix.org> The other side of that is more people using other architectures will drive improvements from feature requests, bug reports etc

13:24 <re_irc> <@firefrommoonlight:matrix.org> ESP has the killer feature of wifi support; it would be lovely to have that as a well supported tool in the Rust ecosystem

21:44 <re_irc> <@firefrommoonlight:matrix.org> So, I have a plan for STM32 Basic timers. They all are either Tim6 or Tim7, and deref to Tim6. These lack interrupts, output compare etc, and are mainly for DAC triggering. Unfortunately, the solution is not so simple for other tims, due to not dereffing cleanly

21:44 <re_irc> <@firefrommoonlight:matrix.org> Could let the user specify the timer and not own a reg block

21:45 <re_irc> <@firefrommoonlight:matrix.org> But... this is still useful, since I can implement full functionality on the other timers without worrying about basic tim limits

22:23 <re_irc> <@firefrommoonlight:matrix.org> basic tim separation implemented

22:46 <re_irc> <@firefrommoonlight:matrix.org> Tangent: Is there a way to tell what the struct is if you're using a `Deref` ? I have code like this this for most of my STM32 periphs: Need a way to tell which periph clock to enable. Is there another way? (Without macros)

22:46 <re_irc> <@firefrommoonlight:matrix.org> impl<R> BasicTimer<R>

22:46 <re_irc> <@firefrommoonlight:matrix.org> ```rust

22:46 <re_irc> <@firefrommoonlight:matrix.org> where

22:46 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/c381f40d88da8d6c5434fd1370bb4b11fb3517d812dde86116865d2ce5fe697e (26 lines)

22:48 <re_irc> <@firefrommoonlight:matrix.org> I want to remove the `xDevice` enums entirely to simplify the API

22:49 <re_irc> <@dirbaio:matrix.org> ```rust

22:49 <re_irc> <@dirbaio:matrix.org> trait RccPeripheral { fn enable(); fn reset(); }

22:49 <re_irc> <@dirbaio:matrix.org> impl RccPeripheral for TIM1, 2, 3, 4... { code that enables/disables the right bit }

22:49 <re_irc> <@dirbaio:matrix.org> impl<R> BasicTimer<R>

22:49 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/80797809c860cea4e317691206401dd747259e7de06f82f033739f4efdaee3f5 (6 lines)

22:50 <re_irc> <@firefrommoonlight:matrix.org> Thank you! I'll see if I can make that work

22:50 <re_irc> <@dirbaio:matrix.org> embassy does it like that, autogenerating the RccPeripheral impls

22:51 <re_irc> <@dirbaio:matrix.org> you'll still need some macro or cfg spam to make the RccPeripheral impls

22:51 <re_irc> <@dirbaio:matrix.org> but at least the code for BasicTimer stays clean

22:51 <re_irc> <@firefrommoonlight:matrix.org> All my constructors currently have the `xDevice` arg, which I don't like for API

22:51 <re_irc> <@firefrommoonlight:matrix.org> Yea that's fine

22:52 <re_irc> <@firefrommoonlight:matrix.org> What should the `TIM1, 2, 3` etc be?

22:55 <re_irc> <@dirbaio:matrix.org> impl RccPeripheral for TIM1 {

22:55 <re_irc> <@dirbaio:matrix.org> fn enable() {

22:55 <re_irc> <@dirbaio:matrix.org> }

22:56 <re_irc> <@dirbaio:matrix.org> et

22:56 <re_irc> <@firefrommoonlight:matrix.org> trait RccPeripheral { fn en_reset(); }

22:56 <re_irc> <@firefrommoonlight:matrix.org> fn en_reset(rcc: &mut rcc::RegisterBlock) {

22:56 <re_irc> <@firefrommoonlight:matrix.org> ```rust

22:56 <re_irc> <@firefrommoonlight:matrix.org> impl RccPeripheral for TIM6 {

22:56 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/e88ae97038df3ffd3a0c80eb1daf974d26210c41da2c0eb347bf6d4d78a384a2 (28 lines)

22:56 <re_irc> <@dirbaio:matrix.org> yeah, that

22:56 <re_irc> <@firefrommoonlight:matrix.org> I guess I'm stuck at glueing what you posted to the construtor

22:57 <re_irc> <@dirbaio:matrix.org> what do you mean?

22:57 <re_irc> <@dirbaio:matrix.org> you can do `R::en_reset()`, which will call the right method depending on the type of R

22:58 <re_irc> <@dirbaio:matrix.org> you need `where R: RccPeripheral` too

23:01 <re_irc> <@firefrommoonlight:matrix.org> Oh shit

23:01 <re_irc> <@firefrommoonlight:matrix.org> This is a language featuere I'm not super comfortable with, but...it works!

23:01 <re_irc> <@firefrommoonlight:matrix.org> Thank you. You've just improved my STM32 API across the board by removing a filler param

23:01 <re_irc> <@dirbaio:matrix.org> :D

23:02 <re_irc> <@firefrommoonlight:matrix.org> OK, ops tested it on a device; works no prob. Hell yea. Now for the rest of the periphs.

23:36 <re_irc> <@theunkn0wn1:matrix.org> Odd question,

23:36 <re_irc> <@theunkn0wn1:matrix.org> Say i have a device on the far end of a transport which, when queried, returns a uint32 representing a register with multiple fields.

23:36 <re_irc> <@theunkn0wn1:matrix.org> are there any good crates for abstracting this similar to how PACs handle MMIO?