3 Benefits of Embedded Linux in IoT Development

The ability to use the same Linux source code across multiple applications makes Linux the operating system of choice for the development and integration of Linux and IoT.
A Linux developer works on a laptop in an open office environment

Embedded development is much different than desktop application development. Embedded servers and sensor interfaces may not offer the same easy access to hardwired ethernet, Wi-Fi and Bluetooth that traditional computers do. But the ability to use the same Linux source code across multiple applications makes Linux the operating system of choice for the development and integration of Linux and IoT.

Embedded Linux and IoT in 3 Parts

To illustrate how embedded Linux and IoT are integrated, let’s look at an agricultural example. In this example, we have a system of three computers used for IoT control and acquisition. This system is designed to monitor water, humidity and temperature for agriculture purposes.

1. Desktop Computer

Part 1 is a desktop computer running Linux.

It has two functions:

  1. To control the recording interval for farm field sensor input.
  2. To record and format data into reports that monitor irrigation systems control and performance, ensuring the irrigation systems only run when needed due to a predetermined interval of low humidity and warm temperatures.

This computer has an Intel/AMD 64-bit processor, 16 GB RAM and several USB 3.0 ports and would be considered a typical desktop system by today’s standards.

2. Embedded Server

Part 2 is an ARM 64-bit quad-core system that boots Linux from a microSD card and has 2 GB of eMMC memory, 4 USB 2.0 ports, an HDMI port, Wi-Fi and Bluetooth 5.2 LE, and a 1 GB Ethernet port. It is connected to a wireless router via Wi-Fi and communicates with the desktop, which is 20 miles away and is connected to a hard-wired internet connection.

This embedded Linux unit gets updates to the operating system and applications via microSD card or Wi-Fi. This computer is a small embedded Linux server that manages reading the field sensors, updates the sensor’s firmware and communicates with the office server to manage, control and report field conditions and sensor data.

3. Sensor Interface and Controller

Part 3 is a postage-stamp-sized Linux system that is programmed at the factory and has temperature and humidity sensors. It has 1 GB of eMMC memory and boots from a microSD card. This device is a single-core ARM processor with one USB port, Wi-Fi and Bluetooth.

Unlike other operating systems, Linux is fully scalable, which means it can run on IBM sx390 mainframes, as well as small credit-card-sized computers, like the ASUS Tinkerboard or Raspberry Pi. Linux supports a wide variety of processor architectures and configurations. As shown in the example, this embedded network is made up of multi-core processors from Intel and ARM, in addition to a single-core processor for sensor control and data collection.

The Benefits of Embedded Linux in IoT Development

As you can see, this configuration uses a variety of communications protocols and topologies. Embedded development is much different than desktop application development. Hardwired ethernet, Wi-Fi and Bluetooth are built into laptops and desktops but are not as readily available for embedded development.

So, one benefit of using Linux would be the availability of common network topologies and protocols. By choosing embedded hardware carefully, you can use the same components throughout the network and not worry about the processor architecture. Then, you can focus on building a version of Linux that uses the drivers for the network and communications protocols you need and ensuring consistent versions across all the computers.

Next, consider testing. How do we test drivers and applications across two or three processor architectures? Another benefit of using Linux is the common development and debugging tools.

In this example, the company that provides the development platforms, compilers, editors, debuggers and code analyzers can use the same tools across any Linux-supported architecture. Everything that is used on the desktop is also available for the embedded server and sensor interface and controller.

And requiring the use of open source software means that, as a worst-case scenario, the tools would need to be compiled, taking an additional hour or two to prepare the development platform. The same is true for debuggers and code performance analyzers, so the cost of development software is the time invested in downloading and possibly building these tools. In comparison, purchasing these tools from third-party sources could cost tens of thousands of dollars.

With Linux, you also have the benefit of consolidated development servers. Developers can consolidate all development and debugging on a single server or desktop system in the lab. This means that the code can be developed, cross-targeted for each different processor architecture and debugged by deploying the applications to their native target, all from one machine.

Developing and Debugging for Multiple Architectures

Using Linux-supported cross-compilers to develop embedded Linux applications for multiple platforms is a big cost-savings factor. Without Linux, this process is extremely time-consuming and difficult.

First, you had to develop your C/C++ source code on the machine, compile it and then debug it. Next, you had to move the source code to another platform and start the same process all over again.

Just how Linux standardization allows for the same source code to be built on numerous platforms, the same process can be used for cross-targeting applications. The same tools, compilers and debuggers are used for cross-platform application development and for Linux. What is not used are tools like Buildroot and Yocto, which were designed specifically for building custom Linux systems for any supported processor architecture, although Yocto is designed for custom application porting as well.

So, the process is pretty straightforward. Eclipse is a tool for editing and building kernels, drivers and applications. Developers install the compilers and tools for each supported platform, set the proper compiler flags in the Eclipse environment and then compile.

To debug, the programs are deployed to a shared directory on each targeted platform, and the GNU debugger (GDB) is set up to attach to the target machine prior to program execution. Then, when the program is executed, single step C or C++ source code debugging can be done by simply setting breakpoints in the code, just as a developer would for a locally debugged program.

Debugging Across Multiple Architectures at the Same Time

In an IoT development environment, such as the one defined here, it is possible to run more than one instance of the GDB application, allowing the use of the same system for both development and debugging all architectures at the same time. Therefore, communications applications and protocols can be changed, compiled, debugged and tuned all while running GDB from one keyboard and monitor. This is also true of Linux, the Linux kernel, and kernel and user space device drivers.

These features translate into serious time and cost savings in a real-world development environment. With cross-platform development on Linux, we have the ability to quickly change, debug and tune applications for combined desktop, embedded server and Linux-based IoT sensor clients.

Before this, embedded hardware costs were inexpensive, but software development and distribution costs were many times what they are today. The open-source approach has allowed software development to become more cost effective, reducing software development costs without penalizing the skilled developers and using processes and techniques not available in closed-source operating systems.

Get the skills you need for an open-source approach with CompTIA Linux+. Download the exam objectives to see what the certification covers.

Email us at [email protected] for inquiries related to contributed articles, link building and other web content needs.

Read More from the CompTIA Blog

Leave a Comment