Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build firm understanding of device generations #6

Open
chrysn opened this issue Feb 1, 2019 · 2 comments
Open

Build firm understanding of device generations #6

chrysn opened this issue Feb 1, 2019 · 2 comments

Comments

@chrysn
Copy link
Member

chrysn commented Feb 1, 2019

Some of this is already in efr32xg1-pac, some encoded in the features of efm32gg-hal.

OpenOCD has some knowledge of this, as illustrated in openocd-org/openocd@6d390e1.

We should become able to tell

  • which devices are exactly the same internally,
  • which devices differ in only scalar properties (eg. flash size that doesn't impact svd2rust creation)
  • how to determine whether a peripheral exists for a given device outside the PACs (currently: "_has_timer2"-style features)
  • whether changes in peripherals always happen at series boundaries, or whether there are per-peripheral releases we can identify
    This matters mainly for the macro/preprocessor part where we need to predict from outside of the PAC which registers are there, eg. whether in an ADC we access the "insel" or the "possel" register, or whether a GPIO has set/clear registers. Either those are gated by "if series < 1", or by "if gpio-version < 1" – currently it's a patchwork of variations in the HAL, with even some "if chip is efm32gg" which is terrible from a maintenance point of view, and worse yet prone to breaking for lack of a fallback-else.
@jacobrosenthal
Copy link

jacobrosenthal commented Feb 15, 2019

libopencm3 has been somewhat battle tested here and has a bunch of efm support
https://github.com/libopencm3/libopencm3/tree/master/include/libopencm3/efm32

They appear to have the:
ezr32wg
g
gg
hg
lg
tg
wg

the ezr32wg and efm32hg use different usb implementations

they rename a few registers on ezr32wg
#define CMU_HFPERCLKEN0_USARTRF0 CMU_HFPERCLKEN0_USART0
#define CMU_USARTRF0 CMU_USART0

hg has its own cmu implementation from the others

Otherwise theyre using a common implementation for those peripherals they support with no ifdefs or anything in them

@jacobrosenthal
Copy link

jacobrosenthal commented Feb 15, 2019

how about we dont get too ahead of ourselves here with your hal anyway, you're trying to use gg, im trying to use hg, lets just make something that supports both of them, or just series 0 until someone else comes along who wants to help make more forward progress

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants