Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Porting TCP/IP web page misleading

Posted by joehinkle on June 21, 2016

I'm writing a NIC driver for the Kinetis K64 to be used in your stack.

I'm being picky here as I'm finding misleading/confusing information.

On the web page: http://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusTCP/EmbeddedEthernetPorting.html#creatingazerocopynetworkportlayer

in the section: Functions Provided by the TCP/IP Stack For Use By The Port Layer

the following is stated:

pucGetNetworkBuffer() - Obtains just a network buffer, without a network buffer descriptor. This function is normally only used in zero copy interfaces to allocate buffers to DMA descriptors.

I don't believe that is a true statement as the function pucGetNetworkBuffer() is defined in BufferAllocation2.c not "1.c" which is associated with zero copy AND the function call malloc to allocate a buffer ... which again is not zero-copy related.

I suggest rewording the paragraph and state:

Obtains just a network buffer, without a network buffer descriptor. This function is NOT used in zero copy interfaces to allocate buffers to DMA descriptors.


Porting TCP/IP web page misleading

Posted by rtel on June 21, 2016

I think the BufferAllocation1.c and BufferAllocation2.c have just evolved at different times. Why can BufferAllocation_2.c not be used in a zero copy driver? Perhaps it would be better to ensure both allocation schemes provide the same interface to the stack and the same functionality as each other - in which case we probably need to add some code in.


Porting TCP/IP web page misleading

Posted by joehinkle on June 21, 2016

I've gone over the port page multiple times.

I suspect zero-copy/BufferAllocation1.c came after BufferAllocation2.c.

Calls by the same function take different type arguments and your implementation example has several bugs which I suspect is do to zero-copy maturing over time but the implementation example forgotten.

I propose a much cleaner zero-copy transmit process than what your describe (switching ethernet buffers pointers, etc -- as the ethernet buffer is directly tied to its network buffer with the network buffer address embeded at the start of the ethernet buffer.

The example says to return the buffer with the buffer's pointer to the ethernet buffer being nulled out and then returning the ethernet buffer after the transmit is completed. I've looked at the stack functions that are suggested to be called and none of them do any conditional work if the ethernet buffer is null or not.

I suggest NOT performing any action on the buffer until after the transmit is completed. In the interupt, obtain the DMA address and acquie the pointer to the Network buffer position at the front of the ethernet buffer. Then just return buffer and descriptor in ISR ... no swapping and all the other mess explained in your example goes away.

Just my opinion.


Porting TCP/IP web page misleading

Posted by rtel on June 22, 2016

Hi Joe - thanks for your feedback. I think the differences between the the _1.c and _2.c implementations comes mainly from the fact that focus goes from one to the other over time, so they are not necessarily in step with each other. Your posts have raised some good points so I will try and clean this up, and update the documentation accordingly.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS