emerent has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
dreamcat4 has joined #rust-embedded
causal has joined #rust-embedded
<re_irc>
<explodingwaffle101> dirbaio: was looking for this when writing a test today. i don't see anything wrong with a cargo feature (unless i don't understand dev-dependancies)
causal has quit [Quit: WeeChat 3.6]
bitbangerror has joined #rust-embedded
bitbangerror is now known as Guest3109
Guest3109 has quit [Changing host]
Guest3109 has joined #rust-embedded
Guest3109 is now known as bitbangerror
bitbangerror has quit [Ping timeout: 252 seconds]
bitbangerror has joined #rust-embedded
bitbangerror has quit [Changing host]
bitbangerror has joined #rust-embedded
bitbangerror has quit [Quit: Client closed]
<re_irc>
<newam> Does the EH-1 need a defined way for handling the the CS pin after a bus failure? I would find this information useful for writing a driver, not sure what other people think about it.
<re_irc>
Currently I do this in my drivers, such that the CS pin is deasserted (or attempted to deassert...) even if the bus has a problem:
<re_irc>
<newam> I guess that should be added to the docs for SpiDevice?
<re_irc>
<dirbaio> i'm not sure what'd we want to doc though
<re_irc>
<dirbaio> "implementations must try to deassert CS on bus error"?
<re_irc>
<dirbaio> i'm not sure if this guarantee is useful for driver authors? like, if you get a spi bus error things are already really really broken
<re_irc>
<dirbaio> it still doesn't guarantee retrying is safe, the CS deasert might've failed too
<re_irc>
<newam> Hmm you do have a point. It would be useful on an overrun, but at the same time there's no traits for driver authors to use to recover from any such error. Handling of that class of error have to be done outside the driver with knowledge of the underlying bus, but if you're already at that point then you probably know how your CS is being handled.
<re_irc>
<newam> dirbaio: That would be returned as a "ErrorKind::ChipSelectFault" though, instead of the bus error.
<re_irc>
<dirbaio> that'd need documenting "the CS error has priority over the bus error" as well
<re_irc>
<newam> well, if implemented that way anyway, I would prioritize CS faults personally, but that's debatable
<re_irc>
<newam> yeah
<re_irc>
<dirbaio> currently ExclusiveDevice gives priority to the bus error
<re_irc>
<dirbaio> I thought the bus error would be the more "important" one, and also it's the error that happened first
<re_irc>
<dirbaio> but uh, no idea
<re_irc>
<newam> dirbaio: I guess this is my python brain acting up, in exception handling for most languages if there is an exception during cleanup of a previous exception then the cleanup exception takes priority
<re_irc>
<dirbaio> exceptions 👻
<re_irc>
<newam> tis a silly place :D
<re_irc>
<dirbaio> yeah I dunno
<re_irc>
<dirbaio> or a 3rd variant "bus error and then CS error while trying to deassert it" ☠️
<re_irc>
<dirbaio> +we could have
<re_irc>
<newam> oooo yes, we could do recursion in the EH traits!
<re_irc>
<dirbaio> I do think we should document something like "on bus error, impls should still try to deassert CS" though
<re_irc>
<newam> yeah, at least a convention if not a strict rule (same for error priority)
<re_irc>
<dirbaio> because it's the most reasonable impl, reduces the chances of something going wrong if the driver or the user decides to retry
<re_irc>
<dirbaio> but it's not a hard guarantee yeah
<re_irc>
<dirbaio> on which chips/HALs is SPI actually, really fallible?
<re_irc>
<dirbaio> for example you can't really have overrun (except HAL bugs), the hardware peripheral will simply clock it slower
<re_irc>
<newam> dirbaio: on STD development tools :D
<re_irc>
<newam> I'm working on an EH-1 impl for "ftdi-embedded-hal" which is why this came up for me
<re_irc>
<dirbaio> ahh yeah
<re_irc>
<dirbaio> if you get an error due to usb unplug, retrying is rarely going to recover it though, he
<re_irc>
<dirbaio> * heh
<re_irc>
<newam> yeah, all the errors are still relatively fatal
<re_irc>
<dirbaio> oh cortex-m 0.7.6 is already out 😍
<re_irc>
<Ivan Levitskiy> On the topic of SPI. Any good examples of a sensor crate or just driver file implementation with DMA support?
<re_irc>
<Ivan Levitskiy> Planned to look at firefrommoonlight's code but he closed the repository😥
<re_irc>
<dirbaio> Ivan Levitskiy: using the embedded-hal traits?
<re_irc>
<dirbaio> there's no traits explicitly for DMA, but HALs can implement the traits using DMA internally
<re_irc>
<dirbaio> so drivers using these can use DMA without "knowing"
<re_irc>
<Ivan Levitskiy> dirbaio: Preferably. Right now I really like how it is used in ad983x-rs
<re_irc>
<dirbaio> few HALs impl the blocking traits with DMA, because there's little advantage in using DMA in a blocking way
<re_irc>
<adamgreig> dirbaio: Though I then realised we should have documented the new feature in the crate docs, oops
<re_irc>
<dirbaio> for async, embassy-nrf and embassy-stm32 impl the uart/spi/i2c traits with DMA internally
<re_irc>
<dirbaio> so any sensor driver using the async traits can use DMA transparently
<re_irc>
<Ivan Levitskiy> I'm currently using RTIC and didn't really plan on moving to embassy
<re_irc>
<dirbaio> RTIC will likely get async support soon :)
<re_irc>
<dirbaio> the other way to use DMA is with the hal-specific APIs, manually managing interrupts. That's what firefrommoonlight was doing in his code I think
<re_irc>
<dirbaio> which gives you lower-level control, but then the driver is not portable between HALs/chips
<re_irc>
<newam> You can also do out-of-your-main-application RTIC tasks for interrupts now too (I think?)
<re_irc>
<dirbaio> "extern tasks" yeah, but that doesn't help with portability
<re_irc>
<Ivan Levitskiy> That looks like what I will be doing too. I don't really need the portability currently.
<re_irc>
<Ivan Levitskiy> But would be nice if there could be a way to implement it, as now I'm using the mpu9250 crate and the blocking read is too slow for me
<re_irc>
<dirbaio> blocking SPI will always be blocking. DMA won't make it faster because the CPU will still waste time spinning waiting for DMA to finish
<re_irc>
<newam> Unless there's a higher priority interrupt that doesn't need to use the DMA
<re_irc>
<Ivan Levitskiy> dirbaio: I totally understand this, the MCU has other stuff to do till the DMA tx end interrupt
<re_irc>
<dirbaio> so you can either switch the driver to use the async trait + use a HAL that impls the trait with DMA
<re_irc>
<dirbaio> or
<re_irc>
<dirbaio> copypaste the driver into your project and make it use your particular HAL's interrupt-based DMA API