6 Trending Topics Every Embedded Learner Must Know in 2022
Tags: iot, embedded, learner, trends
Published: 2022-04-18 12:57:08

## Introduction

Embedded systems is a field where the associated technologies typically do not advance as fast as web technologies. This is a function of the constraints embedded systems have to deal with, including computational power, storage capacity, and connection speed among others. Such constraints are typically worked around through different architectural approaches. However, still in certain applications, the technology itself has to advance to reduce the effect of constraints or hardware bottlenecks. This is probably going to always remain as embedded systems are constrained by definition. Due to this effect, it is typical that certain trends in embedded systems tend to follow tech trends that have existed earlier in other fields but got adopted in some modified form or even optimized to deploy on embedded devices.

Ideally, a learner would capitalize on such trends by building a portfolio of projects, and thus demonstrate some experience, in any trend they find appealing. This would place the learner ahead of the curve setting them apart with unique opportunities when it comes to job placement purposes. ***Along with the trends I mention in this post, I also share a 50+ project idea list revolving around the below topics for learners to leverage. This will also be a live list that I will be updating regularly as more ideas come to mind. You can access the idea list by signing up for the newsletter [here](https://subscribepage.io/2BiaIf)***.

Without further ado, here are 6 topics currently trending in embedded systems:

### **1\.** TinyML 🤖
If you talk about machine learning (ML) nowadays, there's probably no guessing or question about whether it has a future or not. At least in non-embedded fields, there have been impressive applications that have been developed. It would only make sense that embedded systems adopt it as well as many applications such as automotive or industry 4.0 are in dire need of ML capabilities. Though what has also been known about ML is the amount of computational power required to both train and deploy models. As such, ML in embedded was a possibility early on due to system constraints. Potential workarounds included transmitting raw data and then processing models in the cloud. The issue with such an approach is that for power-constrained devices, the wireless component consumes significant power to transmit. This is additional to the latency involved in such an approach.

This is where TinyML comes in, since its emergence, TinyML's target was to offer ML edge capability to microcontroller devices that run on milliWatts of power. Essentially sitting at an intersection between the fields of IoT and ML. As such, TinyML offers four main advantages; less power consumption, reduced latency, enhanced privacy, and low bandwidth usage, all ideal for microcontroller IoT applications. There is no question that now with the existence of TinyML for embedded, the opportunities are endless for what can be achieved. Examples include predictive maintenance in manufacturing, smart structure health monitoring, and plant health monitoring among many others. Obviously, this is a field that is only bound to grow. For the interested, the [following post](https://towardsdatascience.com/tiny-machine-learning-the-next-ai-revolution-495c26463868) offers some digestible technical detail on how TinyML works. 

For those interested to know more, from a book perspective, right now there are only two books that I know of related to TinyML. The first is ["TinyML: Machine Learning with TensorFlow Lite on Arduino and Ultra-Low-Power Microcontrollers"](https://amzn.to/3uxXKFI) that offers a step-by-step guide to deploy TinyML models on microcontrollers and the second is ["TinyML Cookbook"](https://amzn.to/364pqZx) that offers over 50 recipes to deploy TinyML on the Arduino nano and Rasberry Pi pico. There is also a professional certificate offered by [Harvard University on edX for TinyML](https://tidd.ly/3vx4McX). Last but not least, it is worth looking into [Edge Impulse](https://www.edgeimpulse.com/), a company that offers a development platform for machine learning on edge devices that significantly eases the process of deploying ML models to microcontroller devices. Finally, [this](https://www.sciencedirect.com/science/article/pii/S1319157821003335) paper published only recently gives a great overview on TinyML state of the art and future prospects. 

### **2\.** Containerization 🧰
Containers started out as a solution in cloud environments where they provided a better and lighter-weight alternative compared to virtual machines. The idea from a container is that it packages code along with all its dependencies. This results in fully packaged code that can run the same as it's moved around regardless of the underlying infrastructure. Additionally, through a single container, one can package anything from a small microservice up to a large application. This has been revolutionary to many cloud environments as it managed to enhance the portability, deployment times, scalability, and security of software among other benefits.

Moving on to embedded, in the industry, many envision that in around 10 years, embedded development as we know it probably won't exist anymore. Instead, developers would be working on cloud containerized applications that they deploy as cloud extensions to embedded targets. This means that the embedded developer wouldn't really be concerned much about the underlying system and rather focused on features. Obviously, the industry would still require entities that are working on the underlying hardware to create the drivers and abstractions needed.

Still, at this point in time in the embedded industry, containers may be more applicable to certain areas than others. For example, containers in their original form are still a lot to handle for deployment on embedded targets, so some lighter-weight form needs to exist. Even at that point, in some cases, you'd still probably need a microcontroller with a certain level of performance to handle a containerized application. On the other hand, in a development environment, using containers to manage toolchains, toolkits, and testing should be a no-brainer and providers already exist. 

From what has been stated thus far, it becomes obvious that most of the opportunities would be in enabling containers for embedded targets. Currently companies like [pantacor](https://pantacor.com/), [BalenaOS](https://www.balena.io/os/), [Toradex](https://www.toradex.com/operating-systems/torizon-core), [Mender](https://mender.io/), and [Foundries](https://foundries.io/) all offer solutions for containers for Linux-based embedded targets. This means that these solutions cannot support all types of embedded targets as not all have the computational power to support the needed underlying infrastructure. Right now, there is at least still a couple of other promising solutions out there that can support a wider range of controllers and are lighter weight, and don't require a Linux environment. For one, there is [MicroEJ](https://www.microej.com/) that aims to transform electronic "things" into smart things like Android transformed phones into smartphones. Another really interesting effort out there is [Luos](https://www.luos.io/) that provides an open-source lightweight microservices solution for distributed embedded devices.

### **3\.** Security 🔐
Where embedded systems are right now relative to security has a similar feel to where the internet was in the 90s. Essentially, the internet started out as "a group of mutually trusting users", leaving security as an afterthought only for it to bite back later. As such, the internet was playing catch up with all the different types of attacks that kept on emerging. Looking at embedded systems, devices historically have been operating in isolation for quite a while and not much thought was given to security. Because of that, embedded solutions have been regularly adopting practices like leaving crucial memory content unencrypted and JTAG pins exposed, only to leave a vulnerability for an attacker to access crucial data. Later came IoT adding connectivity to embedded edge devices to open up Pandora's box. Come 2015, vehicles were loaded with embedded devices, and we have the infamous [Jeep hacking incident](https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/) triggering a [1.4 million vehicle recall](https://www.wired.com/2015/07/jeep-hack-chrysler-recalls-1-4m-vehicles-bug-fix/) by Chrysler. Essentially, this type of incident shows how much catch-up the embedded industry had to do in terms of security.

The good part is that a lot of good security practices have already been developed for web applications that could be adopted. Those practices probably are also mostly related to software and network attacks. Though there remain side-channel attacks that exploit hardware vulnerabilities by analyzing the power, timing, and electromagnetic signatures of devices to exploit them. 

Within the embedded industry, companies like ARM and Hex-Five are offering Trusted Execution Environments (TEE) for embedded architectures. ARM in particular offers its own [ARM TrustZone® technology](https://www.arm.com/technologies/trustzone-for-cortex-m) for Cortex-M devices. On the other hand, [Hex-Five](https://hex-five.com/) also supports RISC-V architectures. Additionally, there have been open-source hardware penetration testing tools like the  [chipwhisperer](https://www.newae.com/chipwhisperer) and [hydrabus](https://hydrabus.com/hydrabus-1-0-specifications/?v=60aea2edd110) to perform side-channel attacks for hardware penetration testing. A great list of software and hardware tools, frameworks, books, and more relative to embedded and IoT security can be found [here](https://project-awesome.org/fkie-cad/awesome-embedded-and-iot-security#tutorials-and-technical-background). 

### **4\.** RISC-V 💻
RISC-V (pronounced RISC five) is closer to the hardware trend that defines an open-source instruction set architecture (ISA) for processor cores. While there are many details, this is significant in two aspects; intellectual property (IP) rights and design flexibility. From an IP perspective, current popular ISAs like ARM and x86 are acquired by license. This costs companies significant money and also has them delve into legal matters relative to IP ownership. Especially for a startup, this is not necessarily a desirable setup.  Relative to design flexibility, with RISC-V, designers have the flexibility to extend the existing instruction set for a custom application or IP they create. Although this has changed a bit relative to ISAs like ARM, it's something not typically achievable with non-open source ISAs.

Since its inception, RISC-V has gained significant traction and developed a solid ecosystem. In 2015 the RISC-V foundation was established to build a collaborative community around RISC-V. Ever since, software tooling has become well established, additionally, companies like Microchip have emerged with microcontrollers and SoCs based on RISC-V. Other companies like [SiFive](https://www.sifive.com/) allow you to design your own custom IP and deploy it on an FPGA device. Another interesting effort is by [Western Digital](https://www.techtarget.com/searchstorage/news/252493477/Seagate-Western-Digital-outline-progress-on-RISC-V-designs) where in 2017 the company decided to invest heavily into RISC-V cores. Other interesting efforts to look into include the [PULP platform](https://pulp-platform.org/) for silicon-ready RISC-V microcontroller architectures, [Imperas](https://www.imperas.com/) for RISC-V ISA simulation, [Hex-Five](https://hex-five.com/) for trusted execution environments, and [Renode](https://renode.io/) an open-source simulator of SoCs created by [Antmicro](https://antmicro.com/technologies/risc-v/). This is just a sample of the significant efforts out there to drive the adoption of RISC-V. A full list of RISC-V foundation members driving a lot of these efforts can be found [here](https://riscv.org/members/).

### **5\.** Rust Programming 🦀
The embedded industry has struggled for a long time, and continues to, with software bugs. While the industry evolved over time, the struggle still exists. The issues can be attributed to several reasons, but the programming language in use is a key one. Rust is a programming language that was designed with safety at heart. In the creation of Rust, designers effectively summed up many of the reasons behind past software failures and designed a language that eliminates coding unsafe practices. Rust is a modern multi-paradigm compiled systems programming language that is memory safe, incredibly fast,   offers zero-cost abstractions, and is very portable, where for all these reasons and more make it a perfect fit for embedded systems. For the interested, I dig into more detail about this in my ["why you should be worried about the future of C/C++ in embedded: a case for rust"](https://apollolabsblog.hashnode.dev/why-you-should-be-worried-about-the-future-of-cc-in-embedded-a-case-for-rust) blog post. 

For cloud environments, companies like Amazon, Discord, Dropbox, Facebook, Google, and Microsoft have already adopted Rust in some form. In fact, Microsoft and Google already vouch for Rust helping eliminate up to 70% of their security issues in certain areas. In embedded there has been some adoption from companies like [Sensirion](https://sensirion-automotive.com/), [Airborne engineering](https://www.ael.co.uk/), [49Nord](https://49nord.de/en/), and [Terminal Technologies](https://www.termt.eu/). This is in addition to other companies that are starting to list Rust alongside C in job requirements.

In order to get started with Rust, there is a list of resources I captured in an earlier blog post [here](https://apollolabsblog.hashnode.dev/35-rust-learning-resources-every-beginner-should-know-in-2022). Additionally, to extend into Rust for embedded, there is the [awesome embedded Rust](https://github.com/rust-embedded/awesome-embedded-rust) git repo that provides a curated list of everything related to embedded Rust.

#### If you find this post useful, and if Embedded Rust interests you, stay in the know and skyrocket your learning curve by subscribing to The Embedded Rustacean newsletter:

{% cta  http://www.theembeddedrustacean.com %} Subscribe Now to The Embedded Rustacean{% endcta%} 

### **6\.** LPWAN 📡
This is closer to the hardware topic, as the wireless aspect of embedded has become increasingly important over the years. Wireless communication is crucial in providing connectivity in IoT applications like smart cities, smart manufacturing, healthcare, automotive, and others. There are even more interesting applications emerging where wireless technology is also being leveraged for detection and localization applications. However, wireless communication in embedded edge devices has historically been known to suffer in two main aspects; power consumption and coverage range. It is probably fair to say that for most edge devices, the wireless hardware is the most power-hungry especially in long transmission durations. Additionally, coverage distances have been a challenge as its directly related to power consumption. As such, wireless technologies that have been adapted to IoT over time typically would not achieve distances beyond hundreds of feet.

In recent times, Low-Power Wide-Area Networking (LPWAN) technologies have emerged targeting IoT, low power, battery-operated devices. Additionally, LPWAN technologies are expected to offer an extended range up to several kilometers, though at the expense of data throughput. Such technologies include LoRaWAN, Sigfox, NB-IoT, and Wi-Fi HaLow (802.11ah). Still, choosing the correct technology for wireless is a challenging feat for a device manufacturer or product developer. This is because the technologies are somewhat complicated to understand and offer very similar claims in meeting application requirements. This can become an issue as choosing the wrong technology could be costly so the designer has to really understand the differences.

Additional to LPWAN one it would be worth mentioning software-defined radio (SDR). With SDR, effectively the physical layer of a radio device can be programmed to achieve any radio function. This makes the radio much more portable and maintainable. SDR technology has significantly enhanced over the years. However, SDR is one of the technologies that has been slowed down by hardware RF associated technology mostly. While widespread integration of SDR into edge devices still needs time, the future looks really promising. [This](
https://www.ni.com/en-lb/innovations/white-papers/17/software-defined-radio--past--present--and-future.html) white paper by National Instruments gives a nice look into the possible future direction. 

## Conclusion
Operating under constrained environments, embedded systems tend to lag behind in technology adoption compared to areas such as the cloud. Driven by the somewhat recent introduction of IoT and thus connectivity, several topics are expected to take a prime position resulting in demand for expertise. For embedded learners wanting to increase their chances, it would be wise to pick one of these topics to expand their knowledge. Are there any other topics you feel are trending in embedded? Please share your thoughts in the comments. ***Also don't forget, you can access the list of 50+ ideas I put around the above topics by signing up for the newsletter [here](https://subscribepage.io/2BiaIf). ***

#### If you found this post useful, and if Embedded Rust interests you, stay in the know and skyrocket your learning curve by subscribing to The Embedded Rustacean newsletter:

{% cta  http://www.theembeddedrustacean.com %} Subscribe Now to The Embedded Rustacean{% endcta%}