Closed DoumanAsh closed 6 years ago
Are you planning to move forward with this design? I do still find it very hard to read, and very foreign to the convention used in most other HALs.
Edit: I'll add that I'd be happy to do the work to convert the hard work (the configuration code itself) to the other mode, I just don't want to step on your toes.
@thenewwazoo Yeah I'm still thinking about that. The thing is that the way other HALs are using these traits are without actual use, only as trait bounds.
I don't want these traits to be jsut trait bounds. So I've been thinking of making set of traits for each PIN, and which would automatically help to implement method that consumes these pins in order to create SPI. Instead of doing this macro. Sorry I just don't have time with all this stuff to properly work on it, but I'll ping you once again to review
Also what is particularly difficult about this code? It is basically:
use <hal>::spi::Spi;
let pe13 = gpio.PE13.into_alt_fun::<AF5>(...);
let pe14 = gpio.PE14.into_alt_fun::<AF5>(...)
let pe15 = gpio.PE15.into_alt_fun::<AF5>(...)
let spi1 = (pe13, pe14, pe15).spi(SPI1. 5_000, spi::Mode, &mut APB, &Clocks);
SPI has been refactored(temporarily stored original code in spi2.rs)
Now we have generic traits for SCK, MOSI and MISO. Each trait stores SPI index that is used at runtime to verify if correct pin is passed.
Each stm32l4 crate SPIs now implement special trait InnerSpi
to provide a generic interface.
It works thanks to the fact that all register blocks are shared among SPIs
SPI3 pins are not implemented yet, due to the fact that they re-use other pins. I wonder if we should impl it?
@thenewwazoo Feel free to take a look at my idea and share your thoughts. This is how I believe we should approach the problem, making everything generic 😄
@thenewwazoo I'd appreciate if you could review?