fabic_ has joined #rust-embedded
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #rust-embedded
Rondom has quit [Remote host closed the connection]
Rondom has joined #rust-embedded
PyroPeter has quit [Ping timeout: 250 seconds]
PyroPeter has joined #rust-embedded
fabic_ has quit [Ping timeout: 268 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 265 seconds]
<re_irc> <@fyl2xp1:matrix.org> Hi everyone! I'm looking for a small sized board to control some LED strips over Ethernet or Wifi.
<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:
<re_irc> <@fyl2xp1:matrix.org> - On-board Ethernet or Wifi support
<re_irc> <@fyl2xp1:matrix.org> - 5 outputs for bit-banging
fabic_ has joined #rust-embedded
<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.
fabic_ has quit [Ping timeout: 245 seconds]
loki_val has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
fabic_ has joined #rust-embedded
<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
<re_irc> <@ryan-summers:matrix.org> esp32 support is less than stm32 parts imo, since the xtensa core requires a custom rustc
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@korken89:matrix.org> ryan-summers:matrix.org: NUCLEO-H743ZI2 is the one
<re_irc> <@davidgoodenough:matrix.org> ryan-summers: there is also a risc-v esp32 which uses stock rust
<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
<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
<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
<re_irc> <@davidgoodenough:matrix.org> You might want to ask there if it has what you need
<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
<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
<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
<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
fabic_ has quit [Ping timeout: 245 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 245 seconds]
unmanbearpig has quit [Ping timeout: 245 seconds]
creich has quit [Quit: Leaving]
creich has joined #rust-embedded
unmanbearpig has joined #rust-embedded
<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
<re_irc> <@firefrommoonlight:matrix.org> Could let the user specify the timer and not own a reg block
<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
<re_irc> <@firefrommoonlight:matrix.org> basic tim separation implemented
<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)
<re_irc> <@firefrommoonlight:matrix.org> impl<R> BasicTimer<R>
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> where
<re_irc> <@firefrommoonlight:matrix.org> I want to remove the `xDevice` enums entirely to simplify the API
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> trait RccPeripheral { fn enable(); fn reset(); }
<re_irc> <@dirbaio:matrix.org> impl RccPeripheral for TIM1, 2, 3, 4... { code that enables/disables the right bit }
<re_irc> <@dirbaio:matrix.org> impl<R> BasicTimer<R>
<re_irc> <@firefrommoonlight:matrix.org> Thank you! I'll see if I can make that work
<re_irc> <@dirbaio:matrix.org> embassy does it like that, autogenerating the RccPeripheral impls
<re_irc> <@dirbaio:matrix.org> you'll still need some macro or cfg spam to make the RccPeripheral impls
<re_irc> <@dirbaio:matrix.org> but at least the code for BasicTimer stays clean
<re_irc> <@firefrommoonlight:matrix.org> All my constructors currently have the `xDevice` arg, which I don't like for API
<re_irc> <@firefrommoonlight:matrix.org> Yea that's fine
<re_irc> <@firefrommoonlight:matrix.org> What should the `TIM1, 2, 3` etc be?
<re_irc> <@dirbaio:matrix.org> impl RccPeripheral for TIM1 {
<re_irc> <@dirbaio:matrix.org> fn enable() {
<re_irc> <@dirbaio:matrix.org> }
<re_irc> <@dirbaio:matrix.org> et
<re_irc> <@firefrommoonlight:matrix.org> trait RccPeripheral { fn en_reset(); }
<re_irc> <@firefrommoonlight:matrix.org> fn en_reset(rcc: &mut rcc::RegisterBlock) {
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> impl RccPeripheral for TIM6 {
<re_irc> <@dirbaio:matrix.org> yeah, that
<re_irc> <@firefrommoonlight:matrix.org> I guess I'm stuck at glueing what you posted to the construtor
<re_irc> <@dirbaio:matrix.org> what do you mean?
<re_irc> <@dirbaio:matrix.org> you can do `R::en_reset()`, which will call the right method depending on the type of R
<re_irc> <@dirbaio:matrix.org> you need `where R: RccPeripheral` too
<re_irc> <@firefrommoonlight:matrix.org> Oh shit
<re_irc> <@firefrommoonlight:matrix.org> This is a language featuere I'm not super comfortable with, but...it works!
<re_irc> <@firefrommoonlight:matrix.org> Thank you. You've just improved my STM32 API across the board by removing a filler param
<re_irc> <@dirbaio:matrix.org> :D
<re_irc> <@firefrommoonlight:matrix.org> OK, ops tested it on a device; works no prob. Hell yea. Now for the rest of the periphs.
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc> <@theunkn0wn1:matrix.org> Odd question,
<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.
<re_irc> <@theunkn0wn1:matrix.org> are there any good crates for abstracting this similar to how PACs handle MMIO?