Bluetooth

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++

Firmware

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.

Hardware

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:

C

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++

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!

-Phillip

October 2018: EA Framework Announcement & More Embedded Libraries

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

  • Embedded Artistry's C++ Framework Project
  • Three more projects embedded developers should be aware of
  • Embedded articles from around the web
  • Website updates

Embedded Artistry Framework Project

Over the past two years in San Francisco, I’ve had the opportunity to consult with dozens of companies and to work on a wide variety of embedded products. Most teams and projects seem to struggle with the same issues, especially with hiring firmware engineers and keeping projects on schedule.

Why is everyone running into the same roadblocks?

In order to find solutions, I've been immersing myself in the software engineering corpus, reflecting on the coupling between firmware and hardware, learning software architecture, practicing Test Driven Development, and researching embedded libraries and frameworks that can help firmware developers move faster.

What I’ve noticed is that the software industry has learned a lot of lessons over the past fifty years, but we’ve failed to incorporate many of them in the embedded community. We are building products in less time, with minimal teams, and generally using poorly tested vendor SDKs. We aren’t decoupling our software from the underlying hardware. Many embedded teams still don’t utilize modern development practices such as static analysis, unit testing, and continuous integration.

What if we actually leveraged the lessons we’ve learned as an industry? What if we built our embedded software in such a way that we minimized coupling with the underlying hardware and RTOS?

  • We could begin developing and testing our embedded software before we have hardware in house
  • We could write device drivers on our host machine (talking to real parts) and port them over to our target hardware with full confidence that they will work
  • We could defend against the inevitable changes in components and processors that trigger software rewrites and massive schedule delays
  • We could leverage proven libraries and frameworks to save time and avoid reinventing any wheels
  • We could automate our testing and check our code often for preventable bugs

Embedded Artistry is building an embedded C++ framework which will help us accomplish these goals. We want to provide embedded teams with a solid foundation that incorporates our lessons learned and supports modern development practices.

Our primary goal is to support decoupling firmware from hardware at various levels of abstraction (platform, circuit board, processor). Rather than aim for universal abstractions and interfaces, we want to provide a minimal foundation which teams can expand to meet their product’s specific goals and requirements.

We are currently building our basic framework structures on a host machine to ensure we can develop software off-target. Later this fall we’ll bring the framework up on a couple of common embedded platforms.

I’ll be sharing more about the framework as it evolves over the coming months. In the mean time, I’d love to hear from you if you think your team could benefit from a system like this.

Three More Useful Embedded Projects

I always have my eyes open for interesting embedded projects. I want to share three more projects that I've discovered, two of which are being actively used in our framework:

  • Embedded Template Library
  • mpaland/printf
  • embxx

For other embedded projects, libraries, and frameworks which we've shared, check out the following editions:

Embedded Template Library

A common concern with using C++ and the STL on embedded systems is the reliance on exceptions and dynamic memory allocation. For many embedded systems, use of these features is disallowed. Working around this limitation is possible, but often more difficult than project schedules allow for.

John Wellbelove of Aster Consulting Ltd created the Embedded Template Library (ETL) to address these issues. The ETL provides fixed-capacity STL container alternatives and requires no dynamic memory allocation, no RTTI, and no exceptions. The ETL also provides additional container types, helpful utilities, algorithms (such as CRC), reusable framework components (FSM, state chart, scheduler, callback timer), and an abundance of documentation.

If your embedded compiler doesn't support modern C++ standards, you're in luck - the library is compatible with C++03, and many of the C++11 features have been backported through the ETL.

The ETL is an becoming an essential tool for our embedded C++ development. We've adopted the ETL in our current framework project to take advantage of fixed-capacity containers and other useful features.

mpaland/printf

printf is one of those commands that every developer relies on. However, using printf on many embedded systems can be a challenge due to the size of the library (20kB+ is not uncommon). Perhaps you do not want to link with libc for your platform, or the implementation you're using requires you to implement esoteric system functions for each platform.

The mapaland/printf implementation addresses these problems. The implementation is ~600 lines and has no external dependencies. The library is reentrant and all of the useful flags (including floating point and precision/width specifiers) are supported. All you have to do to get up and running on your platform is define a _putchar() function which outputs a character over your chosen communication bus (UART, USB, BLE, etc.).

We've integrated mapaland/printf into our embeddedartistry/libc and are actively using it in our framework project.

Embxx

