Open DoumanAsh opened 5 years ago
How about: join forces with https://github.com/MabezDev/stm32l4xx-hal? I'm finishing RNG, and planning to work on USB next.
Yeah I noticed it yesterday, I guess I gonna deprecate my HAL in favour of yours
Do one of you have the time to merge this crate via a pull request? I won't be having access to any 4x6 boards anytime soon.
Well if I'm going to deprecate my crate, I'd like to merge stuff, but my approach to API is often different(to a better I want to believe) so it wouldn't really straight forward merge. But I'll try to see how much of difference there is before merging: most troubles would be RCC, GPIO and SPI
I’ve only got a few concerns:
I think it might be possible to combine all of the members of the L4 family into a single crate, but my own experience tells me that the macro abstractions will have to be cleaned up and made more “atomic” in order to enable/disable them per device feature. This means strictly and cleanly decoupling the implementation from the particulars of the device, most importantly in a concise way. (This will sound familiar to @DoumanAsh 😉)
I haven’t done any sort of data sheet cross-reference to account for inter-device differences in the implementation itself, but based on how the L0x1 crate has gone, I suspect initial efforts should expect to have, basically, a feature-per-datasheet (e.g. I have STM32L031K4_K6
and STM32L011K3_K4
). I also think it would help immensely if we target exactly two chips as being “tier 1” and require that both be implemented before merge. This approach has helped me already.
Lastly, omnibus crates are not the place for API experimentation, imho. I’d like to see closer adherence to the reference crates where possible. I think this crate could continue to have a life as a place for experimentation.
Lastly, omnibus crates are not the place for API experimentation, imho. I’d like to see closer adherence to the reference crates where possible. I think this crate could continue to have a life as a place for experimentation.
Ah, the fun of making cool API, well yeah we can leave this crate for that purpose 😄
I still haven't looked into yet so I cannot say how easy it would be, but amoung of conditional compilation could be enormous(well it would be easier if we could split things into module per datasheet)
I decided not to deprecate this crate and will try my best to maintain it @nickray But I'll also try to see if I can help with your crate by migrating useful changes
Cool. I personally think that there is no fixed in stone "best practice" for a HALs yet - I find the existing ones all not too user friendly. Perhaps it would make sense generally to have a task force that not only discusses possible traits (as is happening), but also actively implements and uses them in real projects.... Specifically, for my project I absolutely need RNG and USB implementations, and can't wait for the "best practices" to be established, yet also I want to avoid contributing to two different HAL repositories in parallel if possible.
Summing up, I think if either of you have interesting ideas on how to improve the HALs, it would be interesting to have that implemented in stm32l4-hal also :)
@nickray I do not want to rise jut issue to ask at repo, but do you know what is general approach MabezDev has for device specific parts? I see there are some instances of conditional compilation but they are pretty rare.
P.s. honestly i'm not even sure where to find all common elements for all stm32l4
but I'd just ask @thenewwazoo about it 😄
@DoumanAsh I think he's just writing the HAL originally as stm32l432xx-hal
for his thesis, and I tried to convince him that we should do an stm32l4-hal
. So basically none of his stuff will be device-specific currently.
Need to finish following parts for release:
@thenewwazoo Did you want to make PR for UART?