Chapter 3. Your Developers’ User Experience
Chapter 2 talked about reconciling the two main constituencies of your device: users and developers. This chapter digs down more into the developer experience and looks at how your prototyping decisions affect your future developers. A connected device is rarely just a black box. At a minimum, your customers will need someone to integrate that device into their system. But as more computational power comes to the devices you create, there’s more opportunity to enable customers to customize well beyond the initial feature set you envisioned for your product.
The Two Platforms
There was a time when, if you wanted to build a connected device, you’d need to research all the chip vendors, spend hundreds of dollars on evaluation boards, sign nondisclosure agreements to get access to SDKs, and then swim upstream into the vendor’s sales funnel when you needed any kind of guidance developing your prototype.
This old way of doing things was turned on its head with the arrival of the Arduino, an inexpensive microcontroller board for prototyping that allowed anyone with an idea, a modest understanding of electronics and programming, and motivation to create a connected networked device.
More than 10 years later, and Arduino will forever be remembered as the platform that launched the desktop 3D printing revolution. Without Arduino, the creators of 3D printers such as MakerBot, RepRap Prusa, PrintBot, Ultimaker (and many more) would have had to roll their own controller boards for their motors. This early success has validated Arduino as a robust platform for creating connected devices.
And not too long ago, Arduino was joined by a board with very different capabilities: the Raspberry Pi. The Pi became the perfect complement to the Arduino. Where Arduino projects run on the bare-metal CPU, Raspberry Pi boards come with an operating system, Linux, Windows IoT Core, and others. Arduino and Raspberry Pi complete the platform level of the full hardware stack.
Unlike the Arduino, the Raspberry Pi was never really designed as a platform to be used by developers. However, at $35, it made single-board computing accessible, and it was months after its release before supply caught up with demand. The release of the Raspberry Pi Zero, at $5, was met with a similar rush. Supply still hasn’t caught up with demand. While not optimized for development, the board was good enough and cheap enough to build a community around it.
With Arduino and Raspberry Pi, the choice of prototyping platform was simple. If you wanted to talk to arbitrary bits of electronics, your best bet was to buy an Arduino microcontroller board; if you needed the power of an ARM-based board and wanted to run Linux, Raspberry Pi was the best option. If you needed both, you could run a USB cable between them.
The story could have ended there, but it doesn’t.
The New Platforms
Prototyping platforms are becoming more expansive. It’s cheap to add radios to boards, and some platform builders have taken this very far with “kitchen sink” boards. These platforms take the attitude that if one radio is good, another is better. If you can cram another sensor onto the board with only a minor increase in the bill of materials, then another one again seems like a good idea.
On the other hand, we’re seeing the emergence of new “use everywhere” boards, which have minimal features but are cheap, have onboard networking of some sort or another—usually Bluetooth LE or WiFi—and are usually optimized for low-power environments. Typically they also come in small form factors.
The “kitchen sink” board
The great thing about using Raspberry Pi or Arduino is that lots of developers have them, and there is a great deal of community support around them. But specialized boards, like MediaTek’s LinkIt One, have so many features, they can be hard to resist. The LinkIt One for instance supports GSM/GPRS, WiFi, Bluetooth BR/EDR and LE and has an onboard GPS, as well as GPIO, I2C, SPI, UART and Grove connector support.
Boards like these are designed to be a platform for prototyping IoT devices, but the boards themselves are not designed to be deployed as IoT devices. Right now a lot of the work being done inside the IoT community is exactly this, to build platforms, developing something that other developers will build on.
The “use everywhere” board
The poster child for affordable, easy-to-deploy IoT boards is the ESP8266. The Espressif ESP8266 SoC was originally released as a serial-to-WiFi bridge for another microcontroller, like an Arduino.
But it cost less than $2, and as a result a somewhat bewildering selection of module and breakout boards have been produced. It was so cheap people started looking at it rather closely and discovered that it is a full microcontroller in its own right.
In fact, it’s a very capable 80 MHz microcontroller based around a Tensilica Xtensa LX3 core with WiFi support, both as client and as an access point, supporting 802.11 b/g/n protocols at 2.4 GHz and WPA/WPA2 with a full onboard TCP/IP stack with DNS support. It has GPIO, I2C, I2S, SPI, and PWM support. It also has a 10-bit ADC.
Most of these “use everywhere” boards are designed with small form factors and low power requirements. In almost all cases, they also come with advanced power management capabilities and the ability of sleep (and wake) based on external interrupts.
These boards exist in a very different niche than the “kitchen sink” boards being developed as platforms for experimentation. On the one hand, “kitchen sink” boards provide infrastructure for already-identified IoT niches, such as remote distributed sensor networks. On the other hand, they are generally too expensive in single-unit quantities to be viable deployment platforms. However, “kitchen sink” boards are often based on reference designs that chip vendors provide and can be invaluable prototyping tools.
You Won’t Program to the Platform
The Arduino software has been expanded by its makers and their competitors to go beyond the initial 8-bit microcontroller it supported to ARM, x86, and other boards. Large chip makers, like Texas Instruments with its LaunchPad boards based around its MSP430 processor, have gone out of their way to provide Arduino-compatible development environments in an attempt to capture the Arduino developer community.
So even if you’re not using an Arduino, you can prototype on another platform with the same programming language and libraries; the ESP8266 and LinkIt ONE are both examples of boards that you can program with the Arduino IDE.
The upshot is that connected device developers can reach for a Raspberry Pi, Arduino, or any of dozens of boards when prototyping, and won’t have any shortage of developers or knowledge to draw upon. And when it comes time to bring a device to mass production, the path from one prototyping board to many manufactured units is well understood, even if you’re a different chip than what powers the Arduino or Raspberry Pi.
But at the end of the day, your Arduino code is just C++ running on top of some libraries and macros that simplify your code and make it possible for the same source code to compile to multiple chipsets. With Raspberry Pi, you’re using the same Linux software development tools that you use on desktop machines or servers.
If you stick with Linux on single-board computing platforms like the Pi, and the Arduino IDE on all the bare-metal boards, it will be hard to go wrong. You’ll end up with a prototype that has portable code that can be deployed to many different platforms.
Talking to the Cloud
An IoT device does not necessarily need to connect directly to the Internet. However, while a smart, connected device can operate in a standalone fashion, or form part of a local (possibly mesh) network, most connect outward to the cloud in some fashion.
Notwithstanding our discussion in “Local, Edge, or Cloud?”, the architecture of most connected devices is similar: there is the thing itself, an application running on a computer or gateway device that controls the thing, and a cloud service that backs both.
To the Cloud
There are three main models of cloud computing: public, private, and hybrid. A public cloud is one in which services and infrastructure is provided by a specialist cloud company. A private cloud is one where services and infrastructure, the machines the services are running on, are owned and maintained by your own company. A hybrid cloud is a mix of public and private cloud infrastructure.
There’s no reason the cloud components of a device need to be tied to the company that built it. There’s nothing to stop companies from creating devices that will self-deploy the cloud capability the device needs directly to the customer’s cloud provider of choice. This way, customers can pay for their own cloud usage but also migrate the device’s cloud components between different providers as needed.