July 2019: Security, Security, Security!

Welcome to the July 2019 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build superior embedded systems. This newsletter supplements the website and covers topics not mentioned there.

This month we'll cover:

  • Phillip's interview on
  • Atomic clocks in space
  • Stuxnet: ten years later
  • Embedded systems security resources
  • Embedded news from around the web
  • Updates to the Embedded Artistry Website Interview

Last month, interviewed Phillip. Elecia, Chris, and Phillip discussed consulting, writing, learning, code reviews, rules of thumb, Boeing 737 MAX, and implementing C++ threading types with an RTOS.

Check out episode 290!

Atomic Clocks in Space

We love learning about technological developments with space exploration, since they involve wonderful examples of highly reliable embedded systems.

In June, NASA’s Jet Propulsion Laboratory (JPL) announced that they were creating a deep-space atomic clock. This clock is a toaster-sized device that aims to facilitate navigational efforts for future space missions. The first clock was launched into Earth’s orbit at the end of June for a one-year trial.

You can learn more about the Deep Space Atomic Clock with these JPL links:

A Look at Stuxnet, Ten Years Later

June marked the 10th anniversary of the first Stuxnet infection, which targeted Siemens PLCs and was responsible for damaging Iran's nuclear program. Stuxnet caused centrifuges at the nuclear plant to spin out of control while operator screens reported nominal values, leading to systems failures, asset damage, safety concerns, and a national security fiasco.

It's interesting to look back on Stuxnet with the context of today's continual onslaught of security vulnerability announcements and IoT botnet attacks. What have we learned in the ten years since Stuxnet demonstrated the capability of vulnerabilities to wreak havoc on physical systems? The overall state of device security hasn't noticeably improved, and reports of hacked devices reaching into the physical world abound.

Security can no longer be an afterthought. Even if your product isn’t connected to a nuclear reactor, vulnerabilities are exploited with disastrous results. For more on Stuxnet:

For more on Stuxnet:

Embedded Systems Security Resources

A reader reached out to us on LinkedIn and requested recommendations for books and resources discussing embedded systems security. As we just mentioned, security is an area that we all need to focus on when we design and build our embedded systems. If you have recommended books or links that discuss embedded systems security, let us know! We will be collecting recommendations and publishing a post dedicated to security resources. Here’s what we’ve collected thus far.

Phil Koopman has a collection of lectures discussing embedded systems security:

The following books relate to embedded systems security:

Here are articles with general introductions to embedded systems security concepts:

These articles focus on common pitfalls with embedded device security:

Around the Web

We've grouped our July reading recommendations by these categories:

  • General
  • Software
  • Security
  • Hardware


Elecia at wrote a great post about Giving Feedback prompted by our conversation on the podcast.

Bunnie comments on the trade war with China and its potential impact on Open Source Could Be a Casualty of the Trade War.

All About Circuits published a helpful introduction to the Advanced Microcontroller Bus Architecture (AMBA), which is the de facto standard for SoC design.


If you're interested in the intersection of machine learning and embedded systems, a reader on LinkedIn shared this link for running TensorFlow Lite on a microcontroller.

The Memfault team published an excellent article on digging into firmware code size. If you're trying to reduce your binary's size, this article is a must read.

The Memfault team also published an excellent article on writing linker scripts for firmware.

Colin Walls wrote about mixing C and C++ in an embedded application. If you're interested in trying out C++ on an existing embedded product, try one of Colin's two approaches.

Burkhard Stubert added another article to his Speaking CAN series, this time analyzing write buffer overflows.

Watchdog timers are a staple element of embedded systems. Alexandru Lazar shared some Watchdog Timer Anti-patterns that we should keep in mind when building our systems.

Thread Group announced version 1.2 of the Thread wireless protocol. Stacey Higginbotham provided a summary of the changes

For a great example of applying std::variant to create a state machine, check out this C++ article: Space Game: A std::variant-Based State Machine by Example.


