|Product Performed to Expectations:||9|
|Specifications were sufficient to design with:||10|
|Demo Software was of good quality:||10|
|Product was easy to use:||8|
|Support materials were available:||9|
|The price to performance ratio was good:||9|
|TotalScore:||55 / 60|
Unboxing and First steps
The package received contains the development board, Micro USB Cable and a quick guide with a link to Azure sphere SDK and to AVNET documentation.
The first thing that I did was running the excellent tutorial from Brian Willess, it is a 3 part tutorial that covers most of the functionalities of Azure Sphere Starter Kit. The tutorial starts with a simple non-connected demo, then move to connected demo using IoT Hub and finally the IoT Central demo. Following the tutorial was pretty straight forward, but I have difficulties to claim my device as there is a need to have an Azure Tenant that I was only able to get after a few attempts on the Azure portal.
Tools and SDK
As documented on Brian’s blog posts, I’ve installed the Community version of Visual Studio 2019 and the Azure Sphere SDK. Although my professional experience with Visual Studio date from my early days as a Test Engineer with Visual Studio 6, I didn’t have any problem to setup and run some examples from Brian’s tutorial. My personal Notebook is a Lenovo X1 from 2014 with Intel Core i7-4600U CPU , 8.00GB of RAM and 512 GB SSD, it is an old notebook but still able to run Visual Studio 2019.
Azure Sphere Command-line Interface
The Azure Sphere Command-line Interface is part SDK and is used to configure Azure Sphere MT3620. You can use the “azsphere” command to manage your hardware like configure WiFi, start OTA update, check status and others. There is also some command to handle Azure service login and to claim your device.
Claim and Update (via OTA)
One of the first steps you need to do is to claim your device, but you will need to have a user account on Azure Active Directory, I had some hard time to create the AAD User, mostly because I’m not familiar with Azure. There is also the pre-debug command that will allow you to load and debug your applications.
It is also possible to update the Azure Sphere OS version using the CLI tool, in fact, it is pretty simple and automatic:
There are 2 types of applications that can run on Azure Sphere OS, the first one is called “High-Level Applications” and the second one called Real-Time Capable Application, which is also called “RTApp”. From my understanding from Microsoft documentation High-Level Application has the connectivity and security layers, although you can also have a High-Level application accessing HW GPIOs and others.
The RTApp can only access hardware peripherals, but no direct access to network. In order to access the network RTApp must communicate with a High-Level application that has the security layer. Another interesting point regarding RTApp is Microsoft says the RTApp can either run as bare-metal application (all RTApp examples provided is bare-metal) or RTApp can run in a RTOS, but you will need to port the RTOS to run on MT3620. As per MT3620 datasheet, this Chipset has one ARM Cortex A7 processor ( where I suppose the “Linux” based Azure Sphere OS is running) and two ARM Cortex M4 cores for real-time applications, so it seems that user could port some RTOS to run on this cores.
The Azure Sphere has good API documentation, there are libraries called Base APIs that includes C standard library, curl, TLS and a specific Azure IoT C SDK library. The Applibs API has the libraries for accessing HW (gpio, i2c, ADC, RTC, Storage, etc), a library to High-level Application and RTApp communication, Logs, Wifi and others.
An important part of application development is the Application Manifest, it contains many application permissions including HW peripheral and network related permissions. Even if you are developing a LED blink application, you still need to declare each GPIO pin you are using, I guess that is part of security capabilities.
The development board is based on MT3620 MediaTek SoC, as already mentioned it has one ARM Cortex A7 running at 500MHz and two ARM Cortex M4 running at 200MHz, the list of peripheral is pretty complete and includes 5x UART/I2C/SPI, 2x I2S, 8x ADC, up to 12 PWM counters and up to 72x GPIO. It also contains a builtin WiFi 1x1 dual-band 802.11a/b/g/n for connectivity.
The main interfaces to connect external peripherals on the board are the MikroE Click board and Grove System. There are also a UART and an SPI for connecting an external display. Honestly, that was a little disappointing as the MT3620 has a lot of GPIOs, I would expect to have some of them exposed via an Arduino like or Raspberry Pi like connectors. It is true that users still able to use MikroE Click or Grove connecter by wiring the pin exposed to a breadboard, but I would like to have a more common option as well. Also, regarding the MikroE Click Board, it was difficult to find a store that sells the Click Boards here in my home country (Brazil).
The board also contains some sensors, that is excellent as users can use them to collect some data and upload to Azure out-of-the-box, the sensors are ST LSM6DSO (3-Axis accelerometer, gyro and temperature), ST LPS22HH (Pressure and Barometric) and an Ambient light sensor. The AVNET GitHub has examples for LSM6DSO and LPS22HH, which is very helpful to first-time users.
Microsoft Pluton security subsystem is the base of Azure Sphere ecosystem, a great overview of Pluton can be found on Azure blog post called Anatomy of a Secured MCU that I would recommend. I have no intention to explain this here, but basically Pluton generates a key-pairs in silicon during the manufacturing process by using a called true random number generator that uses entropy from the environment. Pluton has a dedicated core used to accelerate cryptographic tasks like hashing with SHA2, Elliptic-curve cryptography (ECC) and AES encryption. All this allows Pluton to provide secure boot and remote attestation for base OS and user applications. The dedicated core can also control access of peripheral in other cores, that’s why even a single GPIO needs to be declared on application manifest.
The Brian’s tutorial covers 3 examples: standalone, IoT Hub Application and IoT Central Application. In the standalone data from sensor are printed in the output at Visual Studio:
The most interesting for me was IoT Central, it was pretty easy to setup and visualize the sensors data. Although during my configuration I realize that surprisingly there is no Azure Sphere MT3620 on device templates, so you need to create a custom device, but this is not a big problem as the interface is pretty easy to follow :
So what’s next? Here is a shortlist on my further work with this kit:
Join Azure Sphere Technical Training Course from Hackster.io
Play with Microsoft Azure Sphere examples
Play with the new Azure Sphere OS Version that was released recently (19.09). The new version added support to new features like adding support to PWM and ADC for High-level applications, enable connection to hidden WiFi Networks and others.
Add different sensors and displays
Another thing that I would expect in a new further is Microsoft to add support to .NET Core IoT library that was recently released. I would play with this as well.
The Azure Sphere MT3620 Kit is an excellent kit for anyone looking to jump in IoT development, besides few problems with Azure account and some difficulties to buy MikroE Click board, I had a very good experience playing with this Kit. The environment with Azure Sphere CLI Tool, Visual Studio and IoT Hub Central provide an easy follow experience, allowing a user to rapidly prototype a new IoT application while security is handled by the Microsoft Pluton security subsystem.
References and Links