starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
procton_ has joined #rust-embedded
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> <> does anyone else on vscode/rust-analyzer get some annoying error message in their, apparently due to the `#[entry]` macro?
<re_irc> <> 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> <>
creich has joined #rust-embedded
<re_irc> <> Finally :D
<re_irc> <> Does anyone know how I can improve the following situation
<re_irc> <> One,
<re_irc> <> ```rs
<re_irc> <> pub enum Foo {
<re_irc> <> perhaps this?
<re_irc> <> ```rust
<re_irc> <> pub trait SomeTrait<T> {
<re_irc> <> }
<re_irc> <> fn SomeFunc(&self, input: T) -> Result<(), Error> {...}
<re_irc> <> hard to say what's idiomatic without more info though
<re_irc> <> are these enum values a sort of "commands", where some impls support more commands than others?
<re_irc> <> in that case doing one method per command, then separating the "support level" on separate traits is maybe more idiomatic?
<re_irc> <> ```rust
<re_irc> <> pub trait SomeTrait {
<re_irc> <> fn do_command_one(&self) {...}
<re_irc> <> It's related to this PR I've been working on:
<re_irc> <> The enum values are the possible DMA request inputs.
<re_irc> <> 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> <> but not all DMA channels can do all peripherals, that's why I have the `Result` in the return type right now.
<re_irc> <> The `pub trait SomeTrait<T>` seems nice, but that would rule out the single public enum.
<re_irc> <> ohhh, stm32 dma 🤣
<re_irc> <> cursed
<re_irc> <> other hals do it at type-level instead of with a "request line" enum
<re_irc> <> with traits to enforce you can only use the right lines on the right channels
<re_irc> <> for embassy-stm32 each peripheral defines its own TxDma/RxDma traits
<re_irc> <> like, `impl TxDma<USART1> for DMA2_CH3`
<re_irc> <> 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> <> Yes, seems logical, the F4 one seems interesting, I'll take a deeper look, thanks!
<re_irc> <> I think we've chatted about this before, and there are a number of ways you can do this. One example:
<re_irc> <> - See feature gates for this. Treat anything gated for `H7` or `G4` as your L4+ MCUs, and the opposite as L4 basic
<re_irc> <> - an example DMA periph implementation
<re_irc> <> the F4 API has one problem where you can't use DMA for SPI for RX and TX at the same time, I wouldn't copy it
<re_irc> <> DMA module mapping inputs:
<re_irc> <> (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> <> (or maybe it's been fixed, I haven't been following closely)
<re_irc> <> In particular, example this example for a peripheral's `dma_wriet` method:
<re_irc> <> ```rust
<re_irc> <> // L44 RM, Table 41. "DMA1 requests for each channel"
<re_irc> <> #[cfg(any(feature = "f3", feature = "l4"))]
<re_irc> <> The function has a `dma_channel` arg, for use with DMAMUX. Ie, you pass the channel to the function for L4+
<re_irc> <> If on an older MCU that doesn't use DMAMUX, choose the correct hard-set channel
<re_irc> <> And if on L4 (not +!), do `channel_select`, which no other STM has!!
<re_irc> <> 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> <> For non-MUX, it ignores the `dma_channel` argument, and chooses the right one for you
<re_irc> <> 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> <> how do you enforce you don't try to use the same channel for 2 things at the same time, then?
<re_irc> <> The peripherals use teh owned-register approach. So, you'd have to violate that with a `peripherals::steal` etc
<re_irc> <> Since the `read_dma`, and `write_dma` methods control which channel to use, eg in the code I copy+pasted above
<re_irc> <> Actually, I suppose you could call `write_dma(...)` twice without stopping it, and UB would happen
<re_irc> <> Thanks for the example, but that would require a lot of rewriting of the current l4-hal though.
<re_irc> <> I'd prefer to be as non-invasive as possible.
<re_irc> <> If that's what you'r egetting that, I don't enforce it
<re_irc> <> I agree - I think your approach is good. I posted for reference, and to demonstrate it can be done
<re_irc> <> yep if oyu don't have owned singletons for channel then it's not compile-time-safe :)
<re_irc> <> 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> <> (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> <> Yeah it's been added
<re_irc> <> oh I see, splitting the peripheral 👀
<re_irc> <> I still think the peri owning the DMAs (instead of in f4xx-hal the DMA owning the peri) is simpler, though
<re_irc> <> because it allows the driver to impl the "transfer" fn just like the blocking one but with DMA
bpye has joined #rust-embedded
bpye9 has joined #rust-embedded
bpye has quit [Ping timeout: 240 seconds]
bpye9 is now known as bpye
bpye6 has joined #rust-embedded
bpye has quit [Ping timeout: 240 seconds]
bpye6 is now known as bpye
bpye7 has joined #rust-embedded
bpye has quit [Ping timeout: 252 seconds]
bpye7 is now known as bpye
rardiol has joined #rust-embedded