Please find attached a new NetworkInterface.c for STM32F4. It has implemented the zero-copy feature in both directions, and therefore it is more efficient and faster than its earlier version.
I would like to invite anyone interested to try it out. Be aware that it may not be as stable yet as the existing driver. I tested it with UDP/TCP/ICMP/etc, and also with iperf.
The following settings are recommended for this driver:
/* Add to your 'FreeRTOSIPConfig.h'. */ #define ipconfigZERO_COPY_RX_DRIVER 1 #define ipconfigZERO_COPY_TX_DRIVER 1 #define ipconfigETHERNET_DRIVER_FILTERS_PACKETS 1 /* Add/change to your stm32f4xx_hal_conf.h : */ #include "FreeRTOS.h" #include "task.h" #include "FreeRTOSIPConfig.h" #define ETH_RX_BUF_SIZE ( ipconfigNETWORK_MTU + 36 )/* buffer size for receive */ #define ETH_TX_BUF_SIZE ( ipconfigNETWORK_MTU + 36 )/* buffer size for transmit */
ETH_TX_BUF_SIZE are defined as
ETH_MAX_PACKET_SIZE, which is hard-coded as
With a limited amount of RAM, it may be very profitable to reduce the value of
ipconfigNETWORK_MTU to e.g.
So let tha value of
ETH_TX_BUF_SIZE depend on
The new driver will also filter incoming packets. That can be important in networks with many UDP broadcasts. These packets should be filtered-out as soon as possible in order not to occupy resources.
The following CUBE/HAL functions won’t be called any more:
HAL_ETH_DMATxDescListInit() HAL_ETH_DMARxDescListInit() HAL_ETH_TransmitFrame() HAL_ETH_GetReceivedFrame()
For two reasons: they’re not compatible with zero-copy, and/or the in-line implementation is faster.
The interface will now work for two types of PHY’s: DP83848I ( found on STM324xG-EVAL ), and also LAN8720 ( found on STM32F4-DISCOVERY ).