I downloaded 160919FreeRTOSLabs.zip and opened the Windows build example in FreeRTOSPlusTCPandFATWindowsSimulator. The code compiles “as is”, however, I get a compile error if I set: #define ipconfigUSEDNS 0 I can remove the compile error by including FreeRTOSDNS.h in FreeRTOSUDPIP.c. I also get the following link errors (with DNS set to 0), which I have not investigated: 1>FreeRTOSARP.obj : error LNK2001: unresolved external symbol _xLLMNRMacAdress 1>FreeRTOSIP.obj : error LNK2001: unresolved external symbol _xLLMNRMacAdress 1>FreeRTOSUDPIP.obj : error LNK2019: unresolved external symbol ulNBNSHandlePacket referenced in function _xProcessReceivedUDPPacket 1>FreeRTOSUDPIP.obj : error LNK2019: unresolved external symbol _ulDNSHandlePacket referenced in function _xProcessReceivedUDPPacket 1>CLI-commands.obj : error LNK2019: unresolved external symbol _FreeRTOSgethostbyname referenced in function _prvPingCommand

Hi Willhelm, if you want to use ipconfigUSE_LLMNR and/or ipconfigUSE_NBNS, it is necessary to also define ipconfigUSE_DNS. It would be helpful if the compiler checks for this dependency and issues a compiler warning. The ’16’ in 160919FreeRTOSLabs stands for 2016, that is a bit old. You can download the latest sources from github/aws or from freertos.org, or from sourceforge/svn. In case you want to use +FAT, you can download it separately from freertos/labs in this file. In the 160919 release you will find some demo applications that use both +FAT as well as the protocols HTTP and FTP. I do have some updates of these protocols, which have never appeared in a public release

Thanks for the response Hein. I have the latest from GitHub, but this release does not include the file system. It’s a little weird that freertos.org promotes an old release with a ready to use TCP and File System example, but the latest on GitHub does not include the file system. In any event, maybe the old release on freertos.org should be removed?

A couple of years ago, as you probably know, Amazon/AWS bought FreeRTOS and it products. At that moment, +TCP was just about ready to leave the Labs section, and become part of the official kernel release. The Amazon/AWS team did a great job: they concentrated on security: +TCP got more secure, and also they added secure layers on top of it. It is becoming a complete eco system for IoT applications. In a meanwhile, FreeRTOS+FAT has become an orphan: it has not been adopted in the official repository yet, and so it is still sitting alone in FreeRTOS.org/fat. I will attach my current version of +FAT, but you will only see small changes compared to the MIT release If you have any more questions about +FAT, you can ask them here.

Thank you very much Hein. BTW, I have a suggestion for you. I noticed that ffstat fails on the mount point (root address). For example, when using the ram disk, ffstat fails for “/ram”. For consistency, I suggest making it possible to do ff_stat on the root mount. I am working on porting a posix app that fails when attempting to iterate and discover disk info.

Yes you’re right, these mounting points like /ram should be stat-able