Appropriately for the 10-year anniversary of Stuxnet, we saw an inordinate amount of articles related to security.

EE Times highlighted that the IoT security gap is widening: we're adding more devices and sending more data, but IoT devices are still a prime hacking target.

Designing Hardware for Data Privacy highlights the need to develop a thread model for our devices and to implement the appropriate countermeasures.

Enhancing Privacy and Security in the Smart Meter Lifecycle provides a look at a variety of techniques that can be used to improve IoT device security.

How Many Layers of Security Do You Have? argues that designers should consider two guiding principles: defense in depth and principle of least privilege.

Will the Real Root of Trust Stand Up? discusses the concept of a "root of trust".


Strange Parts recorded a fantastic factory tour of the PCBWay factory in Shenzen: Inside a PCB Soldering Factory - in China. If you are curious about how circuit boards are manufactured, check out this video.

Dangerous Prototypes shared a helpful app note discussing magnetometer placement in mobile devices.

Dangerous Prototypes also shared a helpful app note discussing a method for using two accelerometers to make rotational measurements, which is useful if you already have two accelerometers and don't want to update your product to add a gyroscope.

Hiring Embedded Engineers?

Is your company hiring embedded systems hardware/software engineers? Send us a short job ad with a link to the full job description. We will be happy to include it in our newsletter.

Website Updates

Stickers are now available in the Embedded Artistry store. You can help support the website by purchasing a sticker.

We've renamed the "Embedded C++" and "Migrating from C to C++" categories to work around a Squarespace link generation issue.

We added additional acronyms to the Glossary.

We added new book recommendations and links to For Beginners, Hardware References and Software References.

We updated the following articles:

New Articles

We published the following articles in June:

These were our most popular articles in June:

  1. Creating a Circular Buffer in C/C++
  2. For Beginners
  3. std::string vs C-strings
  4. Demystifying Microcontroller GPIO Settings
  5. Installing LLVM/Clang on OSX
  6. C++ Casting, or: "Oh No, They Broke Malloc!"
  7. Improving Your Callback Game
  8. Jenkins: Configuring a Linux Slave Node
  9. An Overview of C++ STL Containers
  10. Migrating from C to C++: NULL vs nullptr

Thanks for Reading!

Have any feedback, questions, suggestions, interesting articles, or resources to recommend to other developers? Simply reply to this email!

While you're waiting for our next edition, check out the website or follow us on Twitter.

Happy hacking!

-Phillip & Rozi

November 2018: The Big Hack

Welcome to the November 2018 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build superior embedded systems. This newsletter supplements the website and covers topics not mentioned there.

This month we'll cover:

  • The Big Hack story and its ensuing drama
  • A request for modern Embedded Linux resources
  • Embedded articles from around the web
  • Website updates

The Big Hack

At the beginning of this month, Bloomberg dropped a bomb by publishing "The Big Hack: How China Used a Tiny Chip to Infiltrate America's Top Companies". They followed the initial story with details about the software side of the attack. The Bloomberg article is a thrilling and dramatic read which has stirred up quite a bit of controversy.

If you haven't read the original story, here's a brief summary:

Between 2014-2015, Supermicro server motherboards had a small IC inserted onto the PCB, supposedly connected to the baseboard management controller (BMC). The chip allowed attackers to alter “the server’s Core OS so it could accept modifications and contact attacker-controlled computers for further instructions/code”. Supermicro subcontractors installed these chips at the behest of the People’s Liberation Army (PLA) of China. The software side of the picture involves two vectors: shipping Supermicro servers with outdated firmware that contained known security vulnerabilities, and releasing firmware updates with new vulnerabilities which would be installed after the boards were already in customers’ hands.

Unsurprisingly, the story has been vehemently denied by all parties involved:

Bloomberg was transparent about the companies' denials and published them on their website. Bloomberg then doubled down on the Big Hack by publishing a follow-up article stating that new evidence of hacked Supermicro hardware was found in a (unnamed) US telecom. Unlike the "tiny chip" on the motherboard, the reported hack involved an implant built into the Ethernet connector.

