Exploring the Code Behind IoT Development Boards

Watch the featured videos and or skip to your favorite part of the video below!

Mentioned Videos:

First, the software initializes the libraries from MCC. We answer the question, “How does the scheduler used on the IoT boards compare with an RTOS?” ( 9:05). The scheduler runs on a 16-bit timer and works on a simple link list system to run all the function call backs. Next, the software initializes the Command Line Interface (CLI) (11:55). This uses a simple Universal Asynchronous Receiver/Transmitter (UART) communication built on the foundation services libraries. Next, we review how the scheduler is operating (12:47). Chris breaks down an example scheduler function working in the program that creates the reference to the CLI task. First the callback is called, then the periodic task is built and last the task is rescheduled if it will be called again in the future.
The security section of the program (15:35) covers the code interfacing with the ATECC608 security chip on the board. This works with the Crytpo Authentication Library. The software pulls the Unique User ID from the security device and stores it for use with the broker once the system starts talking to the cloud. This triggers a great question from a user asking, “How can I reduce the amount of power consumption on the AVR-IoT Board?” (16:43).

In the last section of the IoT software, we discuss how the WINC1510 communicates with the embedded microcontroller and the cloud (21:30). If you want to enter soft AP mode, make sure to only hold switch 1 down when the board is powering up. We also discuss how the embedded microcontroller, Microchip and Google handle your credentials that you give to the device when connecting to the Google sandbox and to the Atmel website in Soft AP mode (22:50). Learn how to initialize the WiFi ® connection (24:45) and then Chris discusses the WiFi response call back, which checks to see if the access point between the WINC1510 and the internet server has been interrupted. The wifiHandler callback is handled by the embedded microcontroller but is required to be called once every 50 milliseconds by the WINC1510 to check if any new information has been received. This led to another good user question: “Is there a way to update the WINC1510 firmware using the MCU or do I need to update it via the serial port?” (25:55). We also discuss how often it is necessary to pull the UUID from the ATECC608 security device (28:20).

Chris wraps up the end application and how the IoT software all works together and then answers one more question: “Can I use the AVR-IoT and PIC-IoT boards with another web page besides the one hosted on Google?” (35:00).

In the last part of the livestream, Madhura gives an overview of the application physically working on the AVR-IoT and PIC-IoT Development Boards. First, the board initializes, which is represented by all LEDs blinking twice. Next, the development board connects to the WiFi network. Then, it opens a TCP socket and establishes an MQTT connection with Google. Finally, it will begin exchanging data. Madhura shows the code in the Cloud Task handler that both opens the TCP socket and establishes the MQTT connection. We finish answering some great questions including “Can we create raw TCP/IP sockets?” (42:15) (52:00), “Why use MQTT with a microcontroller?” (43:00), “If we want a secure connection with HTTPS, is SLS or TLS supported in this example?” (50:00) and “Is TLS available in MCC?” (53:28).

[settorezero]

I'd like to use the PIC-IOT board for sending data, via MQTT, to a local server. I've an MQTT Broker (mosquitto) and NodeRed running on a Raspberry Pi in my house and I'm not able to let the PIC-IOT board send data to the local MQTT broker.

[whiteking]

only to google cloud? how bout firebase database?