If you're working with C++ on embedded systems, chances are that you've come across the Practical Guide to Bare Metal C++. This free e-book is an excellent starting point for applying C++ to embedded systems, and the author walks through the creation of many useful embedded systems constructs.

The concepts presented in the book are fleshed out in the companion embxx library. embxx is written in C++11 and targeted for bare metal and embedded Linux systems. The library doesn't use RTTI or exceptions, and most of the constructs presented in the library utilize static memory allocation.

Sadly, the project is no longer active, but it still serves as an excellent resource for embedded C++ developers. Many of the utilities, such as StaticFunction, StaticQueue, and StaticPoolAllocator, are always useful for embedded systems. The project also serves as a great reference for how we can utilize template meta-programming and static memory allocation schemes when writing embedded C++ software.

Around the Web

Steve Branam at Flink And Blink published "So You Want To Be An Embedded Systems Developer". This is an excellent article for those just starting out in the embedded systems field.

Matt Chernosky at Electron Vector shared 7 tips for adding unit tests to existing firmware. Start with Matt's tips if you need inspiration for adding tests to your existing project.

Mohammad Afaneh at Novel Bits published a four-part tutorial on Bluetooth Mesh. If you want to learn about Bluetooth Mesh, start with this series.

Mohammad also shared an interesting white paper in his weekly Bluetooth newsletter: Bluetooth Angle Estimation for Real-Time Locationing. The paper discusses using Bluetooth Angle of Arrival and Angle of Departure for indoor locationing.

Jack Ganssle continues to publish his "Top 10 Reasons Embedded Projects Get Into Trouble". We've worked our way to Number 3:

Website Updates

Our Glossary page has been expanded. If you notice any terms or acronyms that are missing, let us know!

We've restructured our Libraries page and added more of our own open-source projects to the list.

Our Technology Radar has been updated:

  • We are now using TDD and recommend it for adoption
  • We are recommending the Embedded Template Library for adoption after completing our trial period
  • We are experimenting with automated clang-tidy checks on our framework project
  • We have moved away from Doctest and are now trying out Catch for our C++ unit testing because it supports -fno-exceptions

New Articles

The following article was published on our website in September:

These were our most popular articles in September:

  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. Migrating from C to C++: NULL vs nullptr
  9. Implementing an Asynchronous Dispatch Queue
  10. Jenkins: Kick off a CI Build with GitHub Push Notifications

Thanks for Reading!

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.

IMG_7389.jpg

Thanks for Reading!

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

September 2017

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

  • Follow-up Bluetooth Mesh reading recommendations
  • A flexible 2.4GHz antenna suitable for metal surfaces
  • A selection of 2017 embedded market reports that are worth reviewing
  • The incredible engineering behind the Voyager spacecraft
  • How Intel's chip design advances have allowed them to keep Moore's Law alive
  • Building your own SMT reflow oven using a halogen lamp

Bluetooth Mesh Articles

In last month's newsletter, we reviewed two major additions to Bluetooth: Bluetooth 5 and Bluetooth Mesh. Since Bluetooth Mesh is fresh off the press, the Bluetooth SIG has been published some great articles to demystify the new standard.

Check out these recent posts:

A Flexible 2.4GHz Antenna for Metal Surfaces

I was surprised to see an announcement this month regarding an antenna designed for metal surfaces. Building connected devices can be quite a challenging experience. You need to give careful attention to antenna placement and tuning in order to optimize your product's performance. These challenges increase significantly if your product has integrated metal. Metal surfaces can wreak havoc on your antenna design, resulting in antenna detuning, efficiency losses, and reduced communication ranges.

Laird's new mFlexPIFA antenna looks like a promising solution for products with metal enclosures. The mFlexPIFA is about the size of a quarter and is built for 2.4GHz devices. The antenna is adhesive-backed and can be mounted directly onto metal surfaces without detuning the antenna. The design is also flexible, allowing you to mount your antenna to curved surfaces.

Consider this antenna solution in your next connected design, especially if it involves a metal enclosure

More on the FlexPIFA antenna:

2017 Embedded Systems Market Studies & Surveys

"Embedded systems" is a blanket term describing a vast array of devices with differing purposes, computational capabilities, and reliability levels. It's easy to forget the differences in embedded applications and devices, and I find that reviewing market surveys provides some great insight into how the field is developing. I want to share three market surveys with you today:

