February 2019: Bluetooth 5.1 and Peer Code Review

Welcome to the February 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:

  • The new Bluetooth 5.1 specification
  • Phil Koopman's peer code review best practices
  • Embedded news from around the web (there was a lot of activity this month!)
  • Embedded job postings
  • Updates to the Embedded Artistry Website

Bluetooth 5.1 Released

The Bluetooth SIG released Bluetooth version 5.1 in January. The Bluetooth 5.1 release adds new features and capabilities to Bluetooth Low Energy (BLE).

Direction finding is the primary feature of the Bluetooth 5.1 release. The new direction finding capabilities include both Angle of Arrival (AoA) and Angle of Departure (AoD) measurements. Location services, such as asset tracking, item location, proximity marketing, and indoor way-finding, will use the new BLE direction finding capabilities. For products to take advantage of the new direction finding features, multiple antennas are required: 2+ on receivers for AoA method, and 2+ on transmitters for AoD method. BLE stacks will need controller-level updates to support the new features.

Other features of the 5.1 release include:

  • GATT Caching enhancements to reduce connection times in unbonded devices
  • Randomized advertising channel indexing to improve packet collision avoidance
  • Periodic advertising synchronization transfer
  • HCI support for Debug Keys in LE secure connections
  • Sleep clock accuracy update mechanism
  • ADI field in scan response data
  • Interaction between QoS and Flow Specification
  • Host Channel Classification for Secondary Advertising
  • Allow the SID to Appear in Scan Response Reports
  • Specify the behavior when rules are violated

For more on Bluetooth 5.1:

Phil Koopman on Peer Code Reviews

Peer code review is a code quality practice that we encourage all teams to adopt. This month, we listened to Phil Koopman's lecture series on Peer Code Review. This lecture series is full of actionable information which can help teams looking to adopt a formal peer code review practice. The series also serves as a source of new ideas for teams already performing reviews.

One area we want to highlight is Phil's rules for successful peer reviews:

  • Review everything that your team writes down:
    • Documentation
    • High-level design
    • Detailed design
    • Code
    • Test plans
  • Inspect the item, not the author
  • Don't get defensive - nobody writes perfect code
    • If you are getting defensive as the author, leave the room
  • Find problems; don't fix them in the meeting
    • Identify the symptom or technical deficiency of the problem as specifically as possible
  • The word "should" is not appropriate in a peer review
  • No debates on style
    • Enforce conformance to style guide
    • Do not debate whether the style guide is correct

Phil expands upon these rules with his peer code review best practices:

  • Formal reviews (Fagan inspections) optimize bugs found per dollar
    • Formal reviews find more bugs than informal reviews, and they find them more efficiently
    • Informal reviews typically find < 10-50% of defects
    • Online-review tools are OK, but they are not substitute for formal in-person review meetings
  • Target 10% of total project effort to find 50% of bugs
  • Also review documentation and designs - not just code
  • Review documentation and design first to find issues before coding begins
  • Use a checklist to find the most bugs
  • Target 1 peer review per day so you don't burn out reviewers
  • Schedule peer reviews regularly
    • 2-3 reviews per week as the project progresses
  • Limit meetings to 1-2 hours
    • After 2 hours, review effectiveness drops off
  • Target 150 lines of non-comment source code per hour for review
  • Keep a queue of items pending review; pull off queue for a scheduled review
  • Run static analysis tools before review meetings
    • Static analysis tools do not eliminate the need for peer code review

Phil states that formal peer code reviews should capture > 50% of defects. If your team is not finding sufficient bugs during code reviews, listen to the lecture series and try applying a formalized review process. All of us can improve the quality of our peer code review by applying these straightforward rules and best practices in our organizations.

Here are additional publications on peer code reviews by Phil Koopman:

Here are Embedded Artistry publications discussing peer code reviews:

Around the Web

There was a lot of activity in January, so we've grouped our reading recommendations by category:

  • Firmware
  • Hardware
  • C
  • C++


Jack Ganssle shared insights into how we can improve our firmware development processes.

Researchers in Japan studied how tree frogs regulate their communications to avoid croaking over each other frog in the colony. Their findings have implications for a future network packet collision prevention scheme.

Low-powered IoT devices with limited memory capabilities will have to eventually support IPv6. 6LoWPAN will make that happen.

Japan plans to hack 200 milion IoT devices in February to compile a list of vulnerable devices. This effort further highlights the fact that IoT devices, not people, are now the security weak link.

