<re_irc> <@jamesmunns:matrix.org> I think the device-driver crate from diondokter is that?
<re_irc> <@jamesmunns:matrix.org> https://crates.io/crates/device-driver
<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> ```rust
<re_irc> <@firefrommoonlight:matrix.org> #[cfg(any(feature = "f3", feature = "l4"))]
<re_irc> <@firefrommoonlight:matrix.org> where you just do `unimplemented!()` if the periph is read or write only like DMA and DAC
<re_irc> <@dirbaio:matrix.org> huh
<re_irc> <@dirbaio:matrix.org> how do you handle chips where one periph can use different channels?
<re_irc> <@firefrommoonlight:matrix.org> Make those calls behind a feature gate
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> let channel = R::write_chan();
<re_irc> <@firefrommoonlight:matrix.org> #[cfg(any(feature = "f3", feature = "l4"))]
<re_irc> <@firefrommoonlight:matrix.org> #[cfg(feature = "l4")]
<re_irc> <@firefrommoonlight:matrix.org> R::write_sel(dma);
<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> ```rust
<re_irc> <@firefrommoonlight:matrix.org> #[cfg(any(feature = "f3", feature = "l4"))]
<re_irc> <@firefrommoonlight:matrix.org> DacChannel::C1 => DmaInput::Dac1Ch1.dma1_channel(),
<re_irc> <@firefrommoonlight:matrix.org> let dma_channel = match dac_channel {
<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> <@dirbaio:matrix.org> yup
<re_irc> <@theunkn0wn1:matrix.org> | 7 | 6 | 5 |4 | 3|2|1|0
<re_irc> <@theunkn0wn1:matrix.org> thanks!
hosewiejacke has joined #rust-embedded
<re_irc> <@theunkn0wn1:matrix.org> ```rs
<re_irc> <@theunkn0wn1:matrix.org> error_low(RO, 14, 8) = LSB {
<re_irc> <@theunkn0wn1:matrix.org> awiting_command: u8 as Bit=RO 1..= 1,
<re_irc> <@theunkn0wn1:matrix.org> // Bit 0 is LSB; held clear by protocol.
<re_irc> <@theunkn0wn1:matrix.org> that would mean this is reading the wrong way round?
hosewiejacke has quit [Client Quit]
<re_irc> <@theunkn0wn1:matrix.org> error_low(RO, 14, 8) = LSB {
<re_irc> <@theunkn0wn1:matrix.org> ```rs
<re_irc> <@theunkn0wn1:matrix.org> awiting_command: u8 as Bit=RO 7..= 7, // Bit 0
<re_irc> <@theunkn0wn1:matrix.org> no_power: u8 as Bit=RO 6..= 6, // Bit 1
<re_irc> <@theunkn0wn1:matrix.org> ?
<re_irc> <@dirbaio:matrix.org> if `awiting_command` is the least significant bit (bit 0) you want
<re_irc> <@dirbaio:matrix.org> `awiting_command: u8 as Bit=RO 0..= 0,`
<re_irc> <@theunkn0wn1:matrix.org> bit zero should be `awaiting_command`, yes
<re_irc> <@theunkn0wn1:matrix.org> little endian confuses me :(
<re_irc> <@dirbaio:matrix.org> little/big endian is about how bytes are ordered
<re_irc> <@dirbaio:matrix.org> if you only have one byte, it makes no difference
<re_irc> <@theunkn0wn1:matrix.org> ah
<re_irc> <@theunkn0wn1:matrix.org> technically this is split up over two bytes; but each byte can be independently requested
<re_irc> <@theunkn0wn1:matrix.org> I have a total of 15 bits
<re_irc> <@dirbaio:matrix.org> if it's little endian, the first byte will be bits 7..0, the second byte will be bits 15..8
<re_irc> <@theunkn0wn1:matrix.org> it is indeed little endia.
<re_irc> <@theunkn0wn1:matrix.org> ```rs
<re_irc> <@theunkn0wn1:matrix.org> // Command 0xB3
<re_irc> <@theunkn0wn1:matrix.org> // 0xB3 - 0xA1 = 18
<re_irc> <@theunkn0wn1:matrix.org> // reads two bytes: 0xA1 + offset
<re_irc> <@theunkn0wn1:matrix.org> would this be sensible for interpreting both bytes at the same time?
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
fabic_ has quit [Ping timeout: 265 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@huszty:matrix.org> I would have a basic question around embedded_hal and this shift register driver: https://docs.rs/shift-register-driver/0.1.1/shift_register_driver/
<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> <@ryan-summers:matrix.org> Check out Stabilizer's, which also uses a 16-bit timer from an STM32H7: https://github.com/quartiq/stabilizer/blob/master/src/hardware/system_timer.rs#L96
<re_irc> <@korken89:matrix.org> andres: Here you can find an extended 16bit timer for the L4 https://github.com/stm32-rs/stm32l4xx-hal/blob/rtic_0.6_monotonic/src/timer.rs#L219
<re_irc> <@korken89:matrix.org> It should be straight forward to port
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
xnor has quit [Ping timeout: 246 seconds]
xnor has joined #rust-embedded
emerent has quit [Remote host closed the connection]
creich_ has joined #rust-embedded
emerent has joined #rust-embedded
creich has quit [Ping timeout: 265 seconds]
xnor has joined #rust-embedded
xnor has quit [Changing host]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
<re_irc> <@dirbaio:matrix.org> is there something like map_err but without closure?
<re_irc> <@dirbaio:matrix.org> instead of `Vec::from_slice(name).map_err(|_| Error::Truncated)?`
<re_irc> <@dirbaio:matrix.org> something like `Vec::from_slice(name).or_err(Error::Truncated)?`
<re_irc> <@thalesfragoso:matrix.org> dirbaio:matrix.org: `res.or(Err(Error::Truncated))`
<re_irc> <@thalesfragoso:matrix.org> Not exactly what you want, i.e. one enum more
<re_irc> <@dirbaio:matrix.org> yeah, doesn't make it cleaner
<re_irc> <@dirbaio:matrix.org> the useless closure *sliiightly* bothers me lol :D
<re_irc> <@dirbaio:matrix.org> was hoping for something like `my_option.ok_or(Error::Foo)?`
<re_irc> <@dirbaio:matrix.org> look at that
<re_irc> <@dirbaio:matrix.org> so clean
<re_irc> <@thalesfragoso:matrix.org> Time to PR std, the inner code would be the same as using or though
<re_irc> <@thalesfragoso:matrix.org> I mean, the generated one
<re_irc> <@dbrgn:matrix.coredump.ch> andres: I have a 0.5 Monotonic for STM32L071, would that help?
<re_irc> <@dbrgn:matrix.coredump.ch> andres: here's the "official" example, I don't think it changed since I submitted it: https://github.com/rtic-rs/rtic-examples/tree/master/rtic_v5/stm32l0_monotonic
<re_irc> <@oddstr13:matrix.org> dirbaio: Testing the 6LoWPAN now, however it doesn't seem like ndisc is actually working properly
<re_irc> <@oddstr13:matrix.org> Seems it is sending a request, and when receiving a request it updates it's own cache, but doesn't send a response
<re_irc> <@oddstr13:matrix.org> never mind, I did a 💩 and screwed up the static addressing
<re_irc> <@oddstr13:matrix.org> `:dead:` is indeed *actually* a dead address >,<
<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> <@dbrgn:matrix.coredump.ch> Ah, I see!
<re_irc> <@dbrgn:matrix.coredump.ch> andres: alternatively, two 16-bit timers can also be linked in hardware to get a 32-bit timer: https://github.com/stm32-rs/stm32l0xx-hal/blob/50c10535a0c4c92a3402d21106b71880140ac9fd/src/timer.rs#L243-L253
<re_irc> <@dbrgn:matrix.coredump.ch> the overflow of the first timer triggers the second timer.
dreamcat4 has quit [Ping timeout: 245 seconds]
darknighte has quit [Ping timeout: 268 seconds]
edm_ has quit [Ping timeout: 250 seconds]
nohit has quit [Ping timeout: 260 seconds]
SanchayanMaity has quit [Ping timeout: 268 seconds]
<re_irc> <@uebelandre:matrix.org> Hey, is does anyone around these parts have the power to make a new release of `cross`? https://github.com/rust-embedded/cross/issues/542
<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?
<re_irc> <@adamgreig:matrix.org> I think https://github.com/rust-embedded/cross/pull/461
<re_irc> <@uebelandre:matrix.org> Can you comment on the release ticket with remaining steps to get releases unblocked?
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded