Aws vs iot headers and dot_c in tcp

I’m setting up a board to use FreeRTOS on MPLAB X IDE. It is the Digilent’s WiFIRE that uses the MRF24WN wireless card. Harmony in the IDE was failing, so I went through and set everything up manually. The FreeRTOS now uses its’ own TCPIP and can’t use the Microchip Libraries (that is what is says in Harmony).

I got everything setup in the BSP, APP, system.config.h…etc. Made sure the MRF24WN driver was installed. Got the FreeRTOS setup. Piece by piece. I had to go into the compiler settings to point it to the folders and files, manually, after getting the files in place. It was a pain, but it was moving forward successfully.

Then I added the FreeRTOS-Plus-TCP. I was very thorough about following the instructions and went through step by step. It was going good. The instructions by FreeRTOS were great. Thank you.

BUT at some point, suddenly, I had to start pulling in files like iot_wifi.h which then wants various aws_x.h files…okay?

The AWS stuff killed my setup. It broke my links in the compiler to my MRF24WN drivers. It should not have done that. BUT it did.

I don’t want to use AWS.
As recommended, I signed for an account to use the Amazon FreeRTOS stuff…but I could not get actual FreeRTOS information, just hype to purchase AWS services and other hardware.
I don’t want to use AWS.

Amazon has literally taken FreeRTOS files and changed only the name on some of them. In other files, specifically ones built for PIC32 MRF24WN, swapped out the proper driver references for wireless cards they want to support instead of building their own. AWS won’t support the MRF24WN, which is fine, but they appear to have destroyed the support files that others built and use.

This has dismantled being able to use FreeRTOS Plus TCP in an open source method.

How do I get outside of Amazon? Outside of AWS? And still use FreeRTOS Plus TCP?

What are the differences (aside from the aforementioned) between using aws or iot files in the TCP realm?

Or do I need to switch to another RTOS?

I think you are going to have to give us a little more details on what you are trying and where you got stuck here. When I use FreeRTOS+TCP I usually start with this demo

That has no references to AWS at all and just does TCP.

I am not sure at which point you ended up including the iot_wifi code, but that code only implements the wifi control plane (connect, disconnect, scanning for SSID’s etc) and it is an abstraction that you should not even need for your application. Wherever you are including iot_wifi I think is where you are going wrong.

I dug a little deeper on this and it looks like you are trying to use the port for the WINC1500 which is in NetworkInterface/pic32mzef/NetworkInterface_wifi.c ?

It seems like that in their implementation Microchip decided to use the iot_wifi control plane in 2 places, to turn on the module and to connect to the access point in the initialize function. I think you really should implement the initialization code for the MRF24WN in the init function instead. If you want to follow the same pattern as the WINC1500 you could implement your own WIFI_on() and your own WIFI_ConnectAP functions, call it what you like, remove the include to “iot_wifi.h” and all your problems should go away. There should be lots of example code out there showing how to turn the MRF24WN on and how to connect it to an access point.

It also receives data via the interface xNetworkFrameReceived which is specific to the WINC1500 driver, is not part of FreeRTOS+TCP and which will be your next problem. One option is to look at the NetworkInterface_eth.c file to see how to implement the receive channel using xSendEventStructToIPTask directly.

Actually I think you would have an easier time if you started with the other interface called NetworkInterface_eth.c which does not depend on any of the iot code as an example of how this should be done.

You should also specifically look at this documentation https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/Embedded_Ethernet_Porting.html

It specifies exactly which functions form the network interface port layer you need to implement and how they interact to form the abstraction for the MAC driver.

@cobusve Thank you.

I will go through again and try your suggestions. I greatly appreciate the insight.