MCC Generated Example Background

Last modified by Microchip on 2023/11/09 09:03

Explanation of the MCC-Generated Example

Inside of MPLAB® Code Configurator (MCC) generated files, there’s a folder called examples, which contains mqtt_example. That’s the file that contains the functions for our example, including

  • app_mqttExampleInit()
  • app_mqttScheduler().

It was created by ticking the Generate Example box in MCC’s MQTT window.  

In our example, MQTT initializes with app_mqttExampleInit(); and then runs with app_mqttScheduler();  Depending on the stage the development is on, if the broker or the Wi-Fi® is reset, you may need to restart the AVR-IoT WG. This can be done by disconnecting and connecting the device again and resetting its power supply.

In this project, you will need to find different functions inside different files. To make it faster, you can use Ctrl+f for searching inside of a file, and Ctrl+Shift+f for searching in the whole project.

Back to Top

app_mqttExampleInit()

This function initializes all functions required for app_mqttScheduler().

  • Initializes functions for WINC1510, Wi-Fi connection, and MQTT protocol.
  • Creates a connect packet, which will later be sent with app_mqttScheduler() to establish a connection with the broker. 
  • Initializes RTC, the timer that we set up in MCC. It creates a timer to set the frequency of publishing.

Back to Top

app_mqttScheduler()

This function does different things depending on the value of the appState variable.

  • If the value of appState is APP_STATE_INIT, the executed code will be the one inside of case APP_STATE_INIT:{ }. 
  • If the value of appState is APP_STATE_STA_CONNECTING, the executed code will be the one inside of case APP_STATE_STA_CONNECTING:{ }. And the same for every case.

When the program is running, app_mqttScheduler() will be continuously running.

The first time, appState will equal APP_STATE_INIT, so the code in case APP_STATE_INIT: { } will be executed. This code initializes part of what our program needs. This will happen several times until everything that needs to be initialized in APP_STATE_INIT has been initialized.

  • Then, it continues to the next state, APP_STATE_STA_CONNECTING, and constantly executes that state until APP_STATE_STA is connected.
  • Then, appState takes the value of the next state, APP_STATE_STA_CONNECTED. Every state initializes something and then goes to the next state until it gets to the APP_STATE_TLS_CONNECTED state.

When the device is in the APP_STATE_TLS_CONNECTED case, it stays there forever or until an error happens. If an error happens, the new state will be APP_STATE_ERROR, then APP_STATE_STOPPED, and finally APP_STATE_INIT again, to start the whole process again. But in this scenario, the device will not be able to reset the MQTT connection properly. To start the process correctly, the only option is to reset the device.

In the APP_STATE_TLS_CONNECTED case, the MQTT_ReceptionHandler() and MQTT_TransmissionHandler() functions are executed. Those functions are based on states too.

  • What MQTT_TransmissionHandler() does will depend on any previously created packet. If the device didn’t create any package, then this function will not do anything. If there is a previously created package, the function will send it, and delete the packet, so the same message is not sent again.
  • What MQTT_ReceptionHandler() does will depend on any received packet. If the device did not get any packet from the outside, that function will do nothing.

In this example, when MQTT_TransmissionHandler(mqttConnnectionInfo) happens, the publish packet has been created 5 lines above, though app_buildPublishPacket().app_buildPublishPacket() will only occur if (appMQTTPublishTimeoutOccured == true), this is when the timer created in app_mqttExampleInit() is finished.

Important: If packets are received but not correctly processed, the program will collapse and will not send or receive more data through MQTT.

Back to Top