The Big Hack and the ensuing wave of denials have read like a fictional spy thriller. Following the commentary surrounding the story has been fun and enlightening:

  • Joe FitzPatrick at Securing Hardware, one of the sources named in the story, shared his thoughts around hardware implants, how he'd execute such an attack, and how compromising the BMC firmware would be a much simpler approach than implementing the hardware hack.
  • Bloomberg published the story a month after the NASDAQ delisted Supermicro.
  • Supermicro shares plunged ~50% following the first announcement.
    • 20+ people made suspicious short positions and sale orders just before the story broke, leading to calls for an SEC investigations and suspicion that this is a Supermicro hit piece.
  • Matt Levine speculated on whether securities fraud would apply if companies falsely denied the story.
  • Risky Business published a podcast digging into the story and interviewed Joe FitzPatrick, who said he feels “uneasy” about the story as published.
    • Interestingly, Vice states that Joe FitzPatrick "told Motherboard in an online chat he was 'not surprised to see an example finally.'" This is an odd statement for someone claiming the story made them feel uneasy.
  • Serve the Home analyzed the story and the BMC theory.
  • Vice dug into supply chain vulnerabilities and included this interesting quote:
    • “There are two possible stories here,” Matthew Green, associate professor at Johns Hopkins University, tweeted about the attack. “One is that there was an attack. The other is that a large swath of the National Security establishment is promoting the idea that there was an attack. Pick your poison.”
  • Sup China takes a similar tack as Matthew Green and postulates that government sources may be trying to generate or amply mistrust of China.
  • One Bloomberg opinion piece relates the hack to the growing conflicts between the US and China. Another opinion piece postulates on how hopelessly vulnerable global supply chains are - further stirring the pot in regards to China's business practices.

Now that a month has passed, we seem to be at an impasse. The lack of evidence of hacked hardware, a list of affected SKUs, or confirmation by other agencies casts doubt on Bloomberg’s story. The companies named continue to deny the story, and Bloomberg will not make a retraction, name sources, or provide further details. Other news agencies have been unable to independently confirm the story.

Regardless of whether the story is true or false, it highlights the vulnerability of our modern technological supply chains. I published my musings on modern supply chains and the feasibility of hardware tampering on the website.

A Request for Modern Embedded Linux Resources

I've received emails asking for recommendations for up-to-date Embedded Linux resources. We primarily focus on writing software for microcontrollers, so I have little experience with Embedded Linux. Most of the reference material that I've seen is at least a decade old or focuses on Raspberry Pi development using python libraries.

If you're an Embedded Linux developer who writes drivers or other low-level code, I'd love to hear about your favorite books, websites, and courses. Where do you turn to when you have a problem? What training do you take to improve your skills? What tools do you use most often?

You can respond directly to this email or send us a message on Twitter.

Around the Web

Another day, another security flaw announcement, this time for Amazon FreeRTOS.

Phil Koopman highlighted the cost of producing highly safety-critical software.

In the December 2017 edition of the newsletter we covered advances in chip design techniques. Read this IEEE article for another new chip design technique: Through-Silicon Transistors Could Make Stacking Chips Smarter.

Meeting Embedded shared a short interview with Dan Saks, a champion of embedded C++ development.

Mohammad Afaneh at Novel Bits continued publishing his Bluetooth Mesh tutorial series:

Jack Ganssle finished publishing "Top 10 Reasons Embedded Projects Get Into Trouble". He finished his serious with two of the most common problems I see: "Quality Gets Lip Service" and "Unrealistic Schedules".

Website Updates

The Glossary received another extensive update focused on manufacturing and supply chain terminology.

We updated our Technology Radar to include the Espressif ESP32 chipset. Saket Vora introduced us to this chip, which features 512kB SRAM, qSPI supporting 16Mbit external flash, low deep sleep current, and a superb datasheet. We're evaluating it for use with our embedded framework.

New Articles

We published the following articles in October:

We also updated the following articles with new content:

These were our most popular articles in October:

  1. Circular Buffers in C/C++
  2. Jenkins: Configuring a Linux Slave Node
  3. Installing LLVM/Clang on OSX
  4. std::string vs C-strings
  5. C++ Casting, or: "Oh No, They Broke Malloc!"
  6. An Overview of C++ STL Containers
  7. Jenkins: Running Steps as sudo
  8. Jenkins: Kick off a CI Build with GitHub Push Notifications
  9. Migrating from C to C++: NULL vs nullptr
  10. Implementing Malloc: First-fit Free List

Thanks for Reading!

Have any feedback, questions, suggestions, interesting articles, or resources to recommend to other developers? Simply reply to this email!

While you're waiting for our next email, check out the website or follow us on Twitter.

Happy hacking!


August 2018: Spectre Returns, Freestanding C++, Technology Radar

Welcome to the August 2018 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build superior embedded systems. This newsletter is intended to supplement the website and covers topics not mentioned there.

This month we'll cover:

  • More Speculative Execution attacks: SpectreRSB and NetSpectre
  • The new version of the Freestanding C++ proposal
  • The Embedded Artistry Technology Radar
  • Interesting links from around the web
  • Embedded Artistry website updates and popular posts

Speculative Execution Attacks

Earlier this year we covered Spectre and Meltdown, two speculative execution vulnerabilities that affect a majority of the world's processors. In June, there was another announcement regarding an Intel speculative execution vulnerability dubbed lazy floating-point state restore.

The trend continues, and two more speculative execution attack vectors have come to light in the past few weeks:

  • SpectreRSB, which exploits speculative execution of the return stack buffer
  • NetSpectre, a remote attack which does not require attacker-controlled code to run on the victim's machine

Exploring these speculative execution vulnerabilities is a great way for embedded developers to learn the details about how processors work.


SpectreRSB is a speculative execution vulnerability which exploits the return stack buffer (RSB). The RSB is a structure similar to the branch predictor which is used to predict return addresses. When a call instruction is issued, the RSB pushes the return address onto an internal hardware stack.

SpectreRSB has six variants, but the basic flow is as follows:

  1. Context switch to the attacker:
    • The attacker flushes shared address entries (i.e. flush reload)
    • The attacker pollutes the RSB with the target address of a payload gadget in the victim’s address space
  2. The attacker yields the CPU back to the victim
  3. The victim eventually executes a return
    • Speculative execution occurs at the address which the attacker injected into RSB
  4. Control switches back to the attacker, data is leaked

The authors of the paper claim that the existing mitigations against Spectre variant 1 do not protect against SpectreRSB. Intel claims that SpectreRSB is related to branch target injections which have already been mitigated. On some processors, an RSB refilling patch is available that interferes with SpectreRSB’s attack mechanism.

Intel, AMD, and ARM processors are affected, as they all utilize RSBs to predict return addresses.

More on SpectreRSB:


The NetSpectre vulnerability is related to Spectre variant 1 in that it uses speculative execution to perform bounds-check bypass. NetSpectre can be used to defeat address-space layout randomization on a remote system.

Unlike other Spectre variants, NetSpectre does not require a victim to download and run malicious code their machine. Instead NetSpectre only requires the victim to have an active network connection. NetSpectre variations are currently too slow to be valuable to attackers, with exfiltration speeds between 15 and 60 bits/hr. Even if the attack vector is not currently usable, it demonstrates that Spectre is not simply a local vulnerability.

It’s reported that all CPUs affected by the Spectre variant 1 are also affected by NetSpectre, therefore existing vendor mitigations should be enough to protect against it. These mitigations require firmware and OS updates, so unpatched devices remain vulnerable.

More on NetSpectre:

New Freestanding C++ Proposal

In the June 2018 Newsletter, we mentioned the C++ standards proposal to support a "Freestanding" C++ language subset which is suitable for use without an underlying operating system.

A new version of the Freestanding proposal has been released: P1105R0: Leaving no room for a lower-level language: A C++ Subset.

The primary goal of the proposal is to make core language features (such as exceptions, RTTI, and thread local storage) optional if they have an OS dependency or incur storage space overhead. This would better-enable C++ to support the embedded systems and kernel programming communities.

For more on Freestanding C++:

Embedded Artistry's Technology Radar

I was introduced to the Technology Radar concept while at Bredemeyer Consulting's Software Architecture Workshop. The Technology Radar concept was created by ThoughtWorks, and they regularly publish updates to their own radar.

I immediately latched onto the concept as a way to keep track of the technologies and techniques that we are investigating at Embedded Artistry. The technology radar also helps us document the solutions that we recommend others adopt.

We’ve identified four categories that we plan to explore as an embedded systems consulting firm:

  1. Tools
  2. Libraries and Frameworks
  3. Platforms (both hardware and RTOS)
  4. Techniques

We've released the first-draft of our technology radar and will update it on an ongoing basis.

You can find our Technology Radar on the website under the Resources menu.

For more on technology radars:

Around the Web

IT Hare has published another article on (Re)Actors: CAS (Re)Actor for Non-Blocking Multithreaded Primitives.

An amusing RISC-V smear campaign by ARM has brought a lot of public attention to the RISC-V architecture. If you're unfamiliar with RISC-V, check out this IEEE article: RISC-V's Open-Source Architecture Shakes Up Chip Design. You can learn more on the RISC-V Foundation website.

Segger, who produces the J-Link and J-Trace tools, has announced their own C-based embedded OS called emPack. In addition to an operating system, Segger is also providing emPack plugins for GUI, File System, TCP/IP, USB-Device, USB-Host, and more.

Website Updates

We've launched a Store page, where we will be adding templates and informational products that embedded teams can leverage. Both free downloads and paid downloads are in the Store.

We've created a Support page which will stay updated with the ways you can support the website.

We updated the following blog posts this month:

Our Glossary is always expanding and has been updated with a plethora of new terms.

As mentioned we added a link to the Embedded Artistry Technology Radar under the Resources menu.

New Articles

These articles were published on our website in July:

These were our most popular articles in July:

  1. Circular Buffers in C/C++
  2. Jenkins: Configuring a Linux Slave Node
  3. Installing LLVM/Clang on OSX
  4. std::string vs C-strings
  5. Jenkins: Running Steps as sudo
  6. An Overview of C++ STL Containers
  7. Implementing an Asynchronous Dispatch Queue
  8. A Simple Consulting Services Agreement
  9. Creating and Enforcing a Code Formatting Standard with clang-format
  10. Demystifying ARM Floating-Point Compiler Options

Thanks for Reading!

Have any feedback, questions, suggestions, interesting articles, or resources to recommend to other developers? Simply reply to this email!

While you wait on the next edition, check out the website or follow us on Twitter.

Happy hacking!


November 2017

Welcome to the November 2017 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build better embedded systems. This newsletter is intended to supplement the website and covers topics not mentioned there.

This month we'll be covering:

  • The recently announced vulnerability in the WPA2 algorithm
  • Industry standard APIs to make multi-core programming more accessible
  • The EMB² multicore programming framework
  • The recently announced ARM Platform Security Architecture
  • "The Coming Software Apocalypse"

WPA2 Vulnerability: Key Reinstallation Attacks

A serious flaw in the WPA2 security algorithm, which protects our Wifi networks, was announced this month. The attack vectors is dubbed KRACK for "Key Reinstallation Attack." The KRACK vector exploits a flaw in the WPA2 algorithm itself. Any correct implementation is likely to be affected. By exploiting the 4-away handshake protocol used to exchange encryption keys, a third-party can collect and replay the key installation message. This vulnerability enables packet replays, packet forgery, packet decryption, or man-in-the-middle attacks.

Stay alert and update your devices as soon as updates are available. Do not switch back to the less-secure WEP security protocol: once this flaw is patched, WPA2 will remain secure. If you are building or supporting a Wifi-enabled device, check with your chip or SDK vendors for updates and timelines.

More on the KRACK attack vector:

Industry Standard Multicore APIs

Multicore embedded systems are becoming increasingly popular. However, writing programs to use multicore processors effectively is a challenge. The Multicore Association (MCA) aims to improve the adoption of multicore programming by defining and promoting specifications that better enable multicore product development. If you are writing software destined for a multicore embedded system, consider using these APIs to keep your software portable and abstracted from underlying architectures.

The MCA currently defines three multicore APIs, covering task management (MTAPI), resource management (MRAPI), and communication and synchronization between cores (MCAPI).

The aim of the Multicore Task Management API (MTAPI) is to create a standardized API for task-parallel programming on a wide range of hardware architectures. Manually creating and managing threads can be complex, error-prone, and depends on your operating system and hardware. MTAPI abstracts hardware and operating system details and allows programmers to focus on the parallel programming solution. There are no compiler, hardware, or operating system dependencies, and the API is written in C to minimize ABI interoperability problems. The API can be implemented on resource-limited devices and covers a variety of multicore architectures and hardware acceleration units. Task scheduling can be optimized for latency and fairness, enabling its use on systems with soft real-time requirements.

The Multicore Resource Management API (MRAPI) specifies application-level resource management capabilities. This API allows multicore applications to coordinate concurrent access to various system resources.

The Multicore Communications API (MCAPI) defines an API and semantics for communicating and synchronizing processing cores in embedded systems. MCAPI is a message-passing API that is designed for closely-distributed systems (e.g. multiple cores on a single chip, multiple chips on a single board). The API is kept simple to support sufficient functionality while allowing efficient implementations for resource constrained systems.

More information on the MCA standards:

Multicore Framework: Embedded Multicore Building Blocks

Embedded Multicore Building Blocks (EMB²) is an open-source C/C++ library for developing parallel embedded systems applications. EMB² is built on the Multicore Task Management API that we reviewed in the previous section.

EMB² provides generic building blocks for building parallel embedded applications, including basic parallel algorithms, concurrent data structures, and application skeletons. The majority of the framework APIs are non-blocking, avoiding common multi-threaded problems encountered when using locks.The framework utilizes an abstraction layer that makes it easily ported to new operating systems and processor architectures.

EMB² is implemented as a C API with C++ wrappers. The project is based on C99 and C++03 to provide maximum usability in the embedded world. C11 and C++11 can be selected for use of the standard atomic operations instead of the EMB² atomics.

My favorite aspect about this project is the emphasis on quality: the project maintains zero compiler warnings, sports 90% unit test coverage, utilizes static analysis and automated rule checks, and has formally validated pieces of the system. It's refreshing to find a team that cares about quality!

If you're looking for a simple framework to get started with multicore embedded development, check out EMB²:

The ARM Platform Security Architecture

As the news frequently highlights, inadequate security implementations on embedded systems is a major problem. Last September, ARM announced their intentions to work on a platform security architecture to help combat this threat. based on announcements this month, it looks like ARM is delivering on their promise.

Dubbed the Platform Security Architecture (PSA), ARM is focusing on three major components:

  1. Threat Models and Security Analyses derived from a range of typical IoT use cases
  2. Architecture specifications for firmware and hardware
  3. An open source project similar to Arm Trusted Firmware

The PSA is targeted for smaller cores and low-cost devices. Sensitive assets, such as keys and credentials, will be managed by a Secure Processing Environment (SPE) and will be separated from the application firmware.

In addition to the PSA, ARM has announced two new security-related cores. The CryptoIsland-300 is a programmable security core which expands upon the CryptoCell that they announced last year. The SDC-600 is a secure debugging channel that will allow users to enable or disable debugging abilities by using a cryptographic certificate.

