Developing IoT Devices from Your Local Computer

Developing a typical software application locally often involves an IDE (Integrated Development Environment) or even a simple text editor (even Notepad), some sort of build system in the case of compiled languages (like C#) or an interpreter in the case of interpreted languages (like JavaScript). The process often looks like this: Write some code, compile it, run it, see what’s changed. If you are really cool, you can just run some unit tests as you develop to find out if what you have is working rather than running the whole application just to test one thing.

When you are developing for an IoT device, it can get more complicated. Sometimes there are emulators available that can simulate the physical device, other times it makes more sense to actually deploy code to the physical device. If there’s a physical device in the mix, you can deploy code over the wire, like through a USB cable that connects your device to your computer, or over WiFi, or in certain setups even through the internet.  For my Raspberry Pi 3, running Windows 10 IoT Core, I can develop locally using Visual Studio and deploy over my local WiFi new code to my RPi directly from within Visual Studio. For most devices, there are a few ways to develop and deploy to it and it’s highly dependent on the platform of choice.

Whatever the process, reducing the time it takes from changing something to finding out if it works is very important.   The first line of defense I have for being able to iterate quickly is unit tests. Unit tests can run very quickly, and can run against most of the code base all at the same time. Although they can be a pain to set up, the long-term efficiencies gained from knowing that most of your code works every step of the way is a huge time-saver.

This is true of regular development. When IoT is thrown into the mix, with the additional time it can take to deploy code to an emulator or a physical device, the efficiencies gained can be even greater than from application development. The next tactic is to use emulators when you can (as it’s typically faster than deploying to a device), and then when you do have to deploy to a device, make it as repeatable and quick as possible.


Smart Bronco: Choosing an IoT Operating System

What’s a piece of hardware without the operating system to run it? When buying a new desktop computer, the decision often comes down to a few choices: Mac, PC, or Linux. Operating systems in general are designed to run on a limited variety of processors, for example, Microsoft Windows historically has run on processors that run the x86 instruction set (they do occasionally get it to run, with some qualifications, on ARM processors). Linux has been compiled to run on a variety of computer architectures. macOS, it turns out, used to run on Mac processors and now runs on x86 and ARM.

With x86 and ARM being the dominant processors on laptops, desktops, and even phones, does the same hold true for IoT devices? Yes! And no. It depends.

If we are talking about microcomputers, which are essentially tiny desktop computers, often with GPIO (General Purpose Input Output) pins, then yes. The Raspberry Pi 3 is a widely adopted version of this. With an ARM processor, the same architecture as the ones that are in the vast majority of Android phones these days, it can run both many flavors of Linux and a special version of Microsoft’s operating system called Windows 10 IoT Core that gets specifically compiled for ARM processors.

When we want to go with even smaller, cheaper, less power-hungry (and less versatile) devices called microprocessors, the operating systems are more tied to the hardware because they run so “close to the metal” as they say. Rather than talking through abstractions, like the full-fat operating systems mentioned thus far, they often have strong dependencies on the underlying hardware. This category of operating system are typically called “Real Time Operating Systems.” Because there are many different types of microprocessors, there are many different types of RTOS in use today. For example, if you choose to use a Particle Photon, it comes with an operating system called “Device OS”. For any given microcontroller, there are usually a few different RTOS compiled down to be used by that hardware. With so many microcontroller choices, the mix-and-match options with operating systems are varied. Which one you choose is all about what you want to do. For example, if you wanted to use JavaScript to control your Particle Photon (rather than the out-of-the-box C-like language), you could install a new OS (or “firmware”) called VoodooSpark and run the Johnny Five framework on top of it.

For the Smart Bronco project, I am choosing a Raspberry Pi 3 with Windows 10 IoT Core running on it. Windows 10 IoT Core is like Windows-light, with the ability to run only Universal Windows Applications. It is specifically designed for the Internet of Things, even going so far as allowing users to create their own build of the operating system, for example if you’d like to remove the ability to do SSH in production for security purposes. When it comes to operating systems, I know that Microsoft has a great track record with stability and support, and so that confidence also helped make this decision easier for me.

As a developer, the operating system allows me to write code in C#, which is a language I’m familiar with. It will also allow me to take advantage of some of the tools that Microsoft gives for deploying updates to devices (more on that later). I also will be able to run multiple programs at the same time, which could be useful as I start to add more functionality to the Bronco. In addition, because I want to have the option for both “headed” (with a user interface) and “headless” (without a user interface), I know Windows 10 IoT Core gives me both those options.

In your own search for the perfect operating system for your project, making a choice and learning from it is more important that choosing the perfect solution right out of the gate.

Smart Bronco: How to Choose IoT Prototyping Hardware

Choosing hardware to prototype with in the realm of IoT can be overwhelming. There are so many choices! And, there’s so many constraints when it comes to putting a piece of hardware into production:

  • Power requirements vs. availability
  • Internet connectivity options
  • Processing requirements
  • Preferred programming language support
  • Security
  • Manufacturer’s support
  • Availability
  • Longevity

My advice is simple: Don’t worry too much about those constraints when you are just getting started. To make a prototype, focus on what’s going to allow you to fail early and often. In my experience, the prototype will only serve as a reference for the real thing. So, use the hardware that will allow you to get up and running quickly and worry about the constraints later.

For example, if you know JavaScript really well (or your team does), and your aren’t sure what processing power you’ll need, go with a microcomputer with some decent computing power that supports a mainstream operating system like a flavor of Linux or Windows. While options like Raspberry Pis with Windows 10 IoT Core or Raspbian works, don’t be afraid to spec out an Intel NUC or something similar if you want the full power of a desktop processor. This is a proof of concept, after all.

For me, I know the .NET platform pretty well, I’m familiar with C#, and I’ve used the Raspberry Pi with Windows 10 IoT Core before. I think I’ll stick with this tried-and-true formula (at least at first) as I validate that I can get information from a sensor reading the coolant temperature on the Bronco and send it up to Azure using IoT Hub.

Once the concept is proven, assuming that the concept is something like “Can we take this outdated protocol from an old machine and run it through an IoT edge device and get it to the cloud?”, the next step is to take those constraints into consideration and move the code to the hardware that will support those constraints. I’ll cover that another day!

Smart Bronco Project Announcement


Over the course of the next few months, I am planning on taking my 1988 Ford Bronco II and making it a little more smart and a little more connected, thanks to the power of the Internet of Things. I plan on using this cruddy old truck to experiment and learn about IoT being applied in the real world. Of course, because I work at Nebbia Technology, I will be applying DevOps practices and using the Azure cloud. I’m really looking forward to creating, learning, and sharing about how to apply IoT best practices to not only crusty Ford Broncos, but to new IoT projects and products as well. Stay tuned!