Replies: 4 comments 6 replies
-
|
CC to relevant parties: @michalfita, @jamesmunns, @tstellanova, @perlindgren, @ju6ge. |
Beta Was this translation helpful? Give feedback.
-
|
No need to CC me, I closely monitor this repo. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not closing #21 yet, as I need it for work on #23 that's paused as I need to find time to polish the MVP. And I have to have CI to be confident about that approach. Are you saying the effort to move to use cmsis-svd effort wasn't needed? It was your PR actually, why you've changed your mind? |
Beta Was this translation helpful? Give feedback.
-
When developing locally, cargo have a tendency to pull down (seemingly) the whole history of cmsis-svd, a 5GB transaction, even when it is not necessary (it has been downloaded previously while working in a private branch for example; and in the end, cmsis-svd is only used to generate the PACs which are already available). This breaks the work-flow temporarily, but long enough to lose a train of thought. Some local configuration can probably mitigate this but I haven't investigated it. Vendoring the SVDs in-repo also allows us to quickly update them without waiting for an upstream merge. In summary: simplicity and performance reasons. |
Beta Was this translation helpful? Give feedback.
-
|
OK, that were my thoughts from the start... Looks like STM32 PAC do some magic and then derive crates from combination of the common code extracted from ARM core peripherals and specific STM32 peripherals for various models. Pretty tough thing TBH. |
Beta Was this translation helpful? Give feedback.
-
IIRC my initial reasoning was that using a submodule would keep things less fragmented. I did not anticipate the resultant overhead.
The STM32 ecosystem is likely much more diverse than our rather simple 4-chip MCU family. |
Beta Was this translation helpful? Give feedback.
-
I've checked and it seems most popular PAC crates are on MIT/Apache 2.0 now, so 0BSD isn't that common anymore. So that's OK, but I have proposal: Let's do #21 (I can update to newest What do you think? |
Beta Was this translation helpful? Give feedback.
-
The branch I'm finishing up has the most recent SVDs:
I've forgotten what release cmsis-svd is at. It also:
If you need it for #23 I suggest rebasing it upon the upstream branch when it's ready. Merging it as-is would lead to 50K merge conflicts. |
Beta Was this translation helpful? Give feedback.
-
|
Chiming in here - I haven't done any additional work with the atsams since my original work referenced in #14. I may resume that work later in the year, but not sure. I'll probably unfollow this thread (I don't have much to add!), but feel free to re-@ me (or email me) if you need any specific feedback. |
Beta Was this translation helpful? Give feedback.
-
|
The only features not covered by internal work thus far, but by your fork, is the GMAC and |
Beta Was this translation helpful? Give feedback.
-
Following up from #16 and ju6ge/atsamx7x-hal#1, a green light has been given to open-source the internal work done on this HAL at @GrepitAB.
The branch should cleanly merge with
development. Before I create the PR I have a CI to port. The now deprecated #16, #18, and #21 can be closed. #21 has deprecated due to svd2rust updates and new SVDs published by Microchip. PACs are now vendored in the repository instead of via a submodule for simplicity.Of note is a license change from 0BSD to dual-license MIT/Apache 2.0 (in order to mirror the license of other dependencies such as RTIC and the overwhelming majority of Rust crates, and keep any eventual legal work to a minimum). The change is license-compatible and equally permissive.
While I work on finishing touches I request co-ownership of the organization and crates.io entries for bus-factor mitigation reasons.
Beta Was this translation helpful? Give feedback.
All reactions