Getting Started with Azure Sphere

/

Pictures shows security aware graffiti

My free Azure Sphere development kit arrived last Friday, the day after I ordered it. Awesome. If you want one of your own you can get them here for free. It has serial ports, environmental sensors and buttons, plus a connection for an OLED display. You write programs for it using C via a Visual Studio extension. You can deploy and debug the code in the device from your PC and its very secure.

That’s all I really know at the moment, so lets get started. You can find the documents here. They tell you to go here and install the Visual Studio plugin. This also installs hardware drivers for the device. The bit that they don’t document very well is how to set up the device with Azure Sphere. You need to go here to do that. I worked through the sequence with no problems and now I’m waiting for my device to perform an OTA update to the latest firmware. Things that I noticed:

  • When you start using the azuresphere command in the Azure Sphere Developer Command prompt you’ll be asked to log in. This needs to be with an Active Directory enabled account. If you’ve not got one (because you are using an Office 365 subscription username for example) then that won’t work. However, if you’ve an Azure account (and having an Azure Sphere device without an Azure Account would be very stupid) you can use the free tier of the Active Directory provision (just click Azure Active Directory in the portal) to create Active Directory enabled accounts.

  • Once you’ve logged in with your shiny new Active Directory username you must create an Azure Sphere Tenant which acts as a container for your devices. Physical devices are then “claimed” by the tenant so that they are managed by that tenant. This is a one time action. Once a device has been claimed by one tenant it can’t be claimed by any other and a device can only be claimed by one tenant. I’ve made a Tenant called “Connected Humber CIC” for all our devices.

  • By default (i.e. unless you specify otherwise) any user in the Active Directory that authenticated your azuresphere command can control your devices, including pushing new firmware, claiming new devices and so on. If you want to restrict this you’ll have to set this up yourself. It’s not hard to do, but you have to do it. This is not a problem if, like me, you’re only got a few users on your Active Directory, but it would be an issue if you were adding the tenant to a large Active Directory setup (perhaps a corporate lan) with lots of users with different levels of access.

  • You have to use the azuresphere prep-debug command to allow you to deploy code into the device and debug it from Visual Studio. Once you’ve put the device into debug mode it stops receiving OTA updates. The azuresphere prep-field prepares the device for the field. These commands might install usb drivers for the debugging, so they need to run in Administrator mode - (start the Azure Sphere Developer Command prompt as Admin)

  • The Visual Studio Add-In for Azure Sphere works fine in Visual Studio 2019

Well, the firmware update has completed, I’ve done the command to prep the device for debug and now I’m running the GPIO version of “Hello world”; a flashing LED. I’ve even managed to put a breakpoint in the code and stop it. Next thing to do is connect a sensor and get my Air Quality code ported across so that I can get readings into the device, then I’m going to have to figure out how to get the readings over the network to store them and finally how to deploy the code for real.

Exciting stuff.