You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
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.
The text was updated successfully, but these errors were encountered: