Welcome to the June 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:
- Programming vs engineering
- Report CI
- Embedded news from around the web
- Updates to the Embedded Artistry Website
We also want to share some exciting news with you! One of our articles was published in the June 2019 issue of the Software Quality Professional Journal. You can read The Boeing 737 MAX Saga: Lessons for Software Organizations for free if you register for an account with ASQ. Or you can email us and we will send you a copy.
Programmer vs Engineer
The article begins by highlighting the use of "engineer" for programming roles:
What's wrong with programmers co-opting the term "engineer"? The article points out that:
Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education. Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver.
The fact that programmers don't have a similar set of responsibilities is alarming because:
Computing has become infrastructure, but it doesn’t work like infrastructure.
And aside from computing infrastructure that we've come to rely on, we are building more and more software-intensive complex systems:
It’s no accident that the most truly engineered of software-engineering projects extend well beyond the computer. Autonomous-vehicle design offers the most obvious contemporary example. When Google designs self-driving cars, it musters its own computational systems, like mapping and navigation. But it also integrates those into a world much larger than browsers and smartphones and data centers. Autonomous vehicles share the roads with human-driven cars, pedestrians, and bicyclists. Those roads are managed, maintained, and regulated. Self-driving cars also interface with federal motor-vehicle standards and regulations, along with all the other material demands and foibles of a machine made of metal and plastic and rubber rather than bits. Engineering addresses complex, large-scale systems.
We're sympathetic to the article. The fundamental complaint seems to be that companies are co-opting the term engineer for glory, but they are merely profiteering raiders who are avoiding the rigor required of engineering professionals. We can't deny this assessment given many of the requests we receive from new hardware companies looking to strike it rich as quickly as possible.
Fortunately, there seems to be a slowly growing wave of increasing professionalism that may stand to counter the reckless creation of software systems. Jack Ganssle tells a chilling tale about the evolution of fire safety standards and equates the situation to software. He, and many others, also call for eliminating the term "bug" and replacing it with "error".
Jack’s fundamental question still rings true, especially in light of the Boeing MCAS debacle and loss of 346 lives. How many more software-related catastrophes will we experience before we demand a fire code for people working on critical software systems and infrastructure? If programmers want to be considered engineers they ought to be held to the same standards as engineers in other specialities.
We've recently been digging into coroutines for our C++ framework, which is well-timed because they are slated to land in C++ with the upcoming C++20 release. Although they are just being added to C++, the coroutine concept exists in a variety of languages and can be applied even without language standard support (see libaco for a C implementation, and Klemens Morgenstern's talk for a lightweight implementation for C++ on ARM controllers.
As a brief overview, a coroutine is a function which:
- May or may not have its own stack (depending on the implementation)
- Can interrupt its own execution at specific suspension/yield points
- Can be resumed later
Coroutines provide an asynchronous processing alternative to threads. Instead of having a scheduler which interrupts threads, coroutines interrupt themselves. Asynchronous processing is achieved by manually sequencing slices of coroutine functionality.
As always, there are tradeoffs: coroutines give us deterministic asynchronous processing, but they do not provide true concurrency that can take advantage of multiple processors or cores. This set of tradeoffs is generally attractive for embedded systems, as embedded systems designers are often more concerned with determinism than taking advantage of concurrent processing.
The links we list below have helped us immensely in our study of coroutines. We'll be applying them to our embedded C++ framework to simplify some complex areas of asynchronous processing that currently uses hard-to-follow chains of callbacks (these notes from IT Hare demonstrate the complexity problems we are facing). Avoiding chains of callbacks will greatly simplify our asynchronous code.
For more on coroutines in general:
- Eight Ways to Handle Non-blocking Returns in Message Passing Programs with Script
- emBO++ 2018 Klemens Morgenstern: Developing high performance coroutines for ARM
- Wikipedia: Coroutines
- FreeRTOS Coroutines
- Coroutines in C
For more on C++ coroutines:
- Cppreference: Coroutines
- Dawid Pilarski's coroutine series:
- Lewis Baker's coroutine series:
- Coroutines working draft
- 2018 Meeting C++: Andreas Reischuck - Coroutine TS a new way of thinking
- GCC Coroutines (experimental)
- Clang Coroutines (experimental)
- C++ Coroutines Links
- CppCoro: A Library of Coroutine Abstractions for Coroutines TS
Klemens Morgenstern has released a new GitHub integration called Report.ci. Report.ci allows you to report automated unit test results and compiler logs to GitHub from your chosen continuous integration (CI) system. Rather than having to dig around in the build server logs to figure out why a build or test failed, the results can be uploaded to Report.ci and shown directly in the GitHub pull request (under both "Checks" and "Files Changed").
Here are some examples of the service in action:
- Failed test: checks and files changed
- Broken build with compiler log annotation: checks and files changed
Report.ci currently supports 28 unit test frameworks and compiler log annotations for many popular languages and compilers. Other capabilities of the service include Badges, Annotation merging for cross-compilation scenarios, and mapping annotations so they appear at the code under test (rather than the test code itself).
Report.ci is free for public GitHub projects to use. Give this plugin a try if you want to see test results and compiler logs directly within your GitHub pull requests.
Around the Web
We've grouped our May reading recommendations by these categories:
Niall Cooling continued his series on the difference between semaphores and mutexes with Part 2: The Mutex & Mutual Exclusion Problems.
Fotis Chatzinikolaou shared helpful communication protocol design tips in Designing Communication Protocols, Practical Aspects.
Arch Martin at AVX wrote an excellent app note describing the basics of decoupling.
We found an app note from Renesas on eye safety protection guidelines for products using infrared LEDs.
Take a look at the die of Intel's 8087 floating point coprocessor chip
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.
We added new links to the Software References, Hardware References, and For Beginners pages. The new links include a list of all Embedded.fm episodes, links to video playlists, and a review of free Python courses.
A link to our curated YouTube video playlists has been added to the "Resources" menu.
We corrected typos in our article: Ditch Those Built-In Arrays for C++ Containers.
We published the following articles in May:
- Programmers: Let's Study Source Code Classics
- Embedded Artistry YouTube Channel
- Five Wire, a Portable Debugging Suite for Digital Engineers
- Exploring Startup Implementations: OS X
These were our most popular articles in May:
- Creating a Circular Buffer in C/C++
- Installing LLVM/Clang on OSX
- Demystifying Microcontroller GPIO Settings
- Migrating from C to C++: NULL vs nullptr
- C++ Casting, or: "Oh No, They Broke Malloc!"
- An Overview of C++ STL Containers
- Jenkins: Configuring a Linux Slave Node
- Jenkins: Running Steps as sudo
- Improving Your Callback Game
Thanks for Reading!
Have any feedback, questions, suggestions, interesting articles, or resources to recommend to other developers? Simply reply to this email!