tstellanova / atsame7xx-hal

Experimental embedded rust hal crate for Atmel SAM E7xx microcontrollers
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

No need to copy efforts #1

Open michalfita opened 4 years ago

michalfita commented 4 years ago

There is no need to copy efforts and creating another repository for different crate if atsamx7x-hal is intended to support them all.

If there would be more people involved we could move the repository into organization and separate crates using common code for device drivers. The whole family uses peripherals based on the same hardware design, so it's better to reuse than diverge.

ju6ge commented 4 years ago

Hey I just found this repo and I have been following your repo @michalfita for a while, and sadly at that point it did not really help me much when trying to get up and running with the board I am using. This is not meant as a critic.

Because of this I have been working on my own implementation of an hal: https://github.com/ju6ge/atsamx7x-hal. I did this mostly to keep things simple and not having to worry about different mcus in the beginning when coming up with all the abstractions. At this point I have working clock init, gpio, serial, delays and sdram initialization working. I am interested in getting involved in adding this to a more common organization/repo.

michalfita commented 4 years ago

@ju6ge you're third person in need for working HAL on SAMx7x - the crucial aspect of me keeping as much as generic as possible. I already mentioned my idea of framework to @tstellanova in his pull request.

What do you both say about creating organisation on GitHub (like atsamd-rs did) and move your efforts there? Then we could split my repo into one for PAC and one for HAL and create one for Framework (if that's suitable).

ju6ge commented 4 years ago

@michalfita I am strongly in favor of keeping the PAC and HAL in seperate repos, that makes things a lot more manageable. And putting this into an org would probably be best.

The work I have done is strongly inspired by the way stm32 folks have implemented things. So we could use it as a starting point for the HAL part.

michalfita commented 4 years ago

@ju6ge Let me work on that, maybe not today, however.

About STM32 inspiration - it's super fine for many of the stuff, but as Atmel's require a lot of boilerplate for many components, I had idea of rewrite some of ASF into a Framework in Rust and just call these from HAL. @tstellanova suggested separate HALs for each family, so atsams7x-rs, atsame7x-rs and atsamv7x-hal (where without common crate we'd need to copy a lot of stuff).

ju6ge commented 4 years ago

@michalfita @tstellanova not today is fine :+1:

I have been mostly concerned with the SAM E70/S70/V70/V71 devices since that is the one i am using. So I don't really no how big the difference to other samx7x devices in terms of implementation and peripheral initialization is. But I get what you mean, maybe we should also have a repo where we add some documentation and links to important resources.

tstellanova commented 4 years ago

Creating a github org for this seems like a good idea.

We don’t necessarily need a separate hal crate per family, assuming there’s a lot of commonality between supported families. Stm32 has some significant differences between families that make generalized support difficult. The separate crates have resulted in somewhat divergent APIs as hal maintainers lead or lag each other.

I’m am a fan of separating the hal crate from the pac. Now is a good time to separate those as the hal is not huge yet.

On Jun 10, 2020, at 9:30 AM, Felix Richter notifications@github.com wrote:

 @michalfita @tstellanova not today is fine 👍

I have been mostly concerned with the SAM E70/S70/V70/V71 devices since that is the one i am using. So I don't really no how big the difference to other samx7x devices in terms of implementation and peripheral initialization is. But I get what you mean, maybe we should also have a repo where we add some documentation and links to important resources.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.