[En-Nut-Discussion] Large batch of patches with some .conf file changes. How to proceed?

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Wed Jul 15 12:06:23 CEST 2015


Hello,

my local tree contains a branch with a lot of changes. These changes
include some needed change in the .conf files

- Change of STM32 chip naming in the .conf files

Now to specific a CPU for some configuration, only two items are needed:
CM3_GCC = ""
MCU_STM32F407xG = ""
>From 'CM3_GCC', the configurator knows what CPUs to offer and from
'MCU_STM32F407xG' the configurator can decipher all CPU details, including the
linker file. Not all STM32 types are offered yet, but at least all STM32
CPUs with Nucleo or Discovery boards should be available.

- Changes in pin naming in the .conf files

Device pin mapping is done now like 'USART2_TX = "PD5"'. The configurator
tries to offer the available pins, for some pins on a device specific base
and uses some hopefully sensible default. For device pins available on F1,
the default is the none-remapped pin, otherwise the default pin is some pin
available also in small packages. The pins offered may include pins not
available in smaller packages.
This is still complicated, but much less headache than the old way by
providing items like 'USART2_TX_PIN  = "5"' where later the used port needs
to be retrieved with much effort.
Timer pins still use the old way.
Some header later tries to decipher the needed pinmux setting.
This pin naming scheme can also be usefull for other device families.

- EMAC now defaults to RMII

This was described in an earlier mail, with no feedback yet.

<!!!>
How to proceed with such a change, possible requiring Users to change their
configuration? I have very few user feedback on STM32, so I don' know what
is used out there.
</!!!>

Other changes are:
- Switch to STM32Cube vendor headers all over. All header now with BSD license!
- L0/L1/F0/F1/F2/F3/F4/F7 are implemented.
- For F0, remap SRAM at address 0 to mimic VTOR in a way similar to
  VTOR handling for other chips implementing VTOR.
- Provide separted IRQ handlers for combined DMA/USART IRQs like on
  STM32F091 "USART3_8_IRQn".
- For the EMAC, use the Unique ID when generating the local
  MAC. F7_discovery EMAC works in principle, but there is some hickup with
  confnet yet.

Cheers
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


More information about the En-Nut-Discussion mailing list