The Hax hardware accelerator's embedded market study focuses on general trends in hardware development, development directions in different sectors (e.g. consumer, health, industry), automation (which has taken off in China), and hardware funding models.

The AspenCore market survey is less focused on where the market is heading. Instead it dives into areas such as development practices, tools, project timelines, and processor selection.

The Barr Group's embedded systems safety and security survey provides some interesting and alarming insights. They conclude that even though there is increased risk of bodily injury, many automotive design teams are still not using best practices such as static analysis, regression testing, coding standards, and code reviews.

In reading these surveys, I noticed the following general trends:

  • C is still dominating in the embedded space
  • More and more projects are using multiple processors
  • Industrial sensing and automation is rising
  • Devices are becoming increasingly "connected"
  • In many cases best practices are being overlooked

The Voyager Mission Celebration Series

All About Circuits has been celebrating the 40th anniversary of the Voyager I and II spacecraft by dedicating a series of articles to them. The articles dive into the electronics and engineering behind these incredible systems. I have an intense level of respect for the engineers who built such reliable systems without the bountiful computational and technological capabilities that we have today. It would be amazing if any of my devices are still operating 40 years from now, even on the comfortable confines of Earth!

Ten excellent articles have been published in the Voyager spacecraft series:

  1. Voyager Mission Anniversary Celebration Series: Introduction
  2. Powering the Voyager Spacecraft with Radiation: The RTG (Radioisotope Thermoelectric Generator)
  3. Communicating Over Billions of Miles: Long Distance Communications in the Voyager Spacecraft
  4. The Brains of the Voyager Spacecraft: Command, Data, and Attitude Control Computers
  5. Exploring the Solar System with the Voyager Spacecraft’s Cameras, Polarimeters, and Magnetometers
  6. The Infrared Interferometer, Spectrometer, and Radio Astronomy of the Voyager Spacecraft
  7. How the Voyager Missions’ Plasma Science Investigations Teach Us About Solar Winds
  8. The Low Energy Particle Instruments on the Voyager Spacecraft
  9. The Voyager Mission: Insight into Our Solar System
  10. Voyager Anniversary Celebration: 40 Years in Space

The New York Times has recently published "The Loyal Engineers Steering NASA’s Voyager Probes Across the Universe" which takes a look at the human side of the Voyager missions.

While not part of the Voyager series, there was another recent article describing how the space race gave us GPS. If you're interested in the history and theory behind GPS, take a look at "How the Space Race Gave Us GPS Technology".

Intel's New Processor Designs Keeping Moore's Law Alive

This article was published earlier in the year, but I still think its an illuminating read. Back in 2002, Intel announced a breakthrough with their new field effect transistor ("FinFET") design, dubbed the "tri-gate transistor". In 2011, Intel finally announced their first chips built with tri-gate transistors and that the new transistor was the official future of Intel's processing lines. The 2011 announcement involved a 22nm process, and Intel followed that up in 2014 with a 14nm process. Intel is continuing to maintain their 14nm process and finally coming out with a 10nm process this year.

At a time when keeping up with Moore's Law seems like an impossible task, Intel has managed to keep the law alive: both their 14nm and 10nm processes have more than doubled in transistor density. Intel credits their "hyperscaling" techniques, such as reducing the number of dummy gates required to isolate logic cells and stacking metal contacts above gates. These hyperscaling techniques give Intel a transistor density advantage over their competitors at the same process size. For example, Samsung's 10nm process is comparable in transistor density to Intel's 14nm process.

While I don't think I'll be writing firmware for Intel-powered embedded devices in the near future, I'm excited to see the pressure that Intel's 10nm process puts on other chipmakers. Size is a major concern in the embedded world, so I'm certain we will see some of these hyperscaling techniques applied to other chip families in the future.

More on Intel's new architecture, Transistors, and Moore's Law:

Build Your Own SMT Reflow Oven With a Halogen Lamp

I've been slowly building an electronics lab over the years, and I'm lucky enough to possess an oscilloscope, a bench-top DMM, and a logic analyzer. One project I've had in mind is building an SMT reflow oven. Being able to reflow boards would increase assembly and repair capabilities. I was thrilled to find a blog post about building an SMT reflow oven using a halogen lamp. The author was able to build his own SMT reflow oven for ~$30 by using a halogen lamp, an AC dimmer, and a reflow oven controller.

