K64 port of FreeRTOS+TCP?

[eengineer]

I'm sure I'm not the only one who would like to see an "official" NXP port of FreeRTOS+TCP to the K64F board. I've had fair luck with FreeRTOS and the old LWIP stack, but it is very poorly documented and I do not feel particularly confident relying on it.

I would think one of your networking experts could do this port in the day, and save dozens of individuals many, many hours of duplicate effort...

[JHinkle]

I have used both LWIP and FreeRTOS+TCP and my opinion is the FreeRTOS+TCP is much better.

If you are looking for a SDK type solution, you may want to ask Amazon IOT since they now own FreeRTOS and FreeRTOS+TCP.  They now have a team of engineers working on the product (google "FreeRTOS Amazon").

There are many set-up decisions that must be made to implement the stack.  The main functions (that I consider the "Driver") are initialization, enet_receive, and enet_transmit.  The implementation depends on what memory management scheme you select and how you setup your enet buffers.

I've had my implementation several production applications for two years now.  I will share those functions with you but the full implementation will still require reading and understanding all the documentation on the enet in the K64 to get a working stack.

If you implement your stack using a driver similar to mine you can do things like detect specific UDP communication inside the enet_receive and bypass the stack all together - doing a zero-copy packet pass directly to the application layer.

Hope that helps.

Joe

[jaylarson]

Hello E Engineer,

I am also very concerned about relying on the MCUXpresso SDK solution.  I find the fsl_enet driver and lwip ethernetif port bloated and filled with code not needed.  It seems that it was written to cover all possible use cases, when the user is only interested in a single case.  Code like this hides potential problems and certainly doesn't help the users' understanding.  

My review of the existing lwip port / driver has left me with serious doubts beyond the basic readability of the code:

• It tries to handle way too much of the reception of frames in the interrupt (starving other ISRs from attention)
• possibly uses a temporary buffer on the stack with a length of an entire maximum frame.  Not good, especially in an interrupt context.
• Excessively copies received and transmitted data.  The hardware works with DMA, why not use it?!

The LWIP stack seems otherwise OK for me to use.  I think it is solid, and well tested.  But I agree that it is poorly documented.  

So, like you I've looked to see if the FreeRTOS+TCP  might be a better solution going forward.  But I've not found a suitable driver either.  FreeRTOS+TCP looks like it is well documented, but 

Please let me know if you do find a good driver.  I expect that they have been written but are proprietary.  Given the lack of any alternative, I've begun to write my own zero copy driver that doesn't depend on any MCUXpresso code.  The process of writing it myself will give me the best understanding of how to use it for either stack FreeRTOS+TCP or  lwip.  

Good Luck with what ever solution you use. 

Cheers,

Jay

[mjbcswitzerland]

Jay

Don't miss out on the fact that the uTasker project includes an integrated TCP/IP stack which was designed for small flash and RAM footprint (initially used on NE64s in 2004) but works on all Kinetis parts, including all the usual stuff like WEB, FTP, HTTP Telnet servers, IGMP, SNTP, etc. with also MQTT and secure MQTT (based on mbedTLS layer).

It works immediately with FreeRTOS and the TCP/IP stack can also be used via USB (RNDIS). The servers interact inherently with the file system allowing FTP or HTTP content to be stored on SD card or memory stick, or can fall back on a highly efficient file system in internal flash.

IPv4 and IPv6; plus its Ethernet driver allows multi-homed networking (multiple IP and MAC addresses) on multiple interfaces.

The complete operation can be simulated in Visual Studio (testing all of the Ethernet controller's operation, interrupts driver, stack and application in approx. real-time) where the PC looks like a chip on the network to other users.

Most of the operation is included in its open source version on GitHub so it is not restricted to supported professionals either.

Regards

Mark

P.S. Note also that a Freescale employee also made the FNET project that is used by some people which is another TCP/IP alternative if you don't like main-stream.

[danielchen]

Hi

The lwIP TCP/IP stack is pre-integrated with MCUXpresso SDK and runs on top of the MCUXpresso SDK Ethernet driver with Ethernet-capable devices/boards.

The current lwIP verison in SDK2.4.2 is 2.0.3.

You can get the latest SDK from below link

Welcome | MCUXpresso SDK Builder 

Regards

Daniel

[shrinivasnh]

Do you have any example which used FreeRTOS+TCP with USB RNDIS instead of ethernet port

I was not able to find any example which does this and what i instead have is lwip+freertos+usb rndis