FreeRTOS_GetEMACTaskHandle function added

[kzorer]

Add FreeRTOS_GetEMACTaskHandle Function for STM32H7xx Devices

Description

Added the FreeRTOS_GetEMACTaskHandle function for STM32H7xx devices. This function provides access to the EMACTaskHandle for managing the Ethernet MAC task within the FreeRTOS environment.

Test Steps

• Build the project with the new function integrated.
• Deploy the firmware to an STM32H7xx development board.
• Verify that the FreeRTOS_GetEMACTaskHandle function is correctly returning the EMACTaskHandle.
• Run any existing test cases that involve Ethernet MAC operations to ensure they work as expected.
• Validate that no regressions or issues have been introduced in other parts of the system.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

N/A

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[htibosch]

Hello @keremzorer, thank you for your interest in FreeRTOS+TCP.

You are trying to add two new features:

1. A macro ipconfigEMAC_TASK_HOOK(), which will be called during every loop in the function prvEMACHandlerTask().

2. With the new function FreeRTOS_GetEMACTaskHandle(), you want to give read-only access to the variable that stores the task handle: xEMACTaskHandle.

I'd like to mention a few things:

• When you introduce a new global function, it needs a prototype in one of the header files.
• When you add a macro, we normally give it a safe default value in FreeRTOSIPConfigDefaults.h.

Every macro must be defined. The code will never use #ifdef, only #if(MACRO).

Mind you that a user can include multiple network interfaces. However, your function and macro seem to expect a single interface.

If it is really important, we could add two new properties ( member functions ) to the type NetworkInterface_t. By default the function pointers will be set to NULL, which means: not implemented.

[tony-josi-aws]

@keremzorer

Wondering whats the use case of exposing the EMAC task handle?
Thanks.

[kzorer]

Hello @keremzorer, thank you for your interest in FreeRTOS+TCP.

You are trying to add two new features:

1. A macro ipconfigEMAC_TASK_HOOK(), which will be called during every loop in the function prvEMACHandlerTask().
2. With the new function FreeRTOS_GetEMACTaskHandle(), you want to give read-only access to the variable that stores the task handle: xEMACTaskHandle.

I'd like to mention a few things:

• When you introduce a new global function, it needs a prototype in one of the header files.
• When you add a macro, we normally give it a safe default value in FreeRTOSIPConfigDefaults.h.

Every macro must be defined. The code will never use #ifdef, only #if(MACRO).

Mind you that a user can include multiple network interfaces. However, your function and macro seem to expect a single interface.

If it is really important, we could add two new properties ( member functions ) to the type NetworkInterface_t. By default the function pointers will be set to NULL, which means: not implemented.

As you mentioned, ipconfigEMAC_TASK_HOOK functionality already merged last week. I would like to add FreeRTOS_GetEMACTaskHandle function that gives the task handle for application layer, so as you said, it needs a prototype in NetworkInterface.h file. I can fix it. By getting task handle, I can easily trace wheter EMAC-Task works properly or not. Therefore, I would like to add for STM32H7xx devices. That's why I added and created pull request.

[tony-josi-aws]

As @htibosch suggested here, you can get the task handle for the EMAC task by doing this:

TaskHandle_t xHandle = xTaskGetHandle( niEMAC_HANDLER_TASK_NAME );

Hence, the PR seems unnecessary, so I am closing this for now. Please feel free to reopen if you feel otherwise.