I discovered the SMT reflow project through Dangerous Prototypes. Check out their website if you're looking for electronics projects to tackle in the future.

Website Updates

I've made a few updates to the website:

  • Updated the Development Kits page to have a much nicer presentation style. Each development kit has its own dedicated blog post, allowing me to provide more detailed information for each kit.
  • Added more terms to the Glossary

These were the most popular articles over the past month:

  1. An Overview of C++ STL Containers
  2. Installing LLVM/Clang on OSX
  3. Choosing the Right STL Container: General Rules of Thumb
  4. C++11 Fixed Point Arithmetic Library
  5. Circular Buffers in C/C++

Happy hacking!

-Phillip

August 2017: Bluetooth Edition

Welcome to the August 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.

This month we'll be covering:

  • MAX17055 - a new fuel gauge chip from Maxim
  • The Bluetooth 5 standard and changes to the PHY
  • Processors and development kits that support Bluetooth 5
  • The new Bluetooth Mesh standard
  • SDKs that support Bluetooth Mesh
  • A handy trick for when you can't read the part numbers on a chip

MAX17055 - New Maxim Fuel Gauge

Those of us who have used TI's GasGauge line understand how frustrating their parts can be. Undocumented behavior in the gauge firmware, required battery characterization, and per-product configuration can lead to frustrating bugs that are hard to debug. Unless you're a large customer, you have very little chance of getting help from TI and problems often stay unresolved.

One of my clients is using a new fuel gauge chip - the MAX17055 Fuel Gauge. Maxim claims that their gauge "eliminates battery characterization requirements and simplifies the host software interaction" and requires only 7µA of operating current. Unlike TI, Maxim provided great direct support for integrating this part into the new system.

Maxim provides a software implementation guide which describes various methods of using the part. By following the software guide, I implemented a driver for my system in less than an hour. Once the new boards arrived, the driver was working perfectly in a matter of minutes and the initial calibration resulted in readings that were within 5% of the actual voltage value. Since the Maxim Fuel Gauge is a learning gauge, this initial accuracy should improve over a few charge/discharge cycles.

If you're looking for a fuel gauge to use in your next battery-powered device, I recommend the MAX17055.


Bluetooth 5 & Bluetooth Mesh

We've seen two major Bluetooth specification releases in the past 12 months: Bluetooth 5 and Bluetooth Mesh.

It typically takes ~6 months for us to see devices once a new specification is released. We're well into that window for Bluetooth 5, so expect to start seeing new devices soon. Bluetooth Mesh is fresh off the press, so now is the time to start familiarizing yourself with the specification to stay ahead of the curve.

Next, I'll describe the changes involved with the Bluetooth 5 and Bluetooth Mesh specifications. I'll also provide some supplementary reading material and showcase some interesting Bluetooth 5 chips and development kits.


Bluetooth 5

The Bluetooth 5 specification was released in December 2016. The new specification claims a variety of improvements:

  • 4x range
  • 2.5x lower power (BLE)
  • 2x speed (supporting a new 2Mbit/s high-throughput mode)
  • Increased advertising data payload from 31B to 255B
  • Ability to chain advertising packets to create extended payloads
  • Improved coexistence with other WiFi, Bluetooth, and 2.4GHz devices via an improved channel hopping algorithm

The speed and range improvements are brought about by changing the physical layer (PHY) of the Bluetooth protocol stack. The Bluetooth PHY now supports two additional modes, which allow for increased speed or increased range. The three Bluetooth PHYs are:

  1. "LE 1M" - the PHY used in Bluetooth 4
  2. "LE 2M" - the 2Mb/s PHY, which doubles the speed of the LE1M PHY
  3. "LE Coded" - the new long-range PHY that adds error correction

The increased range does not involve any transmit power increases. Instead, the increase is provided by improving receiver sensitivity and utilizing Forward Error Correction (FEC). FEC adds redundant data bits to the transmitted packets. These redundant bits allow for error correction to be performed by the receiver and for messages to be correctly decoded at a lower signal-to-noise ratio (SNR). This provides a ~12dB improvement in receiver sensitivity, resulting in the 4x range improvement. Of course, the redundant information does come with a penalty in reduced data throughput due to the need to transmit redundant bits.

You can switch between PHYs by using the new HCI command "LE Set PHY". You can independently select the PHY to use for both transmit (TX) and receive (RX). This means that we can switch between PHY modes depending on our operational situation. Additional HCI commands are defined to support setting the default PHY and for querying the PHY capabilities of remote devices.

