Summary

The final exercise is to deploy the final level application in your Azure Sphere to your own IoT Central application. Majority of the project code has already been completed in previous exercises.

1. Start Visual Studio Code.
2. Click Open folder.
3. Open the Best-Practices-on-Azure-Sphere folder.
4. Open the EnvironmentMonitor folder.
5. Click Select Folder or the OK button to open the project.

Configure your own IoT Central app using the following Learning Pathway from unit one to eleven to run this project in its entirety: IoT Central Application

As part of the configuration it is important to follow the Learning Path above very carefully using the following criteria:

• IOT_PLUG_AND_PLAY_MODEL_ID inside main.c: dtmi:customEnvironmentMonitor:BestPracticesMonitorqq;1

• ID_Scope inside app_manifest.json: Obtained from your custom IoT Central App

• AllowedConnections inside app_manifest.json: Obtained from executing ShowIoTCentralConfig.exe (found in the Learning Path)

• DeviceAuthentication inside app_manifest.json: Obtained from your Azure Sphere tenant, run the command below to find it:

azsphere tenant show-selected

Once this has been configured it is essential to wait until the message below is displayed inside "Device Output":

[Azure IoT] Using HSM cert at /run/daa/43e5819f-b016-46d6-8364-3d7701be4362
Result: IOTHUB_CLIENT_CONNECTION_AUTHENTICATED
IoT Hub Connection Status reason: IOTHUB_CLIENT_CONNECTION_OK

In this module, you have got started with the basics of Azure Sphere. You have also run an application on Azure Sphere to retrieve sensor information on a button press and send it as a message up to Azure IoT Central using the Starter Kit Board.

We have also seen the basics of C and how it compares to other languages and why it is the chosen language of Azure Sphere. We have also developed a key understanding of the importance of best practices from Efficiency to Security as well as their application. For example, understanding pointers as part of Efficiency to data validation in Security.

Also had an in-depth look at the Azure Sphere MCU, operating system, and the safety architecture and how to take advantage of them to build high-level embedded systems using the best practices. We have also used the best practices to complete simple exercises to demonstrate these guidelines in real use.

Summary of the Best Practices

Efficiency and Robustness

As part of the Efficiency and Robustness section we have learned that it is vital to to know how to keep track of memory and use of polls in an embedded device. In this screenshot, in main.c contains an example of each:

• Track memory statistics if the app is run under the debugger using Visual Studio, example under Efficiency and Robustness

• The polls used are for the buttons using epoll and a timer is added which stops the app if no button is pressed within a one second time limit which is seen inside the ButtonTimerEventHandler function

Performance

As part of the Performance section we have learned the importance of using the right type of built-in functions. In this screenshot, you can see multiple instances of log_debug used to print to console than the use of printf. This is because during runtime it is ideal to keep track and record what is happening internally as the application is run, whereas printf is not designed for such use. As seen below inside main.c (Log_Debug is highlighted before every significant part of the app, from errors to successes):

Reliability

As part of reliability section we have learned it is ideal to have minimal dynamically declared variables as well as specific I/O handlers. In this screenshot at the top of main.c, there are static variables initially declared for handling buttons and polls. This is because they will be used throughout the application lifetime and its important to keep them as up to date as possible. Main.c also includes a specific I/O handler for A and B buttons on the AVNET MT3620 Board (i.e. ButtonTimerEventHandler). These examples are demonstrated below:

We also learned the importance of exit codes, as part of the example application, declared inside exit_codes.h:

Here is an example of its use, in case button A cannot be read:

If this is the case the application will terminate and Exitcode 3 will appear in the console (as initialised in the exit_codes enum) along with a Log_Debug error message, simplifying the debugging process.

The AzureSphereDevX library is used to simplify the development of this application. There are also other pre-initialised exit codes such as during the parse of command line arguments(i.e. for IDScope retrieval from app_manifest.json), if failed the success exit code is returned:

Security and Safety

As part of the Security section we have learned that it is important to validate the application certificates. In this screenshot, you can see we connect to Azure IoT Central which specifically uses a X.509 certificate for a secure connection through the internet instead of using connection string. This is because the connection created will be mutual as both the IoT Central App and the Azure Sphere device are identifying each other. This is demonstrated below, where we first establish a connection with Azure, then before a message is published, we check if the connection is still present.

Establish an Azure Connection:

Check for a connection:

Through this Learn Module you have learned a small number of best practices to be able to develop your own embedded system.