Getting started with Azure Sphere

Microsoft’s Azure Sphere is an interesting concept, a mix of secure cloud services, secure devices, and a new Linux-based operating system, all rolled into a single platform and a Visual Studio-based development platform. I recently received one of the first MT6320 development boards, and I’ve been taking it for a spin.

One of the big problems facing the IoT (internet of things) is security. We’ve all heard how smart bulbs have become part of botnets and how easy it is to break into a home hub and monitor devices. The question is, how do we secure a device that has no root of trust and no tracked supply chain?

That’s where Sphere comes in, mixing secure computing concepts with IoT. Key to the design is an end-to-end link between device, OS, and cloud services. At the heart of the platform is a secured microcontroller, with standard ARM processing and real-time cores, along with Microsoft’s Pluton cores, which mix CPU and hardware root of trust, building on the familiar concepts in Windows’ use of trusted computing modules for secure boot and to cryptographically manage key system components.

Securing the hardware and ecosystem is only part of the story. How easy is it to write code and deliver it to Sphere devices? You can have the securest hardware possible, but if you can’t deliver code, then it’s ultimately useless. Sphere’s original demos with Starbucks were a sign that Microsoft was on track to deliver a usable developer experience, but we had to wait until they shipped tools to see how easy it could be.

IDG

Setting up a Sphere developer kit

Getting started with a Sphere developer kit is relatively quick. The board connects to your PC via a USB cable and automatically sets up as a serial device connected via three USB serial ports. Once it’s connected, download the Sphere SDK for Visual Studio. Although it’s still technically a preview, it’s ready for building apps and gets regular updates as new features are released.

During installation the Sphere SDK adds an IP over USB connection to your developer board, along with its own command line tools. The command line tools are needed to update devices to the latest OS and to control the process of registering it to the cloud-hosted Azure Sphere Service. All the commands are prefixed part of azsphere.exe; type azsphere in its developer command prompt tool (not the Windows terminal) to get a list of the available commands from the built-in help.

Azure Sphere devices are managed from Azure, and that requires setting up an Azure account that’s connected to Azure Active Directory. Signing in for the first time automatically creates an Azure Sphere tenant, which isolates your registered devices and ensures that only you can manage them and deploy software to them. Devices need to be “claimed” to be managed; once claimed they can’t be used or managed by anyone else, even if you sell a development board to another user. Each device has its own unique ID to identify it to the Azure Sphere service and lock it to a tenant account.

Connecting to Wi-Fi

Working with a directly connected device is only part of the story. Sphere needs connectivity to work independently, either when deployed or as part of your development environment. Getting it online with the built-in Wi-Fi is a matter of using the command line tools to configure the developer board’s built-in Wi-Fi, using the azsphere device wifi command. First check its status, and then add an SSID and key. Sphere only supports WPA or WPA2 and will not use hidden SSIDs. Once connected, the device will automatically check for over-the-air updates and install them. You may have to wait a few minutes before the device is ready to use.

Your device is now ready for code. Microsoft provides an initial sample app that blinks a device LED as part of the SDK. First you need to switch on debugging support, using the azsphere device prep-debug command. This locks down over-the-air updates, so code under test won’t get overwritten, and readies the device to get code from your local Visual Studio.

Code is written in C and uses a similar syntax to most devices, with libraries to map I/O to its ports. With the general purpose I/O libraries loaded, and an appropriate application manifest, it’s relatively simple to write code that can trigger outputs or read inputs, much like working with an Arduino or any other microcontroller. Code can be pushed to a Sphere device directly from Visual Studio, with direct debugging access over the USB cable. Additional libraries add support for real-time code, which you need to build the Sphere MCU hardware into control systems.

Using over-the-air deployment

Things get interesting when you start using OTA (over-the-air) deployment. Prepare the device first, giving it an SKU name and joining it to a device group. The cloud service uses these to deploy code; device groups let you target specific devices for specific versions of the software, supporting testing of different versions of your code on different test devices. Devices are then connected to feeds that deploy your applications.

By linking an OTA feed to your application image package, building the code will deploy it to the appropriate channel and a device reset will download it and start it running. This approach lets you connect a device—or even a set of devices—to your CI/CD build process, pushing code to development and production devices as it’s built and tested.

More advanced features

Microsoft has built SphereOS on Linux, but you won’t have access to the command line of any deployed devices, especially if you’re embedding Sphere MCUs in consumer hardware. A controller in a kitchen appliance isn’t easily accessible, and the limited selection of buttons available makes it hard for users to select a wireless network, let alone type in a WPA password. Microsoft offers an option here in the shape of a reference solution that uses a Bluetooth Low Energy (BLE) device to receive WPA configuration information from a phone app to set up a Sphere-based device, as well as showing how to connect BLE hardware to a Sphere development board.

Microsoft is still rolling out new features to its Linux-based SphereOS. The latest builds unlocked the real-time cores in its secure MCU, giving you access to hardware that’s essential for building complex control systems, such as those used in industrial control systems. What you get now is what you need to start building your own apps on developer boards. This is only the beginning though; to really get the benefit of Azure Sphere’s secure environment you must start using it with production hardware.