<re_irc>
<@theunkn0wn1:matrix.org> That looks like what im looking for, il look into it thanks!
<re_irc>
<@fyl2xp1:matrix.org> Thanks everyone.
<re_irc>
<@fyl2xp1:matrix.org> korken89 The NUCLEO-H743ZI2 looks very oversized for driving two LED strips.
<re_irc>
<@firefrommoonlight:matrix.org> dirbaio: I applied a similar change to F3 and L4's channel-selection quirks. I'd been leaning on the `xDevice` enum before too
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure if you do something similar there too, but your same approach works there too to identify the (non-DMA-mux-hardset) channel for a given periph, and to use L4's unique channel selection process
<re_irc>
<@firefrommoonlight:matrix.org> eg:
<re_irc>
<@firefrommoonlight:matrix.org> impl DmaPeriph for pac::SPI3 {
<re_irc>
<@firefrommoonlight:matrix.org> Ie that is only if you don't have DMAMUX, in which case it's not used
<re_irc>
<@dirbaio:matrix.org> for example STM32L486VG USART1 RX can be DMA1_CH5 or DMA2_CH7, the user can choose
<re_irc>
<@firefrommoonlight:matrix.org> Ah - I haven't implemented the secondaries yet. That's a good consideration that I've dodged for now
<re_irc>
<@dirbaio:matrix.org> embassy does it by flipping the trait around
<re_irc>
<@dirbaio:matrix.org> impl UsartRxDma<USART1> for DMA1_CH5 {}
<re_irc>
<@dirbaio:matrix.org> impl UsartRxDma<USART1> for DMA2_CH7 {}
<re_irc>
<@firefrommoonlight:matrix.org> You could perhaps take advantage of identifying wheather it's on DMA1 or DMA2 in the same way. Traitception?
<re_irc>
<@firefrommoonlight:matrix.org> Nice
<re_irc>
<@dirbaio:matrix.org> I think there are some where you can choose multiple chans in the same DMA tooo...
<re_irc>
<@firefrommoonlight:matrix.org> Hah. That would break the traitception approach
<re_irc>
<@dirbaio:matrix.org> so the uart driver Usart<T> requires `where chan: UsartRxDma<T>`
<re_irc>
<@dirbaio:matrix.org> so the user can pass either of the channels
fabic_ has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> The simpler but not-user-friendly approach is to say "supply the correct channel as an argument"
<re_irc>
<@firefrommoonlight:matrix.org> My current approach is a compromise of forcing the user into the first (usually DMA1) option on the non-MUX MCUs
<re_irc>
<@firefrommoonlight:matrix.org> Your approach is more flexible
<re_irc>
<@dirbaio:matrix.org> also there are peris where you don't have "rx+tx channels"
<re_irc>
<@firefrommoonlight:matrix.org> What do you mean?
<re_irc>
<@dirbaio:matrix.org> SAI has A/B, I think it can do tx+tx or rx+rx (?)
<re_irc>
<@firefrommoonlight:matrix.org> Ah. Yea. I was saving SAI until tomorrow!
<re_irc>
<@firefrommoonlight:matrix.org> DAC is the same way
<re_irc>
<@dirbaio:matrix.org> and TIM1s can have lots of DMA channels for each TIM channel or something
<re_irc>
<@firefrommoonlight:matrix.org> I dodge that by only having implemented DAC1 for DMA, so the dac_channel controls which DMA channel to use. But this won't work for DAC2 on MCUs that have it
<re_irc>
<@dirbaio:matrix.org> so you can't simply `impl DmaPeriph for pac::TIM1` :(
<re_irc>
<@firefrommoonlight:matrix.org> Good to know on TIM1. ST timers... urg
<re_irc>
<@fyl2xp1: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.
<re_irc>
<@fyl2xp1:matrix.org> Thanks a lot. They look perfect, hardware-wise. I'm not sure if I want to take the risk to fight against the toolchain (again).
<re_irc>
<@firefrommoonlight:matrix.org> It seems you've exposed teh flaws in my approach, at least for beyond the basic cases
<re_irc>
<@firefrommoonlight:matrix.org> I wish they all used MUX!
<re_irc>
<@dirbaio:matrix.org> dmamux is super nice
<re_irc>
<@firefrommoonlight:matrix.org> And L4 didn't do the weird channel select thing
<re_irc>
<@firefrommoonlight:matrix.org> Speaking of SAI... I recently discovered, the Serial Audio Interface, is not, in fact, the best peripheral to use for PDM mics, despite a long section of the SAI RM chapter dedicated to it
<re_irc>
<@firefrommoonlight:matrix.org> I think that TIM1 bit you posted has to do with why it's an "advanced control" timer. I haven't looked into what advantages that gives you over GP
<re_irc>
<@dirbaio:matrix.org> yea, it's just an example of "not rx+tx"
<re_irc>
<@dirbaio:matrix.org> modeling it as "a peripheral has a rx channel and a tx channel" doesn't match reality
<re_irc>
<@dirbaio:matrix.org> reality is
<re_irc>
<@dirbaio:matrix.org> - a peripheral kind has a set of "dma functions", such as rx, tx, ch1, com, trg, up
<re_irc>
<@dirbaio:matrix.org> - each (peripheral, function) pair can be fulfilled by
<re_irc>
<@dirbaio:matrix.org> - Exactly one channel: F1, L1, some F0s, F3
<re_irc>
<@firefrommoonlight:matrix.org> Good model
<re_irc>
<@dirbaio:matrix.org> it's mega cursed 🤣
<re_irc>
<@firefrommoonlight:matrix.org> I'm really tempted to drop F4 support to reduce complexity
<re_irc>
<@firefrommoonlight:matrix.org> But that's a bit of a tangent
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@theunkn0wn1:matrix.org> > Each error condition corresponds to a bit in the “Error flags halting” and “Error flags occurred” variables. Bit 0 is the least-significant bit. The Jrk uses little-endian byte order, so the first byte of each variable contains bits 0 through 7, and the second byte contains bits 8 through 15.
<re_irc>
<@theunkn0wn1:matrix.org> If i interpret this correctly, a byte will appear in the form `0x0xxx_xxxy` where `y` is bit zero yes?
<re_irc>
<@huszty:matrix.org> I am unable to use it with the up-to-date stm32fxx crates because:
<re_irc>
<@huszty:matrix.org> the trait `stm32f4xx_hal::prelude::_embedded_hal_digital_OutputPin` is not implemented for `PA3<Output<PushPull>>`
<re_irc>
<@huszty:matrix.org> Is it so that this oldish driver wants to use the v1 version of the OutputPin which is deprecated and not produced the current stm32f4 like this? `Peripherals::take().unwrap().GPIOA.split().pa0.into_push_pull_output()`
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
<re_irc>
<@diondokter:matrix.org> theunkn0wn1:matrix.org: If you need to know something or miss something, then let me know!
<re_irc>
<@andresv:matrix.org> Anybody happens to have RTIC 0.6 Monotonic for `STM32L051` or similar. It has 16bit timers.
<re_irc>
<@dirbaio:matrix.org> wohoo, so it works? :D
<re_irc>
<@oddstr13:matrix.org> Had to update my interfacing code to remove the crc bit again, but yes, ndisc is working now
<re_irc>
<@oddstr13:matrix.org> I have not tested it against other implementations however
<re_irc>
<@andresv:matrix.org> Danilo: i modified korken's L4 version and it seems to be working, what i really like in this version is that it expands 16 bit timer to 64 bits
<re_irc>
<@dbrgn:matrix.coredump.ch> andres: using a master/slave setup, or some other trick?
<re_irc>
<@uebelandre:matrix.org> It'd be a tremendous help. If release notes are the blocker, I don't think too many folks would care if they were just a link to the list of commits since the last release
nohit has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
edm_ has joined #rust-embedded
darknighte has joined #rust-embedded
dreamcat4 has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> My recollection is there's some blocking issue preventing a release
<re_irc>
<@uebelandre:matrix.org> Do you have a link for the tracking ticket?