procton__ has quit [Remote host closed the connection]
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
radens has quit [Quit: Connection closed for inactivity]
<re_irc>
<@ubik:matrix.org> does anyone else on vscode/rust-analyzer get some annoying error message in their main.rs, apparently due to the `#[entry]` macro?
<re_irc>
<@ubik:matrix.org> never mind. updating rustc nightly fixes it
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
adamgreig[m] has left #rust-embedded [#rust-embedded]
<re_irc>
<@dirbaio:matrix.org> hard to say what's idiomatic without more info though
<re_irc>
<@dirbaio:matrix.org> are these enum values a sort of "commands", where some impls support more commands than others?
<re_irc>
<@dirbaio:matrix.org> in that case doing one method per command, then separating the "support level" on separate traits is maybe more idiomatic?
<re_irc>
<@jspn:matrix.org> The enum values are the possible DMA request inputs.
<re_irc>
<@jspn:matrix.org> I'm attempting to provide a common interface for all L4 devices, and so would like to have a single public enum with the possible options,
<re_irc>
<@jspn:matrix.org> but not all DMA channels can do all peripherals, that's why I have the `Result` in the return type right now.
<re_irc>
<@jspn:matrix.org> The `pub trait SomeTrait<T>` seems nice, but that would rule out the single public enum.
<re_irc>
<@dirbaio:matrix.org> ohhh, stm32 dma 🤣
<re_irc>
<@dirbaio:matrix.org> cursed
<re_irc>
<@dirbaio:matrix.org> other hals do it at type-level instead of with a "request line" enum
<re_irc>
<@dirbaio:matrix.org> with traits to enforce you can only use the right lines on the right channels
<re_irc>
<@dirbaio:matrix.org> like, `impl TxDma<USART1> for DMA2_CH3`
<re_irc>
<@dirbaio:matrix.org> but in general if you want to enforce it at compile time you'll need types+traits, there's no way to do it with enums
<re_irc>
<@jspn:matrix.org> Yes, seems logical, the F4 one seems interesting, I'll take a deeper look, thanks!
<re_irc>
<@firefrommoonlight:matrix.org> I think we've chatted about this before, and there are a number of ways you can do this. One example:
<re_irc>
<@firefrommoonlight:matrix.org> - See feature gates for this. Treat anything gated for `H7` or `G4` as your L4+ MCUs, and the opposite as L4 basic
<re_irc>
<@firefrommoonlight:matrix.org> (The code I posted *does not* work on L4+, but probably could be with minor changes. It would look like the G4 and H7 code, not the code marked "L4". As Dirbaio implied, damn you ST!)
<re_irc>
<@dirbaio:matrix.org> dirbaio:matrix.org: (or maybe it's been fixed, I haven't been following closely)
<re_irc>
<@firefrommoonlight:matrix.org> In particular, example this example for a peripheral's `dma_wriet` method:
<re_irc>
<@firefrommoonlight:matrix.org> ```rust
<re_irc>
<@firefrommoonlight:matrix.org> // L44 RM, Table 41. "DMA1 requests for each channel"
<re_irc>
<@firefrommoonlight:matrix.org> The function has a `dma_channel` arg, for use with DMAMUX. Ie, you pass the channel to the function for L4+
<re_irc>
<@firefrommoonlight:matrix.org> If on an older MCU that doesn't use DMAMUX, choose the correct hard-set channel
<re_irc>
<@firefrommoonlight:matrix.org> And if on L4 (not +!), do `channel_select`, which no other STM has!!
<re_irc>
<@dirbaio:matrix.org> firefrommoonlight: yours is still enum based, how do you enforce at compile time you can only use a request with the right channels?
<re_irc>
<@firefrommoonlight:matrix.org> For non-MUX, it ignores the `dma_channel` argument, and chooses the right one for you
<re_irc>
<@firefrommoonlight:matrix.org> For Mux, it's not enforced; it's expected you run something like `dma::mux(DmaChannel::C2, dma::DmaInput::Sai1A, &mut dp.DMAMUX1);` first
<re_irc>
<@dirbaio:matrix.org> firefrommoonlight:matrix.org: how do you enforce you don't try to use the same channel for 2 things at the same time, then?
<re_irc>
<@firefrommoonlight:matrix.org> The peripherals use teh owned-register approach. So, you'd have to violate that with a `peripherals::steal` etc
<re_irc>
<@firefrommoonlight:matrix.org> Since the `read_dma`, and `write_dma` methods control which channel to use, eg in the code I copy+pasted above
<re_irc>
<@firefrommoonlight:matrix.org> Actually, I suppose you could call `write_dma(...)` twice without stopping it, and UB would happen
<re_irc>
<@jspn:matrix.org> Thanks for the example, but that would require a lot of rewriting of the current l4-hal though.
<re_irc>
<@jspn:matrix.org> I'd prefer to be as non-invasive as possible.
<re_irc>
<@firefrommoonlight:matrix.org> If that's what you'r egetting that, I don't enforce it
<re_irc>
<@firefrommoonlight:matrix.org> I agree - I think your approach is good. I posted for reference, and to demonstrate it can be done
<re_irc>
<@dirbaio:matrix.org> yep if oyu don't have owned singletons for channel then it's not compile-time-safe :)
<re_irc>
<@firefrommoonlight:matrix.org> I might come around on ditching owned sigletons eventually. For now, despite all my raging against owning buses, I think owning PAC periph reg blocks is fine
<re_irc>
<@firefrommoonlight:matrix.org> (The key difference is I don't expect more than one peripheral-management struct to access a given periph)
x56 has quit [Quit: Ծ-Ծ]
x56 has joined #rust-embedded
<re_irc>
<@henrik_alser:matrix.org> dirbaio:matrix.org: Yeah it's been added