Greetings! Do you want to form an efm-rs org?

[jacobrosenthal]

@fudanchii and I are working on an efm32hg hal (well.. its more of a tomu bsp at the moment, we need to pull out the hal bit) here https://github.com/fudanchii/imtomu-rs as well as https://github.com/jacobrosenthal/efm32hg309f64-pac

I havent seen any other silabs authors active until I stumbled upon you. Are you interested in joining forces and trying to share code in an organization?

It would probably look like https://github.com/nrf-rs/ or https://github.com/stm32-rs Maybe it would bring the others out of the wood work as well.

[chrysn]

Good to hear that, and yes, would be happy to pool implementations!

I've had a glimpse at what you've done in imtomu; there are things that are very similar (eg. GPIOs), but some things where I disagree (eg. I think it's dangerous to let a mutable CMU live while something depends on one of its clocks being configured a particular way).

If we find to a shared understanding of what is safe to do in terms of type state, I'd be happy to move this into a shared project. Are there, to get this started, particular reasons for the choice of having a short-term &mut CMU suffice to set up GPIO? Would you take the same approach with I2C or SPI where not only the clock being enabled but even its timing is relevant?

(A pooled implementation would solve the problem of having committed to the efm32gg-hal crate name before considering everything ;-) )

[jacobrosenthal]

I agree entirely. Its my goal to encapsulate all the peripherals properly. I havent gotten to refactoring the original gpio work yet.

I invited you to efm32-rs organization

[chrysn]

I'd use that opportunity to get the name right.

Suggestion: Let's call it em32-rs (and be sure to tag it with EFM32, ERZ32 etc wherever possible). This would follow the vendor's own naming scheme, they're calling their own library C for the same chip families "emlib" and "emdrv".

On Wed, Jan 30, 2019 at 04:55:48PM +0000, Jacob Rosenthal wrote:

I invited you to efm32-rs organization

Didn't see an invite yet, did github confirm the invitation?

[jacobrosenthal]

Yep. In fact you probably have several emails somewhere now :) Youre an owner feel free to take ownership and tag whatever, etc. I made a wg repo there to start conversation on shared goals and start planning

[jacobrosenthal]

Oh I see you had said em32-rs you meant that instead of efm?

On Wed, Jan 30, 2019, 10:01 AM chrysn <notifications@github.com wrote:

I'd use that opportunity to get the name right.

Suggestion: Let's call it em32-rs (and be sure to tag it with EFM32, ERZ32 etc wherever possible). This would follow the vendor's own naming scheme, they're calling their own library C for the same chip families "emlib" and "emdrv".

On Wed, Jan 30, 2019 at 04:55:48PM +0000, Jacob Rosenthal wrote:

I invited you to efm32-rs organization

Didn't see an invite yet, did github confirm the invitation?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/chrysn/efm32gg-hal/issues/2#issuecomment-459023437, or mute the thread https://github.com/notifications/unsubscribe-auth/AAb0dHQZAHONSGk5gKefYyax6ZoBAw6wks5vIc_fgaJpZM4aZLrp .

[jacobrosenthal]

Just one more check in, did you think the org should be named something other than efm32-rs?

[chrysn]

On Wed, Jan 30, 2019 at 09:26:52PM -0800, Jacob Rosenthal wrote:

Just one more check in, did you think the org should be named something other than efm32-rs?

I'd lean towards em32-rs on the basis that emlib is the only unifying terminology I've seen from Silicon Labs.

(Not even their multiple-family AN documents like 1 manage to use one term – "supports multiple device families" … "MCU Series 0 consists of" etc).

[jacobrosenthal]

Youve convinced me. I hadnt even seen ezr efr etc. I changed it