The PSA is initially targeted for Cortex-M devices and will include open-source implementation examples. The PSA release is expected in Q1 of 2018. Support for Cortex-R and Cortex-A devices will follow after Cortex-M.

More on the ARM PSA:

The Coming Software Apocalypse

The Atlantic recently published an article titled "The Coming Software Apocalypse". Our world is becoming increasingly digitized and we are encountering more and more flaws in the software we depend on. Even our cars, which were primarily mechanical systems once upon a time, are now comprised of 100 million lines of code. The article dives into some of the challenges involved with the increase in software complexity, primarily focusing on limitations in our intellectual management of large software project. Following this premise, the author advocates increased emphasis on using tools during the development process. Software should be modeled before any code is written, algorithms should be checked with formal methods or tools such as TLA+, and code generators should be used to reduce programmer errors.

I later stumbled across a response to The Atlantic's article titled "Tools are not the Answer". The author of this post emphasizes a point which I wholeheartedly agree with: tools are helpful, but not the complete answer. Programmers must hold themselves to higher standards.

The rebuttal emphasizes that our software woes primarily stem from two causes:

  1. Too many programmers take sloppy short-cuts under schedule pressure.
  2. Too many other programmers think it’s fine, and provide cover.

And the obvious solution:

  1. Raise the level of software discipline and professionalism.
  2. Never make excuses for sloppy work.

This is not to say that tools won't help: our software is still becoming increasingly complex and difficult to manage. We must improve our development processes and hold ourselves to higher standards.

Read more here:

Selected Quotes from the Articles

“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”

This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”

The software did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing.

Take error handling and correction seriously in your designs:

But, as described in a report to the FCC, “the situation occurred at a point in the application logic that was not designed to perform any automated corrective actions.”

We already know how to make complex software reliable, but in so many places, we’re choosing not to. Why?

I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” > Not one in twenty raised their hands.

Website Updates

I added additional C++ references to the Software References page. I also expanded the Glossary with additional terms and an improved organizational scheme.

These were the most popular articles in October:

  1. Circular Buffers in C/C++
  2. Installing LLVM/Clang on OSX
  3. Implementing Malloc: First-fit Free List
  4. std::string vs C-strings
  5. An Overview of C++ STL Containers

Thanks for Reading!

Have any feedback, suggestions, interesting articles, or resources to recommend to other developers? Respond to this email and let me know!

Happy hacking!


October 2017

Welcome to the October 2017 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build better embedded systems. This newsletter is intended to supplement the website and covers topics not mentioned there.

This month we'll be covering:

  • The BlueBorne Bluetooth vulnerability
  • DARPA funds embedded initiatives
  • A helpful introductory RTOS series
  • Amazon launches an FPGA cloud
  • A terrible security flaw discovered in pacemakers
  • Limiting the number of characters printf displays

The BlueBorne Bluetooth Vulnerability

Armis Labs recently announced a series of eight attack vectors that endanger the majority of our Bluetooth devices, including Android, iOS (pre-10.0), Windows, and Linux. The threat is dubbed "BlueBorne", a blend between Bluetooth and airborne. Affected devices are vulnerable to BlueBorne as long as Bluetooth is enabled, even if the device is not discoverable and not paired to the attacker's device. BlueBorne does not require any action to be completed by the user, and the user may never know his device has been compromised. The disclosed vulnerabilities are fully operational and enable a variety of attacks, such as arbitrary code execution, man-in-the-middle, and information leakage.

Bluetooth is a nearly ubiquitous technology and Armis estimates that over 8.2 billion devices may already be affected. Popular libraries like BlueZ which is used on a variety of PC and embedded systems are compromised. It is recommended to turn off Bluetooth when you are not using it until the vulnerabilities have been addressed. Ensure your software is up-to-date and keep an eye out for software updates on your Bluetooth-enabled systems. If you are building a Bluetooth-enabled system, review the technical paper and ensure that your design is not suspect to the disclosed vulnerabilities.