Bluetooth 5 is operationally compatible with Bluetooth 4.x devices. However, the changes to the Bluetooth 5 specification have been made at the PHY layer. You will be tied to the LE 1M PHY and will not be able to take advantage of Bluetooth 5 benefits.

For more details on Bluetooth 5, read these:

Bluetooth 5 Chips & Development Kits

Let’s take a look at some development kits and chips from Nordic and Silicon Labs that already support the new standard.

Nordic nRF52

Nordic offers Bluetooth 5 support in its nRF52 line, consisting of three chips: nRF52810, nRF52832, and nRF52840. All of the nRF52 chips support the new CSA algorithm, the LE 2M PHY, and increased advertising packet size. However, only the nRF52840 has support for the new long-range LE Coded PHY.

nRF52810 & nRF52 DK

The nRF52810 is the simplest of the three Bluetooth 5 chips, sporting a Cortex-M4 and a basic set of peripherals. Due to the reduced flash, RAM, and peripheral counts, this chip is useful as a dedicated Bluetooth processor in a multi-chip system.

The nRF52810 itself is not included on a development kit. Nordic recommends the nRF52 DK for exploring the low-end of the nRF52 series. This starter board is compatible with Arduino shields, allowing for some interesting prototyping options. The nRF52 DK utilizes a nRF52832, so you'll want to hold off on using unsupported features if you're going to uses the nRF52810.

nRF52810 Specifications:

  • 32-bit Cortex-M4 64MHz Processor
  • 1.7v to 3.6v operation
  • 192kB flash + 24kB RAM
  • Up to +4dBm output power
  • -96dBm sensitivity, Bluetooth low energy
  • 1 x Master/Slave SPI
  • 1 x Two-wire interface (I²C)
  • 1 x PWM (4 channels)
  • AES HW encryption
  • 8-channel 10/12-bit ADC
  • Quadrature decoder
  • 64-level analog comparator
  • Real Time Counter (RTC)
  • Digital microphone interface (PDM)

More on the nRF52810:

Nordic nRF52832 & Nordic Thingy:52

The nRF52832 is the mid-tier Bluetooth 5 chip. The nRF52832 is built on a Cortex-M4F processor. The nRF52832 provides a significant increase in flash, RAM, and peripherals over the nRF52810. These improvements make the nRF52832 an attractive choice as a primary processor for your system or for exploring new BLE features like IPv6 support. The nRF52832 includes an on-chip NFC tag to support out-of-band pairing. You can utilize the NFC pairing method for a simpler process of exchanging authentication information between two bluetooth devices.

The nRF52 DK supports the nRF52832, but Nordic also sells the Thingy:52 development kit. The Thingy:52 provides you with a variety of environmental sensors (temp, humidity, pressure, air quality, color, and light), a 9-axis IMU (accelerometer, gyro, and compass), a speaker, and a microphone. The range of components provided with this dev kit is impressive and useful for many Bluetooth prototyping scenarios. Nordic also supplies a Thingy:52 app and demo code to get you up and running as quickly as possible.

nRF52832 Specifications:

  • 32-bit ARM Cortex-M4F 64MHz Processor
  • 1.7v to 3.6v operation
  • 512kB flash + 64kB RAM
  • On-chip NFC tag for Out-of-Band (OOB) pairing
  • Up to +4dBm output power
  • -96dBm sensitivity, Bluetooth low energy
  • 3 x Master/Slave SPI
  • 2 x Two-wire interface (I²C)
  • UART (RTS/CTS)
  • 3 x PWM
  • AES HW encryption
  • 12-bit ADC
  • Real Time Counter (RTC)
  • Digital microphone interface (PDM)
  • On-chip balun

More on nRF52832:

nRF52840 & Preview DK

The nRF52840 is the king of the Bluetooth 5 chips and the only chip in the product line that supports 802.15.4 and the new Bluetooth 5 LE Coded PHY. The nRF52840 provides an impressive 1MB of flash and 256kB of RAM.The chip sports additional peripherals, such as the ARM Cryptocell cryptographic co-processor and a USB 2.0 controller. With an improved output power of up to +8dBm, the nRF52840 is definitely the chip to pick if you're looking at long-range Bluetooth communications.

