Re: Pinmux override

Stefan Jaritz


As Erwan was telling, IMHO the pinmux variant is a good solution. For example if you doing power saving, you might power down parts of you pcb. Just image the case that you have a peripheral communicating via USART. If it is powered down down you should also configure your stm UART pins, to prevent that you stm is powering the IC via the RX, TX lanes. So you need to do this pinmux stuff not only at boot time.

If you image the board startup as just one use case of pin config, because your firmware will have different ones (like production, self test, operational, error state) you can imagine that the generating a static config via dts is not working in most of the cases. For my stm32f4 platform you can perfectly handle pinconfig with the stm32 pinmux port.

for example:

static void uart3_dma_gpio(bool on) {
   const struct pin_config pin_on[] = {

    const struct pin_config pin_off[] = {
        {STM32_PIN_PB13, (STM32_MODER_ANALOG_MODE)},
        {STM32_PIN_PB14, (STM32_MODER_ANALOG_MODE)},
    if (true == on) {
        stm32_setup_pins(pin_on, ARRAY_SIZE(pin_on));
    } else {
        stm32_setup_pins(pin_off, ARRAY_SIZE(pin_off));


On 11/01/2020 22:17, Marc Herbert wrote:

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like

Join to automatically receive all group messages.