It has been a while since Microsoft tries to enter into a new market of hardware since the Zune failure in 2006 that's different from new mices and keyboard or even new XBOXes. There's a reasonable question once up you measure the amount of money that it's important to deal with when you work with hardware. If your software product does not make enough money, you can just lower the price or even (if it has a lot of bugs) remove from the market. When you deal with hardware there isn't this kind of easy-way solution because you'll need to store it in some place, so the problem starts even worse if you need to replace your client with this kind (AKA x360 - 3 red lights).
So Microsoft knows more than any giant company in silicon valley that if you want to walk by this path, you need to take care and that's why this chip that's present in this DK, it's not has been developed by Microsoft rather it was projected by one of the largest semiconductors company in the world from Taiwan, Mediatek.
The Azure Sphere
A solution for creating highly secured, connected MCU-powered devices to help you reimagine your business, drive innovation, and delight customers.
That's why they claim to name this as Azure Sphere, so the concept is that we have a secure OS, a secure MCU and cloud security that'll help us to develop our IoT products in a secure manner. Secure it's what they say, but the hackers that'll confirm this for us in the future. The way that they guarantee security it's through OS layer levels and intrinsic Microsoft firewall between buses inside the chip (that's why we have only one certified chip until now).
I throughly believe that M$ has knowledge to develop such a kind of security support but as Windows, weekly updates in embedded devices for IoT it's what developers wouldn't imagine when they grab a new IC to test.
What about this MT3620?
Okay, let's talk about the hardware that I have in my hands.
Azure Sphere MT3620 Development Kit has three MCUs, one ARM Cortex-A7 core and two general purpose ARM Cortex-M4F cores, it has embedded support for real time requirements using different set of peripherals like GPIO, UART, I2C, SPI, I2S, PWM and ADC along with dual-band 802.11 b/g/n Wi-Fi (more than enough for embedded homemade projects =)). According to the Seeed Studio wiki page about the MT3620, until now we don't have support in Azure Spehere software for:
- Two general purpose ARM Cortex-M4F cores
- ADC, I2C, I2S, PWM, SPI
- Wi-Fi 802.11a, and RTC with clock selection and battery backup
That's my face when I read this for the first time ... it's like removing the two wheels of a Ferrari just because the steering wheel does not support four ones. Be patience because probably in their new update this will not be an issue anymore, they'll release a new update to support this, wait I've mentioned updates...Sorry, talking seriously they have a lot of IOs connected through the pin headers that'll be enough for small/medium size applications such as sensors reading, remote actuators, active wireless controllers for IoT problems and others.
Besides the not so good points, the hardware has a small form factor and has good ESD protection in the PCB, avoiding some damage when manipulating the board. Also, the two antennas using the diversity feature helps to improve the quality and reliability of a wireless link when connected through a Wi-Fi access point. Another good point is the Azure support that's capable to talk directly with the hardware to update and exchange info with the target. In the video below, there's a small demo proposed by Seeed Studio for this board where you can check the connectivity.
I received one development kit from Seeed Studio to review it (tks guys!) and at first glance, the setup of this board seems easy (the Anderson's from future does not agreee at all) for new Windows developers, once up it's all based on Visual Studio IDE even for me, as I'm not so used with Windows OS. The first issue that I faced during the installation of Azure Sphere SDK preview was the Windows version where mine was out-of-date to use such set of tools. Then, after update everything and installing all the tools needed, it was time to blink some LEDs (at least what I've imagined...). Microsoft has a
confuse complete wiki for getting started with the target, what helps when you need to work with the board out-of-the box without manuals or tutorials in the internet.
After playing around with formating windows with a new version that's compatible I follow the tutorial to recovery the update with the latest firmware:
Now it's time to create an account to azure portal, what's not so good for developers because you should have a credit card to enable the free trial account. Also, after creating an account, you need to create a domain service so you'll be avaiable to create an user in the AAD (Active Azure Directory). I've spent 4 hours to discover such thing because the docs at the moment are not so clear about this kind of steps if you're not a frequently Azure user.
In the image below you can see that the user should be part of a specific domain name that was created before.
NOW with the user created in AAD and the board updated I'm able to register:
$> azsphere login # Now you make the login with the AAD user then.. warn: No Azure Sphere tenants found under the selected AAD user. Use 'azsphere login' to change AAD user, or create a new Azure Sphere tenant using 'azsphere tenant create'. Successfully logged in with the selected AAD user. This authentication will be used for subsequent commands. Command completed successfully in 00:02:30.6191316. $> azsphere tenant create --name aignacio # The command below will create an remote user into our hardware, it should prompt a new login form.... Created a new Azure Sphere tenant: --> Tenant Name: aignacio --> Tenant ID: 4xxxxxx-3xxx-4xxx-axxx-4xxxxxx Selected Azure Sphere tenant 'aignacio' as the default. You may now wish to claim the attached device into this tenant using 'azsphere device claim'. Command completed successfully in 00:01:47.5780036.
Login into again and then you'll be able to "claim" the device and link with your AAD user with the folloing commands:
$> azsphere device claim C:\Users\aignacio\Documents>azsphere device claim Claiming device. Successfully claimed device ID 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' into tenant 'aignacio' with ID 'XXXXXXXX-XXXXXXXX-XXXXXXX-XXXXXX-XXXXX'. Command completed successfully in 00:00:05.1698435.
According to Microsoft documents there's not step back after you claim the device with the user, so be sure to take note of the passwords. These commands should be used in the Azure Sphere Developer Command Prompt Preview console. It's time to set up your wifi with the device:
$> azsphere device wifi show-status SSID : Configuration state : unknown Connection state : disconnected Security state : unknown Frequency : Mode : Key management : UNKNOWN WPA State : DISCONNECTED IP Address : MAC Address : xx:xx:xx:xx:xx:xx Command completed successfully in 00:00:02.6271540. $> azsphere device wifi add --ssid HomeStark --key supersecret ID : 0 SSID : HomeStark Configuration state : enabled Connection state : unknown Security state : psk Command completed successfully in 00:00:02.1536220. $> azsphere device wifi show-status SSID : HomeStark Configuration state : enabled Connection state : connected Security state : psk Frequency : 2447 Mode : station Key management : WPA2-PSK WPA State : COMPLETED IP Address : 192.168.0.28 MAC Address : xx:xx:xx:xx:xx:xx Command completed successfully in 00:00:01.5876206.
You can also check if your device it's up-to-date with:
$> azsphere device show-ota-status Your device is running Azure Sphere OS version 18.11. The Azure Sphere Security Service is targeting this device with Azure Sphere OS version 18.11. Your device has the expected version of the Azure Sphere OS: 18.11. Command completed successfully in 00:00:03.7033041.
After following this tutorial now I'm able to blink a simple LED program and upload through OTA using MSVS Studio. The user interface it's very clear to use and easy to compile the example, so no worries about this point.
Then finally our simple demo:
What I've think until now....
It's good to hear that big companies decide to look with a bit of attention to developers, supplying with new hardware boards for IoT world, so seeing M$ entering in this movement I think that's nice! But as homemade developer, I think that the starting price it's higher than usual, what could be a consequence of the security embedded in the hardware through the chip and I don't know if the developers will spend more bucks for this feature, not now maybe. Also, I think that peripherals must be the first thing to worry in M$ plans in the near future for this board because release such a target without APIs to use ADC, SPI...it's not so good when you want to test some sensors.
Also the starting point doccumentation should be rewrite in a easy shape form for new Azure users, like Espressif IDF docs (good example to follow ;D) and less steps should be integrated to make the cloud interface more deploy-to-go device.
Thus not be completely ready until now, doesn't make the board not useful, but enables you to test Azure platform integrated with a real developed for hardware, what can be good if your plan overlay these cloud path. I've plan in the future to develop a real project with this target and keep updated in this blog if you want to see such project in the next posts.