Nordic has released a nRF52840 Preview Development Kit (PDK). This kit is more similar to the nRF52 DK than the Thingy:52. The PDK provides no external peripherals or sensors to play with, but like the nRF52 DK it is compatible with Arduino shields for easy prototyping.

nRF52840 Specifications:

  • 32-bit ARM Cortex-M4F 64MHz Processor
  • 1.7v to 5.5v operation
  • 1MB flash + 256kB RAM
  • Up to +8dBm output power
  • 802.15.4 radio support (ZigBee and Thread)
  • On-chip NFC
  • PPI –Programmable Peripheral Interconnect
  • 48 x GPIO
  • 1 x QSPI
  • 4 x Master/Slave SPI
  • 2 x Two-wire interface (I²C)
  • I²S interface
  • 2 x UART
  • 4 x PWM
  • USB 2.0 controller
  • ARM TrustZone CryptoCell-310 Cryptographic and security module
  • AES 128-bit ECB/CCM/AAR hardware accelerator
  • Digital microphone interface (PDM)
  • Quadrature decoder
  • 12-bit ADC
  • Low power comparator
  • On-chip balun

More on nRF52840:

Silicon Labs EFR32

Silicon Labs offers Bluetooth 5 support in the EFR32 Blue Gecko line of SoCs. Similar to the Nordic nRF52810, the EFR32 series is built upon a Cortex-M4 processor. The EFR32 line sports a whopping +19dBm of programmable output power in their beefiest configuration.

Silicon Labs provides a Blue Gecko Starter Kit to support EFR32 development. The starter kit is modularized to support a wide variety of radio daughter boards for easy prototyping and chip comparisons. The starter kit comes with two Bluetooth radio daughter boards. Only the provided EFR32BG13 radio board supports the LE Coded and LE 2M PHYs. The starter kit contains a few push buttons and a coin cell battery holder, but does not include other on-board peripherals. A wide variety of headers are supplied for your prototyping needs.

Unlike Nordic's nRF52 line, the EFR32 line has many different chip configurations. Also, not all EFR32 chips support the new 2M PHY and LE Coded PHY, so be sure to include those features in your search. Silicon Labs provides a full list of EFR32 SoCs, so you can find one that fits your needs exactly.

Sample EFR32 Specifications using maximum values:

  • ARM Cortex-M4 Processor (up to 40MHz)
  • Up to 1MB of flash
  • Up to 256kB SRAM
  • Up to +19dBm output power
  • AES256/128 hardware accelerator
  • 12-bit ADC
  • Current DAC (4-bit)
  • Up to 4x analog comparators
  • Low-energy UART
  • Up to 4x USART (SPI, UART, I2S, IrDA)
  • Up to 2x I2C
  • Up to 65 GPIOs
  • On-chip balun

EFR32BG12P632F512FM38 Specifications (Blue Gecko Starter Kit):

  • ARM Cortex-M4 40 MHz Processor
  • 512kB Flash + 64kB SRAM
  • +10dBm output power
  • -103.3dBm receiver sensitivity
  • AES-128/256 hardware accelerator
  • 12-bit ADC
  • Current DAC (4-bit)
  • Up to 4x analog comparators
  • 4x UART Ports
  • 3x USART ports (SPI, UART, I2C)
  • 2x I2C ports
  • 31 GPIOs

More on EFR32:


Bluetooth Mesh

Bluetooth Mesh is not included in the Bluetooth 5 standard. It was released in July 2017. Bluetooth Mesh provides the ability for Bluetooth devices to implement a many-to-many (m:m) network with a maximum size of 32,000 devices. Previously we were limited to a one-to-many (1:m) topology, where a central Bluetooth hub was responsible for broadcasting messages to the various nodes. In addition to m:m topology support, Mesh allows devices to relay data to other devices that are not in direct radio range. This re-broadcasting scheme allows the network to cover a larger area than with Bluetooth LE. Since Bluetooth Mesh is built upon Bluetooth LE, it can be utilized by both Bluetooth 4.x and Bluetooth 5 devices. Existing devices in the field can take advantage of Bluetooth Mesh as long as they are capable of firmware updates.

Bluetooth Mesh devices communicate using a publish/subscribe messaging system. Whenever a device publishes a message to a specific topic, all devices who are subscribed to that topic will receive a copy. Mesh also introduces the concept of device "state" which can be adjusted through published messages. The new "model" concept defines a mesh node's messages, states, and behavior.

