search

DoumanAsh / stm32l4x6_hal

HAL for the STM32L4x6 family of microcontrollers
https://doumanash.github.io/stm32l4x6_hal/
Other
1 stars 4 forks source link

Future Plan #14

Open DoumanAsh opened 5 years ago

DoumanAsh commented 5 years ago

Need to finish following parts for release:

@thenewwazoo Did you want to make PR for UART?

nickray commented 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.

DoumanAsh commented 5 years ago

Yeah I noticed it yesterday, I guess I gonna deprecate my HAL in favour of yours

nickray commented 5 years ago

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.

DoumanAsh commented 5 years ago

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

thenewwazoo commented 5 years ago

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.

DoumanAsh commented 5 years ago

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)

DoumanAsh commented 5 years ago

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

nickray commented 5 years ago

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 :)

DoumanAsh commented 5 years ago

@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 😄

nickray commented 5 years ago

@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.