Open Dirbaio opened 10 months ago
i'm going to remove this from the 1.0 milestone,
It concerns only embedded-hal-bus
, we can do it in 0.1.1
in a backwards-compatible way (like adding .set_blah_delays()
methods), or in 0.2
if we don't want to be compatible.
Hello! Thank you very much for this amazing set of crates that makes Rust embedded system usage so convenient.
I would like to know if there is any plan to support this feature as its necessary to drive chips like the LTC6813
If there is but no one is currently working on it, I would be pleased to be given direction in order to help implement this!
I have previously worked on enabling this in the esp-idf-hal
at a higher level to access existing C API, but didn't touch yet to this set of crates in more details.
At first sight I would say, adding a parameter in the Device creation function, as well as a field in the Device struct to store a delay duration and using the delay_ns()
function after this line https://github.com/rust-embedded/embedded-hal/blob/a0ccb6579669804e9be723912ed645a16362c8a6/embedded-hal-bus/src/spi/exclusive.rs#L119 could do the trick? But I am not sure how/where the clock is controlled.
If that's alright i would be happy to provide a PR for this
Could the SPI SCLK frequency be also added? This is very useful when multiple devices share the same SPI bus, and is very common.
As discussed in today's meeting:
It is better if the CS-assert-to-clock and clock-to-CS-deassert delays are configured in the SpiDevice itself, so that the driver doesn't have to add them to every single transaction, and can use the
read
/write
/write_read
convenience methods.embedded-hal-bus
to do the delaysOperation::DelayNs
directly for CS-to-clocks delays.