How to share, and what

[jacobrosenthal]

SVDs and Pacs
To be honest the stm32 attempt to unify all svds stuff using feature gates looks really complex to me https://github.com/stm32-rs/stm32-rs

This guy was attempting to unify efm32 crates
https://github.com/rqou/efm32-unified-crate

Honestly Im not super excited about that. Id rather duplicate now and deal with this later when we have more implementations vs trying to generate all implementations today we could possibly support today.

That said if someone else wanted to do all that work I wouldnt stop them.

I like the nrf52-hal-common pattern in nrf52-rs
https://github.com/nrf-rs/nrf52-hal/tree/master/nrf52-hal-common

Any ideas which peripheral blocks are common on efm32 families?

Im guessing all the cortex m peripherals are very similar?

[chrysn]

The cortex-m peripherals are well covered by the cortex-m crate.

I agree with your assessment of the efm32-unified approaches. I see the shortcomings of the individually-maintained-SVD-crates approach, but unless someone involved is involved in the process of building something better, I'd rather maintain the 6 or 7 individual crates properly, and move over to whatever comes after svd2rust when that's ready for production use.

It'll help a lot to think precisely about which chips a register crate can encompass. From the sub-series I know, the first generations (gecko, tiny gecko, giant gecko) can be a single PAC per chip series (ie. one efm32g, one efm32gg, one efm32tg) – all in which they differ for our purposes is which pins are bonded to an actual pin.

That pattern has been abolished with the newer series; for EFR32 I've determined that EFR32xG1 is a pattern that works as far as the SVDs are concerned. That might be extensible to EFR32xG12, but that needs to be checked before creating them.

For the HAL, so far having a single hal works well with efm32gg-hal which, contrary to the legacy name, supports both efm32gg and efr32xg1. SiliconLabs manage to do it in C with emlib, so I'd say we'll manage that too. I'm using features there with "private" sub-features that are enabled by the chip selection. We can still move to a -hal and -hal-common pattern, but the generations are not quite cleanly set (or at least I don't see them clearly), so it's probably better to start with a single HAL.

[jacobrosenthal]

I agree with your assessment of the efm32-unified approaches

Excellent. Ill bring my efm32hg309f64-pac in here. Speaking of naming Im generating from the efm32hg309f64 svd but I with memory is handled outside the PAC that could probably be renamed and to efm32hg309 ? Thoughts on this?

It'll help a lot to think precisely about which chips a register crate can encompass

I don't have prior knowledge here. My first and only SI labs chip is this efm32hg Thoughts on how that shares? Ill fork your hal and see what I see and do some research myself

For the HAL, so far having a single hal works well with efm32gg-hal which, contrary to the legacy name, supports both efm32gg and efr32xg1.

If you think we can do it in a single hal, lets do it. You're farther along than @fudanchii and I so Im happy to go with with your existing work

The cortex-m peripherals are well covered by the cortex-m crate.

Yeah I was speaking to drivers on top, like I think we can share like Delay Time Trace type stuff. Which we will be doing with a single hal model.

[chrysn]

> I agree with your assessment of the efm32-unified approaches Excellent. Ill bring my efm32hg309f64-pac in here. Speaking of naming Im generating from the efm32hg309f64 svd but I with memory is handled outside the PAC that could probably be renamed and to efm32hg309 ? Thoughts on this? > It'll help a lot to think precisely about which chips a register crate can encompass I don't have prior knowledge here. My first and only SI labs chip is this efm32hg Thoughts on how that shares? Ill fork your hal and see what I see and do some research myself

Judging from the other EFM32, probably efm32hg. Just take the SVDs of some of the EFM32HGs and diff them -- only name and description should differ. I think that my EFR32xG[1] PAC is currently in nice shape, and I'd move it in here (as much as it pains me to migrate from gitlab to github – by the way, how attached are you to github?). Its build process is based on Make and not a Rust tool (and thus rather slim[2] compared to efm32hg309f64[3]; also, I personally dislike having generated files checked in so I banished them to a dedicated after-svd2rust branch). If you like that workflow, it could be amended by a make target that checks whether the diff between two or three .SVD files is sufficiently small, then that could be added easily. (But no rush in unification there, the pac crates should be low maintenance anyway). [1]: https://gitlab.com/chrysn/efr32xg1 [2]: https://gitlab.com/chrysn/efr32xg1/blob/master/Makefile [3]: https://github.com/jacobrosenthal/efm32hg309f64-pac/blob/master/tools/src/bin/gen.rs

