Adding FreeRTOS with TCP/IP stack to a Vivado project (ZC702 board)

I have created a Vivado 2019 project for the ZC702 board. The FPGA design has memory mapped IP that generate data. I need to send this data over Ethernet to a PC. I export from Vivado to SDK, and when I open SDK for the same “workspace”, my FPGA design is represented as “design1warpperhwplatform0. I created a simple Hello application and modified it to read from the IP memory map and print the content to validate the connection been the ARM processor and the IP runningin the fabric. The next step, which I have tried and failed at, it to somehow import FreeRTOS and the TCP/IP stack. Get some simple ‘echo’ process to work, and them modify the echo process to read from the IP’s memory mapped IP. I have downloaded and ran the FreeRTOSv10.2.1.exe. I have a folder “FreeRTOSv10.2.1″ . I when into SDK and selected the RTOSDemo subfloder for import. I end up with an RTOSDemo application, with ‘fatal erros FreeRTOS.h No such file or directory”. And ” make: [src/FullDemo/subdir.mk:39: src/FullDemo/IntQueueTimer.o] Error 1″ . The import also brought in an RTOSDemobsp and ZC702hwplatform, both w/o error. Although I will have to change the RTOSDemo application to use my “hw_platform” which has the memory map for my IP. So did I skip a step? import the wrong thing? PS. It’s very confusing to call the TCP/IP stack “FreeRTOS+TCP”, all new comer will think that in includes both the RTOS and the TCP/IP stack. How else could be it looked at? Renaming this would reduce confusion.

Adding FreeRTOS with TCP/IP stack to a Vivado project (ZC702 board)

Marc,
PS. It’s very confusing to call the TCP/IP stack “FreeRTOS+TCP”, all new comer will think that in includes both the RTOS and the TCP/IP stack. How else could be it looked at? Renaming this would reduce confusion.
I’m sorry about this misunderstanding. But today it is too late to change the names of products that have existed for so many years:
  • FreeRTOSPlusIO
  • FreeRTOSPlusUDP
  • FreeRTOS-Plus-IoT-SDK
  • FreeRTOS+Trace
  • FreeRTOS+POSIX
  • FreeRTOS+CLI
  • FreeRTOS+FAT
  • FreeRTOS+TCP
It all started with the FreeRTOS kernel, and later there were many additions which were named FreeRTOSPlusxxx. The “FreeRTOS+TCP” is just a shorter name. Some of these products can be found in the /Plus section. Other products were stored in a /Labs section, meaning that they were kind of experimental. Both +TCP and +FAT are adult and stable now. +TCP is also available from amazon/aws and FreeRTOS’s SVN. +FAT doe not have a new home yet. +TCP also contains the UDP protocol, so it can replace the FreeRTOSPlusUDP library.
FreeRTOS.h No such file or directory
You can Google this error message. Of course it has to do with the include path settings ( -I ) There is an application for Xilinx that demonstrates both +TCP and +FAT here. This demo project is a bit outdated though, and it might come with an older kernel. If you have problems to get that demo running, you can ask questions in this post. I attach the latest +TCP Network Interface for Xilinx as Zynq_02_july_2019.7z Unfortunately I have no experience with memory-mapped IP’s.

Adding FreeRTOS with TCP/IP stack to a Vivado project (ZC702 board)

That’s a lot of information, but I’m just trying to get FreeRTOS to work with TCP/IP with SDK. I tried to follow the instruction in the old demo, but using the latest FreeRTOS. I don’t see any instruction on setting the path setting to the include file. Could you provide step by step instruction on the bare mimimum to download on my PC (for the purpose of running FreeRTOS with TCP) , and once I’ve downloaded the files on to my PC, step by step instructions on what to import into my SDK session? And what compiles settings to configure if needed? I can followed the existing instructions on configuring IP address vs DHCP etc, that’s not an issue. The issue is much more lower level. The issue which files to get, which folder to import, and how to setup the include path. Right now I have in my workspace the folders/project “RTOSDemo”, “RTOSDemo_bsp” and the error shown in my previous message.

Adding FreeRTOS with TCP/IP stack to a Vivado project (ZC702 board)

I’ve restarted with a new SDK workspace. I imported “FreeRTOS/Demo/CORTEXA9Zynq_ZC702″ as instructed by “https://www.freertos.org/RTOS-Xilinx-Zynq.html#DemoApp” And ended up with this error in SDK. I’m surprised to see lwip mentionned, I thought FreeRTOS had moved away from using it. I downloaed the latest FreeRTOSv10.2.1! Description Resource Path Location Type make: *** [src/lwIPDemo/lwIPApps/apps/httpserverrawfromlwIPdownload/subdir.mk:23: src/lwIPDemo/lwIPApps/apps/httpserverrawfromlwIPdownload/httpd.o] Error 1 RTOSDemo C/C++ Problem

Adding FreeRTOS with TCP/IP stack to a Vivado project (ZC702 board)

This error “static declaration of ‘strnstr’ follows non-static declaration” is only in the lwipdemo, I will attempt to ignore it, since I don’t want to use lwip. But I also won’t delete the lwipdemo. I tried doing that in my first attempt, and that’s were I got the first error I reported.

Adding FreeRTOS with TCP/IP stack to a Vivado project (ZC702 board)

Xilinx still use lwIP though. The top level of the FreeRTOS download has a FreeRTOS directory and a FreeRTOS-Plus directory. The demo in the FreeRTOS directory uses Xilinx created projects that include lwiP. You can use the Xilinx tools to generate projects with or without lwiP and with or without FreeRTOS. The FreeRTOS-Plus directory contains projects created by the FreeRTOS team directly so the demos in the FreeRTOS-Plus directory use the FreeRTOS TCP/IP stack, so FreeRTOS themselves don’t create projects using lwIP any more but third parties do. The older labs project you refer to demonstrates all the files and build options that are needed, but also uses an older version of the Xilinx provided driver files and an older version of the FreeRTOS TCP stack. Updating the FreeRTOS TCP stack to the latest should be easy enough. Updating the Xilinx drivers can be harder but people on this forum will have newer Xilinx drivers (especially Hein who is a primary maintainer of the TCP stack).