For more on BlueBorne:

DARPA Funds Embedded Initiatives

DARPA has announced that it is providing funding for six new programs with an embedded focus. DARPA is focusing the new initiatives on researching new materials and integration techniques, improving circuit design tools, and creating new system architectures for microelectronics. The programs that sound the most exciting are in the Materials and Integration category: "Three-dimensional Monolithic System-on-a-chip" (3DSoC) and "Foundations Required for Novel Compute" (FRANC).

3DSoC is aimed at improving speeds and reducing power consumption by transitioning from a 2D circuit layout to a 3D circuit layout. By constructing microelectronic circuits in 3D space (e.g. in a cube) we can create novel design strategies and arrangements for our circuits and chips. Migrating to a 3D circuit arrangement is expected to improve logic density, increase computational speed, optimize for size, and reduce power.

FRANC is looking to overturn John von Neumann's computer architecture model which separates the memory and processing blocks. Computations are often limited by the speed at which data can be moved back-and-forth between the processor and memory. As a result, memory transfer speeds are a major bottleneck in many systems. FRANC's aim is to address this bottleneck by developing a new method for handling memory and logic in a combined manner.

It's exciting to see DARPA inducing major changes in our microelectronic circuits and system architectures. Innovations like these will have a significant impact on our industry in the coming decades.

More on DARPA's new initiatives:

An Introductory RTOS Series

The embedded guru Colin Walls has been working on a series called RTOS Revealed. This series of articles is a great way to learn more about real-time and OS concepts, multi-threaded scheduling, and how to use an RTOS. Colin covers basic RTOS concepts and dives into the Nucleus SE RTOS to provide concrete examples. I recommend reviewing the entire series if you are new to the embedded systems space.

Here's the current lineup of articles:

New articles in the series are released on a monthly cadence.

Amazon Launches an FPGA Cloud

Xilinx and Amazon have partnered to launch customizable FPGA instances in the AWS Cloud for applications that can benefit from hardware acceleration. These instances are built on the Xilinx Virtex UltraScale+ FPGAs and can include up to eight FPGAs per instance. Amazon also provides an FPGA Hardware Developer Kit (HDK) to simplify development of FPGA instances.

A Terrible Flaw Discovered in Pacemakers

465,000 U.S. patients have been told to visit a clinic to receive a firmware update for their St. Jude pacemakers. The firmware contains a security flaw which allows hackers within radio range to take control of a pacemaker. This is one more example demonstrating that security must be a crucial aspect of embedded systems design and development. Taking security shortcuts never pays.

Limiting the Number of Characters printf Displays

I originally hesitated about sharing this tip, but I've found myself repeatedly it: You can control how many characters printf spits out for the %s symbol by specifying a precision.

There are two options for controlling the length. You can specify the maximum using a fixed value:

// Fixed precision in the format string
const char * mystr = "This string is definitely longer than what we want to print.";
printf("Here are first 5 chars only: %.5s\n", mystr);

You can also control the length programmatically by using an asterisk (*) in the format string instead of the length. The length is then specified as an argument and is placed ahead of the string you want to print.

// Only 5 characters printed. When using %.*s, add an argument to specify the length before your string
printf("Here are the first 5 characters: %.*s\n", 5, mystr);

Website Updates

This month, the website went through a total visual redesign!

Old pages such as "Around the Web" have been split out into separate pages to provide better categorization:

I've also added some new pages in the "About" section:

These were the most popular articles in September:

  1. Installing Clang/LLVM on OSX
  2. Circular Buffers in C/C++
  3. C++11 Fixed Point Arithmetic Library
  4. An Overview of C++ STL Containers
  5. std::string vs C-strings

Goodbye to a Dear Friend

We lost our dear companion and beloved mascot Jensen to stomach cancer. She will be sorely missed.


Thanks for Reading!

Have any feedback, suggestions, interesting articles, or resources to recommend to other developers? Respond to this email and let me know!