The Multicore Association has released a new version of the Software-Hardware Interface for Multi-Many Core (SHIM). Version 2 of the specification introduces new features around power consumption properties, inter-connect contention descriptions, custom instructions, vendor extensions, and more.


EDN gave us a look at NASA Apollo electronics from the 1960s.

Samsung shipped the first 1 terabyte NAND chip.

For years we have faced a constrained DRAM supply with rising prices. Now we are dealing with over-supply and a forecasted 20% price crash.

Nanopower announced their nP-BLE52 module, which is a System-in-Package (SiP) combining an nRF52832 with a custom power management IC. The custom power management IC enables the SiP to put the SoC into sleep mode, cut power, and wake it up at a pre-set time and restore the pre-sleep state. Sleep mode current consumption is spec'd at 10nA, making this processor ideal for low-power and long-life embedded applications.

Apple has filed a patent for a new version iBeacon, which will utilize ultra-wide band radio instead of BLE.

The electronics industry shipped over 1 trillion devices last year, including integrated circuits and optoelectronics, sensors, and discrete (O-S-D) devices.

All About Circuits has been publishing reviews of sensors, in case you need inspiration for your next project:


Feabhas published an article describing How to use C structs to access memory mapped peripheral registers. Many vendor SDKs and frameworks use this technique for interacting with processor peripherals.


C++ can be a confusing language, especially when details such as lvalues and rvalues come up. This practical post on C++ moves is for those developers who don't know (or don't care) what rvalues are.

C++11 added smart pointers to our arsenal, but it's not always clear how we should move them into and out of functions.

As is commonly heard, const is a contract. It's important to understand exactly what const should communicate at different points in our programs.

Embedded Job Postings

Cisco Meraki is hiring for a Firmware Features Software Engineer in San Francisco. The features engineer will architect and implement features across the software stack, spanning from device drivers and routing code all the way up to Cisco's distributed, cloud-hosted backend.

Hiring Embedded Engineers?

Is your company hiring for embedded systems roles? Send us a short (< 100 words) job ad with a link to the description and we will be happy to include it in our newsletter.

Website Updates

We've added code syntax highlighting to our website. Please let us know if you notice any problems with code samples after the update.

We expanded the Glossary with additional terms.

We updated the following article with new content:

New Articles

We published the following article in January:

These were our most popular articles in January:

  1. Circular Buffers in C/C++
  2. std::string vs C-strings
  3. Jenkins: Configuring a Linux Slave Node
  4. Installing LLVM/Clang on OSX
  5. C++ Casting, or: "Oh No, They Broke Malloc!"
  6. Jenkins: Kick off a CI Build with GitHub Push Notifications
  7. Jenkins: Running Steps as sudo
  8. Demystifying Microcontroller GPIO Settings
  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!


January 2019

Happy New Year!

Welcome to the January 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:

  • Highlights from 2018
  • The Embedded Template Library
  • A code "self-review" exercise
  • Embedded news from around the web

2018 in Review

We covered a lot of ground with our newsletter in 2018. We focused on four major topics:

  1. Improving Quality
    1. Lightweight Processes to Improve Quality
    2. Testing Embedded Systems
  2. Libraries suitable for embedded systems
    1. C and C++ Libraries We Like
    2. C++ Embedded Frameworks
    3. Three more useful embedded projects
  3. Changes to C++ that might impact embedded developers
    1. C++ standardization meeting in Rapperswil
    2. New Freestanding C++ proposal
    3. An update on Freestanding C++ & scoped enumerations proposal
  4. Security Flaws & Hacks
    1. Spectre & Meltdown
    2. Spectre Returns
    3. The Big Hack

2018 was a productive year for Embedded Artistry:

On a fun note: according to our Twitter analytics data, 99% of our followers love “dogs”, with “tech news” and “space & astronomy” following closely behind. Our team feels the same!

Embedded Template Library

We've been hard at work on our C++ embedded systems framework. A critical design requirement is that the framework core components do not utilize dynamic memory allocation. Unfortunately, this excludes most of the STL containers, as they get storage from the heap by default.

Rather than reinventing the wheel, we spent some time searching for existing solutions to this problem. We feel lucky to have discovered the Embedded Template Library (ETL), an open-source project created by John Wellbelove at Aster Consulting Ltd.