Bluetooth Mesh utilizes a "managed flooding" approach, allowing for a peer-to-peer multi-path communication network. Since there is no central hub or routing nodes, the network is more resilient to device failures. Messages are retransmitted by devices which are designated as "relays", allowing messages to reach nodes that are not in direct radio range. A message can make a maximum of 127 hops, allowing us to cover quite a large physical area. Devices contain a message cache which is used to determine whether a particular message has been seen before. If it has, the message is discarded and not processed by the stack.

Some of our mesh nodes are likely to be low-power devices which wake up periodically to relay data. Bluetooth Mesh allows us to designate "friend" nodes which are not power constrained. These friend nodes store messages intended for the low-power node. Once the low-power node wakes up, it can request the cached information from its friend. This concept of "friendship" allows us to implement an efficient wakeup schedule to conserve battery life.

Mesh nodes send out regular heartbeat messages to let us know that they are alive. These heartbeat messages allow the network to learn about its topology and help devices avoid unnecessary message retransmissions. There is also a mandatory "health" model which allows devices to send out fault information, such as in low battery or overheating conditions.

Bluetooth SIG is targeting industrial applications so Bluetooth Mesh is designed with security in mind. Every packet is encrypted and authenticated, asymmetric cryptography can be utilized, and security keys get refreshed periodically.

It's possible to utilize multiple mesh networks in the same location. Each mesh network has an identifier which indicates which network the packet belongs to. Also, thanks to the built-in security, devices cannot decrypt or authenticate mesh packets from another mesh network. Each network remains isolated from the other.

Large-scale sensor networks, asset tracking, building automation, and commercial lighting solutions are expected to be the first use cases of the new mesh networking protocol. Multiple projects that I've worked on recently will benefit from switching to Bluetooth Mesh.

More on Bluetooth Mesh:


Bluetooth Mesh SDKs

In order to build a mesh network, we need a compatible software stack. Bluetooth mesh networks require a Bluetooth LE 4.x or 5.0 which supports GAP Broadcaster and Observer roles. These roles are used to advertise and scan for advertising packets. Luckily, both Nordic and Silicon Labs have made our lives easy and provide full-fledge SDKs to support Bluetooth Mesh development.

Nordic

Nordic supplies an nRF5 SDK for Mesh. The SDK is currently noted as "alpha" quality, but you can download the SDK and start prototyping immediately.

The Mesh SDK is compatible with both the nRF51 and nRF52 processor lines. The SDK comes with example applications and models for beaconing, lighting control, and provisioning devices (including provisioning through relay nodes). The SDK allows for node-to-node and node-to-group communications and supports configurable scanning and advertising interval. It's also worth noting Nordic's excellent OTA DFU support remains in place with the Bluetooth Mesh SDK.

More on the Nordic Mesh SDK:

Silicon Labs

Silicon Labs also supplies a Bluetooth Mesh SDK. The SDK is currently noted as "beta" quality. You must create an account and request access to the SDK before you are able to download it. Silicon Labs is lighter on the describing support currently provided in their SDK, but they claim to be compliant with the existing specification and support the LE 2M and LE Coded PHYs. My SDK access request was approved within 24 hours.

More on Silicon Labs Mesh SDK:


Can't See IC Part Numbers? Try this

I learned an awesome trick from EDN's recent article "Simple Trick Lets You See Your Parts". If you need to read the part number on an IC but can't make out the details, simply apply a clear piece of cellophane tape to the part. I've used this trick multiple times in the past week, and it's extremely helpful when I'm away from a microscope.

EDN provides a great warning that you should heed:

Be careful though, as tape can generate considerable ESD, so avoid touching the actual pins of the package.

ReadingICPartNumbers

Website Updates

I've made a few updates to the website:

  • Created a new Development Kits page. Take a look if you need inspiration for your next project or want to experiment with more complex systems.
  • Added clang and Modern C++ references to Around the Web
  • Added language recommendations to Getting Started. I also removed an outdated C++ Idioms reference and added a book recommendation for developing your software career.
  • Expanded the Glossary

These were the most popular articles over the past month:

  1. Ditch Those Built-in Arrays for C++ Containers
  2. Migrating from C to C++: Take Advantage of RAII/SBRM
  3. Using A C++ Object's Member Function with C-style Callbacks
  4. Ditch Your C-style Pointers for Smart Pointers
  5. Installing LLVM/Clang on OSX