Topics

Pinmux override

Joris Offouga
 

Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports, but it is not defined in pinmux.c and I must thzn modify this file to add the I2C configuration. Is there a better way to do this without modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga

Erwan Gouriou
 

Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan


On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



Allen Curtis
 

I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC

Erwan Gouriou
 

Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC

Vincent - VLoTech
 

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...

Vincent van der Locht

Op 11 jan. 2020 om 16:35 heeft Erwan Gouriou <erwan.gouriou@...> het volgende geschreven:


Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC

Marc Herbert
 

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@...> 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 https://lists.zephyrproject.org/g/devel/topic/61321118

Stefan Jaritz
 

Morning,

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[] = {
        {STM32_PIN_PC5, STM32F4_PINMUX_FUNC_PC5_USART3_RX},
        {STM32_PIN_PB10, STM32F4_PINMUX_FUNC_PB10_USART3_TX},
        {STM32_PIN_PB13, (STM32_PINMUX_ALT_FUNC_8 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
        {STM32_PIN_PB14, (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
    };

    const struct pin_config pin_off[] = {
        {STM32_PIN_PC5, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB10, STM32_MODER_ANALOG_MODE},
        {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));
    }
}

Stefan

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

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@...> 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 https://lists.zephyrproject.org/g/devel/topic/61321118