Combine samd11 and samd21 into common/thumbv6m using feature flags

[glaeqen]

• Remove reference to samd21 module from BSCs
• Combine samd11 and samd21 into common/thumbv6m using feature flags

[jacobrosenthal]

This is also a breaking change to bsps as it shuffles around the exports and also as a result changes the documentation. If that is a change that is wanted, Im not sure why it would be included in this pr and not as its own separate change

[glaeqen]

@jacobrosenthal When it comes to API breakage, this PR only expands existing API and preserves existing one fulfilling semver's requirement for a minor change (not true for samd{1,2}1 changes, removed public module from src/lib.rs; My mistake, I was only thinking about changed re-exports in BSCs). Considering a documentation change (namely a re-export note) seems really strict for me. New re-exports populate the same (or more) symbols in the namespace in a cleaner way while being effectively undisruptive for an end user. I guess it boils down to where one decides to put the boundary of "API breakage". Every piece of code built against these crates will keep compiling with these changes in place.

I can put export shuffling in other PR if that's a problem. I decided not to because this PR will contain re-export changes either way but limited to removal of samxXX references.

[glaeqen]

@jacobrosenthal I decreased the scope of this PR.

[jacobrosenthal]

To be clear I think what the public api looks like is a valuable conversation i just would expect some explanation what api is being refactored towards and why.

I cant personally speak to what people want to collapse the features down to, others have been refactoring along these lines for a while now and I presume theyll weigh in

[bradleyharden]

I like these changes. I actually don't think it goes far enough. But I agree with @jacobrosenthal that I would like to see some conversation about the public API. Several changes have been moving in this general direction, but we haven't really decided on a vision for a refactored API.

I would suggest getting rid of the common module altogether. Now that all of the chip-specific directories are gone, I don't see any need for it. We can just elevate all the existing modules. I think that would be clearer and more intuitive.

I would also like to see a consistent naming scheme for embedded-hal, atsamd-hal and the BSPs. I think I've seen instances where all three of them have been imported as hal, which I think is really confusing. I would propose that all BSP examples import the BSP as bsp. And I would propose we somehow distinguish between embedded-hal and atsamd-hal in a consistent way. I would suggest two options: either ehal & hal, or hal & sam respectively. I don't have a strong preference for any particular name, but I don't like using the same name for different crates throughout the project.

By the way, thanks @vccggorski for getting rid of the last two chip specific directories. I did some similar refactoring a while back for the sercom module. At the time, I thought about doing this as well, but I didn't want to get sidetracked.

[bradleyharden]

Note, @jacobrosenthal started some discussion on a similar topic in #357.

[glaeqen]

@bradleyharden

I like these changes. I actually don't think it goes far enough. But I agree with @jacobrosenthal that I would like to see some conversation about the public API. Several changes have been moving in this general direction, but we haven't really decided on a vision for a refactored API.

I would also like to see a consistent naming scheme for embedded-hal, atsamd-hal and the BSPs. I think I've seen instances where all three of them have been imported as hal, which I think is really confusing. I would propose that all BSP examples import the BSP as bsp. And I would propose we somehow distinguish between embedded-hal and atsamd-hal in a consistent way. I would suggest two options: either ehal & hal, or hal & sam respectively. I don't have a strong preference for any particular name, but I don't like using the same name for different crates throughout the project.

Note, @jacobrosenthal started some discussion on a similar topic in #357.

I think that this comment of yours should definitely be a part of a thread #357. In my next PR (after getting that one merged in) I planned to change BSPs even further. At this point, the most reasonable option is to join my and @jacobrosenthal effort from December and continue the discussion there.

By the way, thanks @vccggorski for getting rid of the last two chip specific directories. I did some similar refactoring a while back for the sercom module. At the time, I thought about doing this as well, but I didn't want to get sidetracked.

Also to @vcchtjader! :) He was doing the heavy lifting here

I would suggest getting rid of the common module altogether. Now that all of the chip-specific directories are gone, I don't see any need for it. We can just elevate all the existing modules. I think that would be clearer and more intuitive.

Definitely agree. I'll start working on that. Actually, I presume that you'd rather see that in a separate PR, correct @bradleyharden? If so, what is still missing to get this PR merged?

[bradleyharden]

I would be fine with merging. The changes are technically breaking, but upgrading would be trivial. I think @jacobrosenthal might want to see a more complete vision for the end point though.

I think I can summarize the proposed end point discussed so far as:

• Remove chip-specific modules and common module.
• Make the thumb modules private, to indicate that they are an implementation detail.
• Consider the remaining modules public and let them become the official API.
• Rename imports across the HAL and the BSPs to increase consistency and clarity
• Update the BSPs to re-export the HAL itself, rather than modules within the HAL. I think that's what @jacobrosenthal was getting at in Harmonize bsp api with an eye towards clean docs #357.

Am I missing anything? Is this a sufficiently detailed vision? If so, I say let's implement it.