The ETL provides fixed-size alternatives to STL container types. The ETL containers specify a maximum capacity at compile-time and make no calls to malloc/free/new/delete. As an added bonus, the containers are all cache friendly: storage for all container types is allocated in contiguous blocks. The ETL also provides additional utilities and frameworks that are useful for embedded projects. The library can be safely used in conjunction with the STL.

The ETL will be included in our embedded framework and will be seen in our code samples for future articles. You can find additional ETL links and information on our website.

Code Self-Review Exercise

Code reviews are one of the essential practices for improving software quality. Aside from identifying issues with code before its deployed, reviews expose developers to new techniques, approaches, and patterns of thought.

As a consultant, it’s hard to enlist help for internal code reviews. As such, I’ve been testing other strategies to improve the code I write. For example, I use automated processes to check for problems or style inconsistencies, and I run through a checklist of common design mistakes before I merge in any new code changes.

Recently, I’ve been noting mistakes I’m prone to make and screening for them before submitting pull requests. I learned about this exercise in "Social Effects of Peer Review.". Here's a summary of the exercise from the article:

Try this experiment sometime: For one week, make a log of every error you make. Every misspelling in e-mail, every time you accidentally close the application you’re working in, every time you have a bug in your code, even every syntax error you make. Don’t get too specific; keep each item in the list high-level and use hash marks to count how many times you make that type of mistake.

For now, just imagine you’ve done this. As you might guess, certain patterns emerge. A few of the items have an awful lot of hash marks next to them. In fact, by the end of the second day you might have been getting tired of counting some of them!

And that annoyance might live in the back of your mind. You might even start thinking about it consciously. Pretty soon you’ll anticipate the mistake and prevent yourself from making it. Some of those will come easy, others will take work to eliminate. But eventually you develop habits that prevent that type of error completely. If you frequently forget to close parenthesis in your code, perhaps you’ll enable the feature in your code editor that closes parenthesis for you. If you close applications by accident, maybe you’ll pause just a few seconds every time you’re about to hit the close button. Maybe you’ll look up how to spell common words or learn how to input your common mistakes into the auto-correct facility in your e-mail editor. Over time you become more productive and more efficient. You’re working faster and smarter. Not through some self-help seven-step program, just by observing yourself a little more carefully and systematically than you’re used to.

Noting down all of the mistakes you make can also be a humbling experience. Give it a try this week as a New Year’s resolution and see how much you improve by just paying more attention to yourself.

Around the Web

MQTT and CoAP are ubiquitous in IoT applications. Unfortunately, Trend Micro reported that these messaging protocols are insecure. You can read their full report, "The Fragility of Industrial IoT's Data Backbone".

While we're on the topic of vulnerabilities, this article by The Register discusses the software bugs and software quality.

All About Circuits shared an embedded project that we love: How to Make Your Umbrella into a Weather Station with a Particle Photon.

All About Circuits also posted an introduction to MEMS systems. Since many components in our embedded systems utilize MEMS technology, we recommend familiarizing yourself with how it works.

This article provides a nice summary of how different industries are leveraging IoT devices.

IEEE Spectrum published an article describing sensors that are suitable for medical applications.

Orbit Fab launched an experiment to the ISS to test cube satellite refueling technology.

Ellisys has created a video series that teaches developers about Bluetooth. Videos include: Intro to Bluetooth Low Energy, Generic Access Profile (GAP), Advertisements, Connections, Generic Attribute Profile (GATT), Power Consumption, Security, Bluetooth 5 and IoT, and Intro to Bluetooth Mesh.

Jee Labs published a six-part series which introduces developers to the CAN bus:

  1. Intro
  2. Access
  3. STM32
  4. JeeH API
  5. Demo
  6. Single-wire

Website Updates

We updated the Embedded Artistry Technology Radar to reflect the changes in various technologies and techniques that are under assessment.

We also updated the following previously published articles with new and corrected content:

New Articles

We published the following articles in December:

These were our most popular articles in December:

  1. Circular Buffers in C/C++
  2. Jenkins: Configuring a Linux Slave Node
  3. std::string vs C-strings
  4. Installing LLVM/Clang on OSX
  5. C++ Casting, or: "Oh No, They Broke Malloc!"
  6. Jenkins: Kick off a CI Build with GitHub Push Notifications
  7. An Overview of C++ STL Containers
  8. Jenkins: Running Steps as sudo
  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!

We’d also love to hear how the code review experiment goes for you.

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

Happy hacking!