RoadTest: AVNET Azure Sphere MT3620 Starter Kit
Author: cbaldy
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: As a relatively affordable IoT-focused development kit, the Avnet Azure Sphere MT3620 Starter Kit joins MCU options such as the multitude of ESP8266-based development boards, Arduino lineup, TIs LaunchPad lines; most comparably the ESP8266, but adds a security element to the mix that was sorely needed and not clearly implemented prior.
What were the biggest problems encountered?: While the process of "claiming" the device in Azure was actually quite straight forward, some of the required jumping between the Azure Sphere Developer Command Prompt and Visual Studio was annoying. I do much prefer using a full blown IDE such as Visual Studio or Eclipse over the Arduino IDE or even TIs overall...the experience wasn't as easy to pick up as I am used to developing for a platform such as Expressif's ESP8266.
Detailed Review:
Summary
All in all, I have to say I was extremely impressed with the total package presented in the Avnet Azure Sphere Starter Kit. Although I initially whined about the lack of header pins included, I have to be honest, the only pins I have soldered on so far are the OLED I2C pins. I may also be coming around on the MikroE and Grove connectors being included (if more board vendors include them as well, and it becomes a standard for development boards). I can certainly see benefit to having an easy plug module capability. One concern I do have which I will have to wait to see is the pricing for the module without carrier-board; obviously this module would need to be priced such that it's use at a mass scale (i.e.: >100 units even) makes financial sense. If the modules are affordable and accessible (even for the hobbyist) I would certainly consider the MT3620 for my projects and especially if they were deployed anywhere in the "wild". Alas, if security is not a concern, the price point needs to compete with the wide range of currently available modules offering the capabilities of this module without the security. The real value (as in the Azure Sphere OS and Microsoft's committed 13 year support) should be placed front and center.
Personal Background
I work for a Telecom/ICT provider researching and developing data services for enterprise customers. The primary industries in our operating market are Agriculture and Mining (both standing to greatly benefit from the application of IoT) so the development and innovation of secure and reliable Machine-to-Machine and IoT services are becoming a major focus for us.
I studied Electronics Engineering in University and have had an affinity for micro-controllers since learning and working with PICs years ago. My primary platforms of choice today are TI's Launchpads (mostly using the 16 pin DIP MSP430s if the project can stand it, and just since they are so easy to plug into a socket once they are programmed), and the ubiquitous ESP8266. I have been very excited to work with the Azure Sphere Starter Kit since discovering the MT3620 form-factor was to be a castellated stamp module (as an ESP8266 fan, I've fallen in love with this form-factor).
Initial Impressions
I was both pleased with and very mildly disappointed with the platform immediately out of the box. While I was aware that the headers for PMOD, 5V, VBAT, and the I2C for the OLED display were not populated, I kind of expected that they would be included to be soldered on by the user if needed. I also wish the carrier board would have had some type of "socket" for the castellated MT3620 module. There are projects for which I purposely "scale down" just so that my DIP16 MSP430s can be used, since I can literally use them as I would have a PIC in the past (this for me is just much easier to prototype with as a hobbyist). I mean, the whole benefit of a SoC (or module) to me is to incorporate the necessary supporting circuitry into a nice, easy to interface package and I kind of wish that this platform would have better emphasized the fact that all of this capability is contained within this stamp-sized package. Size is of course an extremely crucial factor for the acceptance of any given IoT implementation. I do though acknowledge the demographic for such a development board, and firmly believe the design choices made were in fact the correct ones.
Aside from these seemingly trivial and topical gripes, this product really does excite me. I am very much a fan of Microsoft's innovation (proud Surface Pro owner), but unfortunately have fallen victim to their sudden dropping of platforms in the past such as the Band and Windows Phone; Azure Sphere OS seems different, I hope. Microsoft really is putting a lot on the line with their unprecedented support commitment for this OS (13 years), and for their investment in IoT in general, so I am hopeful that this will be sufficiently fostered and backed.
Among the features of the board which I appreciate may actually seem fickle to be honest; the plastic stand-offs. I'm so surprised at how many development boards I see that don't even consider mounting holes, let alone standoffs. It does however make me wonder a bit more why the standoffs are included but not the pins for the headers. I would have liked to have also seen more GPIO presented, and not the breakout specific to MikroE and Grove, but as I mentioned, I certainly do understand AVNETs motivation to do this.
If I were pulling the board out of the box starting completely fresh as a developer, I certainly would have appreciated the integrated sensors, buttons, and LEDs. For me however, they left me in a strange space. I sometimes find my development boards become a permanent component in projects I build. Most of the time when I use them like that, I end up just removing the additional unneeded components or if easy enough just removing the module/IC from the carrier board entirely. I feel development boards in this price range are most suited to this sort of short-run prototyping and the carrier board should act more like a reusable programming and debugging UART than a showcase of flashing lights and buttons. To be truthful, this has always been one of my biggest complaints about development boards and should not be considered as a direct fault with this specific one.
As for the initial setup and "hello world", this was an interesting one for sure. I appreciate (and I am certain other developers considering this platform for an IoT application agree) the priority Microsoft has placed on securing the platform. I understand that this aspect is not necessarily a factor of the carrier board at all (which is the portion I would consider to be AVNETs), but I do feel it needs to be mentioned. The appeal for me with this SoC, is strictly in the ability to establish "firewalls" to control access to resources. I would have been happy if the platform only did this and required integrating into some other MCU, but it does everything else as well. The MT3620 is an extremely capable platform, and coupled with Azure Sphere OS, and AVNETs carrier board the solution provides a very strong mix of breakout and functionality allowing developers to test, learn, prototype, and conceptualize. I initially started out following the three out-of-box demos from the Element14 page found at https://www.element14.com/community/community/designcenter/azure-sphere-starter-kits/ , eventually moving on to the Hackster.io workshop as suggested here on Element14.
For all of the samples and walk throughs, the demo code provided was very clearly documented and the walk-through was extremely easy to follow; despite some of the walk-through using VS 2016 (I think) and the version I downloaded was 2019, nearly all of the instructions were identical besides a very few which were easy enough to figure with common sense. Everything compiled well and ran smoothly first try. I did run into a snag with the OLED I had purchased but the solution was explained in a forum post (forgive me I do not have a link or member name to credit) which solved the issue immediately.
My original intent was just to log my experiences with the platform and compare it against some others I have worked with previously, however an interesting use-case came to mind while reading over some material for the platform and I may include some progress on this in the review. The use-case I am considering this platform perfectly suiting is to act as a "Trusted Platform Module" or TPM of sorts to authenticate users for an "Out-of-Band" (OOB) management platform specifically geared towards "Customer Premises Equipment" or CPE. Within my industry (Telecommunications), it is absolutely critical to be able to reach and manage network equipment at all times and especially when facilities such as fiber or copper are compromised. We rely on a management plane which is completely isolated to maintain reach-ability even when the locations primary power and connectivity are lost. Several commercial OOB solutions incorporate environmental sensors, external relays, redundant power options, and multiple fail-over connections (all of course easily handled with an MCU). To accommodate this however, the vendor equipment typically takes up a full 1U rack space or more. My thought is that by utilizing a platform such as this, the entire OOB functionality could be incorporated directly into a vendors equipment (i.e.: a router or a switch).
In conclusion, the Avnet Azure Sphere Starter Kit offers an excellent "board of education" and starting point to developing for the MT3260 and for the Azure Sphere OS in general. Having a development platform that integrates rich security maintained by a monolith as large as Microsoft, provides businesses with legitimate options to deploy an IoT solution highly customized to their specific needs, all while vulnerabilities, patches, and updates are handled by Microsoft.
