Embedded software engineers have always been a rarified group. When application programmers were moving toward high-level object-oriented programming languages like C++, Java, and graphical application development environments like MATLAB, embedded programmers were only reluctantly moving from assembly language to C. There have always been many fewer embedded programmers than application programmers, especially when smartphones allowed clever hackers and hobbyists to develop an app and upload it to the cloud. Unlike app developers, embedded programmers need to have a deep understanding of the hardware platform on which their code runs.

The Internet of Things (IoT) promises to bring about a big change in this equation. With processors going into every thermostat, toaster, watch, and light bulb, there needs to be many more embedded programmers to write the IoT apps, and there needs to be more tools that allow programmers to write code without knowing the hardware. This seems like a big challenge – and a big opportunity – for an industry where the code is tied very closely to the hardware.

Companies that produce embedded software tools are recognizing the need to adjust these tools and their message for this new breed of IoT programmers. At least the ones that will remain successful and relevant are recognizing this need. One particular area that needs changing, I believe, is the real-time operating system (RTOS) that schedules the applications and is very closely tied to the hardware.

Many traditional RTOS companies see the solution as providing modular RTOSs. Micrium, for example, lets a programmer select only the modules required, thus reducing the amount of system memory required. It allows programmers to pick and choose their functionality from a large library and only write code for the unique tasks that their device will perform. To allow a task to interface with the RTOS, with other tasks, and with the hardware, the user still needs to learn and understand the dozens of APIs controlling low-level things like mutexes, semaphores, and memory management. This strategy fits into the traditional RTOS business model that has worked in the past for embedded systems.

Wind River, an Intel subsidiary, provides RTOSs that allow network connectivity to a cloud and provides tools to manage that cloud. It appears that Intel is focusing on the powerful servers that manage the data coming from the many IoT devices. That makes sense because Intel makes big, powerful processors that are suited for data crunching. They have long ago moved away from small, inexpensive, low-power processors that are required for IoT devices. Wind River appears to offer a classic, relatively big and complex RTOS with networking protocols to easily connect to data-crunching servers. This strategy fits in with Intel’s desire to sell bigger, more complex processors.

The new players in the IoT device space include Apple and Google, which are creating their own RTOSs for this market. Apple has HomeKit, and from what I can gather, it’s focused on iPhones and other Apple devices controlling IoT devices. But there’s little support for software development for the IoT devices themselves. To find out what support there is, you need to join the somewhat secretive MFI program. Once you’re approved by Apple, you get some kind of tools, but they appear to be compliance tools rather than development tools. This strategy fits in with Apple’s desire to sell more iPhones, iPads, and iMacs.

Google has a different approach; they recently announced a small RTOS called Brillo that’s based on its successful Android smartphone OS. But it’s especially adapted to IoT devices by having a smaller memory footprint. It includes drivers for Wi-Fi, Bluetooth Low Energy, and other “Android things” according to their announcement. Any OS that includes all these features must be pretty large unless they use a modular approach. Even then, Android is pretty big so I suspect Brillo will be smaller, but not small. It’s not clear because there are few details at this time. What is clear is that Google wants to get access to the data like it does in Android smartphones. This strategy fits in with Google’s desire to capture, utilize, and sell the massive amounts of data coming through these devices.

My own company, Zeidman Technologies, has yet a different approach. Our SynthOS tool lets developers write code such that multitask scheduling and inter-task communications are done at an abstract level. The programmer writes the functional application code without any concern for the particular RTOS or the particular hardware. SynthOS examines the code, determines the relationships between tasks, the data structures required, the mutexes, semaphores, and message queues, and then writes a small, optimized RTOS that can be run on any processor, even an inexpensive, low-memory, low-power processor. This is similar to how programming language compilers hide the underlying mechanisms behind the stack, the heap, and all other low-level optimizations from programmers. Our strategy fits with changing market needs for ultra-low cost IoT hardware plus a changing requirement for greater programmer productivity.

Bob Zeidman is the president and founder of Zeidman Technologies where he invented the patented SynthOS program for automatically generating an application specific operating system (ASOS). Bob is the recipient of the 2010 and 2015 Outstanding Engineer in a Specialized Field from the IEEE Santa Clara Valley Section. SynthOS can be used online for free at www.SynthOSonline.com.