Mbed-os: `void HAL_ETH_MspInit(ETH_HandleTypeDef* heth)` needs `__weak`

[Arjun765]

Description

• Type: Enhancement
• Priority: Major

Without weak if i need to use different pins than the one used in the nucleo board, i would need to modify the mbed init file (mbed-os/features/FEATURE_LWIP/lwip-interface/lwip-eth/arch/TARGET_STM/TARGET_STM32F4/TARGET_NUCLEO_F429ZI/stm32f4_eth_init.c)

Target
STM32F4

[jeromecoutant]

Hi @guest253456

I agree, we need to propose a solution.

[pauluap]

That function IS defined as weak in the device implementation

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_eth.c#L611

The stm32f4_eth_init.c is a target specific file (as can be seen from the path) - and if you have something with different pins, it is a different target, and thus needs a target-specific HAL_ETH_MspInit, and thus I think that it makes sense that reimplementation is required and the build modified to pick up the correct target implementation.

[0xc0170]

@guest253456 Does it answer your question?

[Arjun765]

thus I think that it makes sense that reimplementation is required and the build modified to pick up the correct target implementation.

That would mean i would need to create a new target which is same as nucleo apart from the ethernet pins and i would need to maintain this target. Ideally i should be able to change the pins by passing it to the EthernetInterface class.

[ohagendorf]

And it is possible to use an original NUCLEO board, change some solder jumper and add a shield with a different PHY chip. We did this with a LAN9303 to have switch functionality ontop of the NUCLEO.

So, it is not a different target but a possible configuration of several existing targets.

We solved it with excluding the device specific eth init c file with the help of .mbedignore and adding a changed copy of it to the project root. It works but it is not very smart.

[pauluap]

Yeah, I agree that creating a new target isn't a snap operation. What I eventually ended up doing was to start with the cmake export and built up my own target.

@ohagendorf - that's cool - did you have two MACs running in that application?

But yeah, I agree that it's nice to be able to swap in target specifics as a constructor configuration. There's a branch that I'm looking forward to when it's released - the feature-emac branch that wraps a lot of the emac stuff into a class that can be inherited, reimplemented, whatever - https://github.com/ARMmbed/mbed-os/tree/feature-emac/features/netsocket/emac-drivers.

However, even then, the target-specific HAL_ETH_MspInit is still present because that's what the HAL implementation uses to perform target-specific initialization. The HAL implementation is provided by ST - you can find the same code in the STM32Cube packages.

Thinking about it a bit, I guess that it may be possible to get the feature-emac implementation to pull in a function object - the STM driver does know that HAL_ETH_MspInit will be called when it calls HAL_ETH_Init but that turns in a can of worms, build system changes are easier, I think... if the user has a build system that they are comfortable with.

In the short term ohagendorf's solution works. In the long term, I think that it's a fair argument that if a target isn't correct, then it's a new target.

It'd be an interesting exercise to teach the mbed build system how to handle target deviations in a supported manner other than using `.mbedignore', I just chose to switch to CMake and handle my deviations directly.

The heart of the issue here, I believe, is not the necessity of implementing HAL_ETH_MspInit - it's getting the build system to do what you want.

EDIT: upon review, I realize that my last sentence is exactly what @guest253456 said in the first place, they have an implementation in hand that they want to compile in place of the target provided one. Ah, so well, around in a circle I go. I think that my point remains, the __weak annotation is correctly placed on the driver implementation, and the default target implementations are done in the correct-according-to-my-not-very-impartial-point-of-view way. It is a struggle to start deviating from targets. Figuring out the json-based build system was a hill I decided not to tackle, turning to the easier path (for me at least) of transforming to a cmake build system.

[ohagendorf]

@pauluap - we disconnected the NUCLEO onboard PHY and connected the LAN9303 on a shield - that is developed by us. The LAN9303 looks like a PHY from the STMF7 controller side (nearly no software changes necessary) but has two additional MACs/PHYs/RJ45 sockets for external connections. From the outside view it looks like a 3port switch with two available RJ45 ports and the third is connected to the STM32.

We ported a BACNet stack to mbed (will be available soon) and the device can be used in a daisy chain configuration.

[jeromecoutant]

Hi

please check #6952

Regards,

[jeromecoutant]

Hi @guest253456

Are you OK to close this issue now that #6952 is merged ?

https://os.mbed.com/teams/ST/wiki/How-to-use-own-ETHERNET-PHY

Regards,

[Arjun765]

Yes