> The cortex-m peripherals are well covered by the cortex-m crate. Yeah I was speaking to drivers on top, like I think we can share like Delay Time Trace type stuff. Which we will be doing with a single hal model.

That should eventually go into something like cortex-m-hal, but for some time we can keep it here.

[jacobrosenthal]

by the way, how attached are you to github?

I like it quite a bit and I find gitlab to be much worse ux and discoverability and thus collaboration to be much lessoned. That said I like the competition and Im sure a day is going to come \ where some international MS partner is going to want to start censoring code and MS wants to sell services there and Github is going to go to shit in a hurry. That said SVDs hopefully shouldnt need too much collaboration and if you dont want to move them seems fine.

Its build process is based on Make and not a Rust tool (and thus rather slim[2] compared to
efm32hg309f64[3];

Hah. Mine was a slim bash file originally too but I did that to myself on purpose :) I liked the idea of cross platform solution, and until we get better version control of binaries without running inside a container I wanted to lean on cargo.toml for version control. It was quite helpful during the 2018 edition switchover where I wanted to specify version bumps of tools easily, build locally and test.

also, I personally dislike having generated files checked in so I banished them to a dedicated after-svd2rust branch).

I understand that sentiment, Others were going for a build.rs solution that would actually build on demand which I think is too far for a file that changes so often. Ill have to take a look at your solution.

That should eventually go into something like cortex-m-hal, but for some
time we can keep it here.

Agreed, Im seeing lots of copy and paste across vendors, surprised this hasn't been done yet. But one thing at a time.

[jacobrosenthal]

Judging from the other EFM32, probably efm32hg. Just take the SVDs of
some of the EFM32HGs and diff them -- only name and description should
differ.

Yeah, scripted something up and sure enough, think theyre all the same. Going to call it efm32hg-pac I think? Though I dont see anyone using the -pac nomenclature on the repo it seems best to be specific? Thoughts on efm32hg-pac vs efm32hg?

[chrysn]

On Wed, Jan 30, 2019 at 09:58:49PM +0000, Jacob Rosenthal wrote: I find gitlab to be much worse ux and discoverability and thus collaboration to be much lessoned.

OK, I can work with both (just prefer the one I can fork/patch when needed).

I understand that sentiment, Others were going for a build.rs solution that would actually build on demand which I think is too far for a file that changes so often. Ill have to take a look at your solution.

Mhm, that *has* become feasible with the latest SiliconLabs license adjustments. Let's review that when [101] is resolved ;-) [101]: rust-embedded/wg#101

> That should eventually go into something like cortex-m-hal, but for some time we can keep it here. Agreed, Im seeing lots of copy and paste across vendors, surprised this hasn't been done yet. But one thing at a time.

Same goes for bit-banding, by the way.

Thoughts on efm32hg-pac vs efm32hg?

[1] has all crates only by their unsuffixed matching expression, so I'd go with no -pac. [1]: https://github.com/rust-embedded/awesome-embedded-rust/blob/master/README.md#device-crates

[jacobrosenthal]

I think its more that the pac nomenclature is more recent. There is also
https://github.com/nrf-rs/nrf52840-pac
https://github.com/nrf-rs/nrf52832-pac
https://github.com/lpc-rs/lpc-pac

[chrysn]

On Thu, Jan 31, 2019 at 12:14:29AM -0800, Jacob Rosenthal wrote: I think its more that the pac nomenclature is more recent.

OK, I did not notice that – you're right, it reflects the current documentation (at least after [134]). There's probably no hurry in the renaming, but let's go for -pac with new ones or ones that are renamed anyway. [134]: rust-embedded/awesome-embedded-rust#134

[ryankurte]

I did some work on this with the intent of teaching svd2rust to extract commonality across families, so we could generate common bindings and re-export them for each board.

That kindof stalled because stm32-rs seemed like a better way, but across the new (Draco / Series 2 iirc) EFM devices there were something like 40 unique peripherals, and I think it'd be reasonably easy to extend the tools we were playing with to extract the bits we need.

[jacobrosenthal]

@ryankurte I found https://github.com/rqou/efm32-unified-crate so pinging @rqou