ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.66k stars 2.97k forks source link

Configurable ethernet pinout #7037

Closed omdathetkan closed 6 years ago

omdathetkan commented 6 years ago

Description

I am using a custom board, roughly based on the NUCLEO_F767ZI. Most of the pinout is the same, but for example for RMII_MII_TXD1 I am using PG14 instead of PB13 since this made much more sense from a layout perspective.

I am currently working around this using:

// "Overrides" mbed-os\features\FEATURE_LWIP\lwip-interface\lwip-eth\arch\TARGET_STM\TARGET_STM32F7\TARGET_NUCLEO_F767ZI\stm32f7_eth_init.c
void eternet_override_pre(void)
{
    GPIO_InitTypeDef GPIO_InitStructure;

    /* Enable GPIOs clocks */
    __HAL_RCC_GPIOG_CLK_ENABLE();

    /* Configure PG14 (Instead of PB13) */
    GPIO_InitStructure.Speed = GPIO_SPEED_HIGH;
    GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStructure.Pull = GPIO_NOPULL;
    GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
    GPIO_InitStructure.Pin = GPIO_PIN_14;
    HAL_GPIO_Init(GPIOG, &GPIO_InitStructure);
}

void ethernet_override_post(void)
{
    HAL_GPIO_DeInit(GPIOB, GPIO_PIN_13);
}

Which I use to wrap the connect function:

eternet_override_pre();
status = eth.connect();
ethernet_override_post();

This works for me but is not very clean, especially if the original pin is used by something else. Would it make sense to make this configurable somehow? Or would trivial things like this require me to make a completely new target (undesirable form maintenance perspective)?

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug

jeromecoutant commented 6 years ago

Hi

You can check https://os.mbed.com/teams/ST/wiki/How-to-use-own-ETHERNET-PHY and use USE_USER_DEFINED_HAL_ETH_MSPINIT macro

Regards, Jerome

omdathetkan commented 6 years ago

Ah perfect! I will give this a try. Thanks.

ciarmcom commented 6 years ago

ARM Internal Ref: MBOTRIAGE-12

jeromecoutant commented 6 years ago

Hi

could we close the issue ?

ST_TO_BE_CLOSED

Thx

omdathetkan commented 6 years ago

@jeromecoutant this solves the issue so this can be closed, but wouldn't a __WEAK definition of these functions be a cleaner implementation?

jeromecoutant commented 6 years ago

Hi These functions are already WEAK in ST Cube driver files ... (targets/TARGET_STM/TARGET_STM32F7/device/stm32f7xx_hal_eth.c)

omdathetkan commented 6 years ago

I see, makes sense.