Bluetoe, a C++ Bluetooth Low Energy Stack Bluetoe is an open source, C++ Bluetooth Low Energy stack for writing resource constrained peripherals. After a short introduction into the basic protocols of Bluetooth Low Energy, I will present the design goals of Bluetoe and design decisions made. The declarative approach to define a Bluetooth GATT server allows for an efficiency unreached by traditional C approaches, both in terms of memory and CPU usage. Based on some implementation details, I will show you how this efficiency is reached and how design decisions made allow for easier and less error-prone usage of the library. Bluetoe applies a lot of the template meta programming stuff, that was talked about in the last years.

Unit Tests for embedded software in practice

Unit tests often don’t get enough attention during development of embedded systems. There are a lot of myths, that this kind of tests are not suitable for embedded software, such as that the ratio between overhead and benefits for developers is low or the tools are expensive. Surprisingly those myths are taken as excuse not to test the software from the beginning of development. Instead, first tests are often made as black box tests

later, when the hardware is available. Such an approach leads to a long feedback loop and fear for code refactoring. Which leads to a poor software quality.

During this seminar you will see how unit test can be done for embedded software from the very beginning of development. You will be able to gain an experience for running tests off-target as well as how to cross compile them to run on the target hardware (on-target).

Dealing with performance

Software Performance plays a critical role in almost all embedded projects. Faster code yields better response rates and increased system output. It also lowers energy consumption and makes cheaper hardware feasible. Surprisingly, in this domain little attention is given to the mapping between source code parts and their resulting performance. Unfounded prejudices, e.g. against certain modern C++ language features, dominate discussions and prevent urgently needed innovation in the area of embedded software engineering. At the same time MCU features such as caching and pipelines make it increasingly difficult to judge runtime performance – even when considering the assembly output.

This presentation shows an engineering-based method to measure code performance for embedded microcontrollers. Cycle-precise results allow for well-founded discussions on the applicability of language, library or design features in question.

barebench.com – a web-based service to measure code performance for embedded microcontrollers. Without special hardware

Building hardware

Tamoggemon Holding k.s. recently finished work on a large-scale embedded Linux project to provide information from vehicles. This talk would introduce a variety of topics interested to people interested in professionalizing systems based on RaspBerry Pi and Co, and who want to learn more about the hardware side of things. Topics covered would range from PCB prototyping to getting manufacturing done. Furthermore, the talk would also at things which did NOT work out well...

USB for the Masses

In the darkest timeline of Bare Metal Engineering the usage of USB is a ungraceful hassle. Every Chipvendor implements own Libraries that work different and need many lines of code for even smallest ideas. Why can‘t developers just say „i want a serialport over USB“? Why must it be easier and less frustrating to use specific chips for this purpose? This talk will show in what situation we are living, what can be done better and shows POCs with C++ on this specific topic to prevent this timeline to stay the darkest one.

Deadly Sins of Development that Lead to Vulnerable Devices Mirai and BASHLITE malware infected more than one million embedded devices. These infected devices were involved in several Distributed Denial of Service Attacks (DDoS) with a record breaking capacity of up to 1.1Tbps. In this talk we are going to have a closer look at commonly done mistakes that lead to such kind of vulnerable devices. We will demonstrate these mistakes utilizing real life examples including a live demo and in-depth analysis of a printer malware.

Furthermore we will introduce some open source tools used by security researchers to identify vulnerabilities

Understanding dynamic linking on GNU/Linux

Dynamic linking is a valuable tool to share code between multiple applications and to load code at runtime. It is heavily used in GNU/Linux systems. Modern build tools make it very easy to use existing shared objects or to build and install new ones. But what exactly is inside a shared object? How is it loaded at runtime? And what is the ld.so? Dynamic linking can be used without knowing the answer to any of these questions. But a deeper understanding of dynamic linking can be very valuable when one has to debug problems with shared objects. Knowing how the linker works is also important when one wants to build an embedded linux distribution or needs a dynamic plugin system for an application.

Dynamic Memory on Embedded Systems

Dynamic memory allocation is a feature that is often taken for granted. Most developers use some form of new or malloc every day, usually without worrying too much what goes on behind the scenes. But not so on the embedded world, where the usual mechanisms are often not available, be it for reasons of performance, safety, or due to restrictions of the target hardware. In this talk we will explore how custom allocators can be used to overcome those issues. We will motivate why one would actually want to use dynamic memory in embedded software in the first place and discuss different techniques for making it work. We will explain how basic allocation techniques like pooling and monotonic allocation behave with regards to performance and reliability. We will take a look at some of the technical challenges behind allocators, like the different forms of alignment and the way that the standard library manages stateful allocators.

Fixed-point Numbers on Embedded Systems

While floating-point arithmetic is remarkably versatile, the silicon and energy costs can be up to ten times those of fixed-point. Many of the reasons to favour floats went away with the advent of C++11 and with C++20, fixed-point is truly ready for the lime light. This talk will demonstrate how types in the CNL library can help you make the best use of computing resources on any hardware. Much of the talk will be devoted to exploring the design trade-offs necessary to maximise efficiency on constrained systems.

It will include generally-useful techniques for improving code safety that don't compromising the run-time.

Bringing Compute to Embedded Hardware with SYCL

Computer Architecture is constantly evolving and is becoming increasingly heterogeneous to support the need for ever more performance and lower energy consumption. This does not stop at the embedded domain: Emerging technologies such as machine learning and computer vision and autonomous and assisted driving require huge amounts of computing power that is only affordable through specialized silicon on low power devices. This has lead to the development of new programming models and industry standards for heterogeneous programming. SYCL is an open standard from the Khronos Group that allows developers to write standard C++ code which can then be offloaded to a range of accelerator devices including GPUs, DSPs and FPGAs. This talk will present the SYCL programming model and cover how to execute code on an accelerator. It will also put the technology in a wider context and explain the influence on the C++ standard and its role for Machine Learning on embedded hardware.

How to find the right amount of abstraction for hardware

In every Embedded Project you must answer the question: Which drivers do I use? And if your application should be programmed in C++ or even in UML, using code generation, this question is even harder, because most available drivers are written in C and wrappers will be necessary. If there are C++ Drivers available, they often use advanced Template Metaprogramming, what could be a sticking point if C++ is new for the team. This Talk explores different ways of abstracting hardware, using different language-features and provides benchmarks in performance and ease of use.

Embedded Programming with Modern C++

Course Description

##################

One of the design goals of modern C++ is it to be the better programming language for embedded and system programming. What does that mean? I show

you in my class how modern C++ addresses safety-critical systems, deals with high-performance requirements and manages limited resources.

Prerequisite

############

Participants should have a basic knowledge of the C++ language.

You will get in return the training material consisting of the presentation, the exercises, and the solutions to the exercises.

Course Topic

############

Safety Critical Systems

- Unified initialisation

- Strongly typed enums

- User-defined literals

High Performance

- Type-traits

- constexpr

- Associative containers

Reduced Resources

- Move semantic

- Memory management

- Smart pointers

Interrupts and how to handle them

There are two major hurdles when it comes to C++ in a bare metal embedded environment: time to hello world (getting everything set up) and the time domain itself (latency, race conditions etc.). In this workshop, we will go from nothing to a simple program with common tools reflecting on the design decisions of big-name vendors along the way. I hope to greatly reduce the time to bug discovery of the most common bugs I have seen in this domain.

Bare-Metal-Roadmap

Through the much-hyped advent of Industry 4.0 and IoT, billions of new bare metal devices will be connected to the internet or intranets and will be expected to talk to each other, even across company boundaries. This presents a plethora of new challenges, many of which share a common root; it is crucial that we build a foundation for code reuse and encapsulation of expertise in this domain. What does cross-platform code really mean when we are targeting thousands of 'platforms'? When encapsulating expertise, we implicitly make assumptions about user code and user code implicitly makes assumptions about library code. What are valid assumptions? What is the basic interface? In this talk I will present a possible future for bare metal development which attempts to answer these questions.

A possible future of resource constrained software development

Sometimes a problem is tough enough to merit a reevaluation of the very tools and methods which fail to solve it. After all concurrency did not end up being about locks and speed did not end up being about saving copies in other domains. Looking at our domain and our problems it would seem a contrarian view of the state of the art is long over due. In this talk we will explore some lesser known paths around the locking, register corruption, stack overflow, heap overflow, testability and latency related problems which make programming in our domain so tricky and error prone. I hope to present a clear vision of how I would like the future in our domain to look like.

Building embedded devices with KiCad

When developing embedded software, you sooner or later reach the point where no off-the-shelf hardware is available, the clutter of the jumper wires becomes confusing or the components are too tiny for a wiring pen. A self-designed circuit board is a remedy and can be built without prior knowledge with manageable effort and at low cost. This workshop shows how to proceed and what you have to consider. In the last years the open source software "KiCad" has become very popular, therefore it will be used to demonstrate the process from circuit design to the finished PCB layout. All relevant issues will be addressed, including RF, EMI and power dimensioning to develop an add-on board for a microcontroller development board. Each participant will create his own board during the workshop, so please bring a laptop with Kicad (version 5) installed.

C++ as API for Small Real-Time Operating Systems

Before C++11, C++ provided only very minimal operation system interaction (IO streams). With C++11 a story started to provide more C++ standard interfaces that interact with the operating system. C++11 started with threading and some synchronization, C++17 added filesystem and C++20 might add minimal executors. With C++23 full executors, networking and timers are expected. Many small realtime and embedded operating systems don't offer as much. So the chance is that in the not too far future you can write your full small embedded application in pure standard C++. The benefit of doing so is that your application will run on the development host without much effort for much easier testing and debugging. This presentation will look at the current state and what's still missing to implement your ISRs in standard C++. And it shows some concrete mappings of the relevant C++ interfaces to existing realtime operating systems.

Testing and Qualification of Optimizing Compilers for Functional Safety

In the development of embedded applications, the compiler plays a crucial role in the translation from source to machine code. If the application is safety-critical, functional safety standards such as ISO 26262 for the automotive industry require that the user of the compiler develops confidence in the compilers correct operation. In this presentation we will discuss the requirements of ISO 26262 on tools such as compilers and how they can be met with a testing procedure that works well with the V-Model of engineering. As the name implies, functional safety standards deal with specified functionality of components. But what about the optimizations that a compiler applies to the program, sometimes even silently? Optimizations are not even mentioned in the language standards for C and C++ - they are "non-functional" behavior of the compiler. As we will demonstrate, ignoring optimizations will lead to significant holes in the compiler's test coverage. We will show how we have developed a technique that achieves good results with optimization testing and have some errors in Intel's well-regarded ICC compiler to show.

"The Subtle Art of Debugging - A software engineers’ daily job he was never trained to do"

It's odd how debugging is not taught in any curriculum, yet we are all expected to do it every day. In this talk I will dig into the daily work of software engineers, look for structure to this common process that we all deal with. We will have a look at common advice and I will go through the steps that helped me do my job in the last 15 years.

C++ for C Programmers

A brief introduction

Embedded programming with the hwcpp library

Workshop introducing his Library hwcpp

Poor man's meta classes

Herb Sutter pitched the idea of meta classes within the domain of C++ in 2017. The influential paper is founded on the idea of combining new reflection capabilities and a new way to construct parts of a type. With these feature in place, generative programming should look more like regular imperative C++.

In the absence of those new language features this talk will show generative programming techniques that are possible with today's compilers. Guided by examples from the paper we will establish a toolbox of common operations for declaring and processing type information using kvasir mpl. Some of those examples will be taken from software frameworks used for low cost and low power IOT control units recently released in products by Siemens.

We will provide a introduction to the terminology connected with Undefined Behavior in C++ and explore the differences between run time errors and undefined behavior. The presentation will focus on Undefined Behavior from the perspective of a developer rather than a compiler designer. As developers we may need to assume that all Undefined Behavior is treated as if the code was not present. Whereas many talks focus on what current day compilers actually do, our talk will explore what an "evil compiler" is permitted to do.

Refactoring C++ Using LibTooling

Keeping a large codebase nimble is hard work, and therefore often neglected or not even attempted. By using clangs libTooling, the laborious task of refactoring can be fully automated, and distributed as tools to your users.

In this talk I'll give an introduction into using C++ as a live-at-HEAD language, in which old features are regularly deprecated, while automatically moving the codebase along. Each "breaking" code change will be accompanied by a tool which replaces all occurrences of the old API with their new counterpart, similar to clang-modernize.

The resulting tools can be build as static, dependency-free executables. This allows to distribute the tools to your end-users, making the technique not only viable for internal APIs, but also for public API changes.

The presented methodology has been battle-tested in a medium sized codebase for the past year, drastically reducing the turn-around time for API changes. Most of the examples shown in this talk are tools I've previously built.

Accelerating C++ Development Tools Through Process Virtualization

Waiting for development tools to run and build is a complete waste of the developer’s time.

In this session, we will explore tips for speeding up your daily C++ activities, using parallel processing and distributed computing.

We will examine advanced technologies as process virtualization and hooking that can accomplish distributed processing in a generic manner

Undefined Behaviour is not an error

We will provide a introduction to the terminology connected with Undefined Behavior in C++ and

explore the differences between run time errors and undefined behavior. The presentation will focus on Undefined Behavior from the perspective of a developer rather than a compiler designer. As developers we may need to assume that all Undefined Behavior is treated as if the code was not present. Whereas many talks focus on what current day compilers actually do, our talk will explore what an "evil compiler" is permitted to do.

Rust combines low-level efficiency on the same level as C and C++ with many of the high-level comforts of a modern programming language, as well as a focus on safety and reliability. This makes Rust a prime alternative to C and C++ in the embedded space, down to the smallest microcontrollers. In this hands-on workshop, we'll run a simple Rust program on an ARM Cortex-M microcontroller (NXP LPC82x). We'll learn how to use the libraries and tools in Rust's embedded ecosystem to build the basic support libraries for a microcontroller, and how to write programs and libraries to target it.

We'll start at the beginning. Prior knowledge of Rust is certainly helpful, but not required. Development boards are provided, but please bring your laptop.

An address of a homepage, blog or something like this, where the audience can find more info about you or your job

Building embedded devices with KiCad

Now that the heavy work in KiCad is done you'll probably want to hold the project in your hands as soon as possible. Unfortunately a lot of things have to be organized. This talk will give a deep insight into the different aspects of sourcing your prototypes and small series. From PCB and stencil over parts to the actual assembly. After this talk you’ll have a fundamental knowledge on how to get your prototype build in the first run.

Freestanding on the shoulders of giants

Last year at EmBo++ Ben Craig presented the first of his “Freestanding proposals”. A proposal to move the freestanding implementation as defined in the C++ standard to some-thing that is actually useful. Since then, work has continued on the broader scope of whatfreestanding is, but implementations of the proposal has been scarce.This talk focuses on the development of the freestanding library as proposed in P0829 in GCC for the AVR microcontrollers. The AVR is chosen partly because there currently is no standard C++ library for it and partly because it is a very popular microcontroller due to the Arduino platform. GCC libstdc++ currently has freestanding implemented and this is used for the basis of the implementation. The proposal only adds to the current freestanding implementation, and all parts of the proposal are already in the hosted library so just tacking it on should be simple. . . one should think. After this talk, you will have a better understanding of what P0829 is, how it can be implemented using GCC and why it is useful. You might even get inspired to help the effort yourself.

Rust combines low-level efficiency on the same level as C and C++ with many of the high-level comforts of a modern programming language, as well as a focus on safety and reliability. This makes Rust a prime alternative to C and C++ in the embedded space, down to the smallest microcontrollers. In this hands-on workshop, we'll run a simple Rust program on an ARM Cortex-M microcontroller (NXP LPC82x). We'll learn how to use the libraries and tools in Rust's embedded ecosystem to build the basic support libraries for a microcontroller, and how to write programs and libraries to target it. We'll start at the beginning. Prior knowledge of Rust is certainly helpful, but not required. Development boards are provided, but please bring your laptop.

There are a lot of common mistakes, in real life embedded software development. These mistakes can result in inefficiency, in bad design, in unmaintainable code and as a worst case, in crashes. The presentation wants to highlight these common mistakes and shows solutions for these all day problems. The presentation will contain at least multithreading and its missunderstanding and missues. It will turn the view to ways how multithreading can be efficiently used and when multithreading does not

help at all. Another part of the presentation focuses on new development concepts, that comes with the (not so new) c++ standard beginning with c++11. The new introduced patterns presents a new art of design thinking. Traditional object oriented design pattern e.g. from Java are exchanged by more efficient ones and show the way to future development in embedded systems.

Type based allocation

Allocators have been subject to a tradeoff between either flexibility or fragmentation and runtime. The goal is to create an allocator that can allocate multiple types without the typical overhead of a heap allocator. Is such a thing even possible? Yes it is! With the development of new metaprogramming tools an option has surfaced: the use of the type system to create more efficient allocators. So, how do you create a type based allocator? How much do you actually stand to gain from it; will we get our cake and eat it too? This talk will be covering the design and implementation, use cases, and future possibilities of a type-based allocator, along with all the challenges that come with it.

Transducers allow us to express composable transformations on sequential inputs, in a way that is completely independent of the input source. They can later be applied eagerly or lazily over collections (pull-based iterators), but most interestingly, they can also transform ephemeral reactive, push-based, sequences, like network streams, inter-process channels or reactive observables (e.g. RxCpp [3]).

Transducers provide an elegant decoupling between the "what" and the "how" of transforming sequences of elements or events, allowing for high reuse. But as we'll see, their implementation is very simple and has excellent performance. They are, indeed, just simple high order functions, and can be combined using normal function composition.

Transducers were introduced in Clojure by Rich Hickey [2]. While I was working at Ableton I implemented them in C++, and we released them as part of the Atria [1] open source library. It is maybe suprising how smoothly concepts from Lisp-based languages translate to C++, thanks to the power of generic lambdas. Our implementation introduces innovations of its own, like implementing state-full transducers without mutation, enabling further safety and reusability.

In this session we will introduce the concept of transducers and how they can be implemented in modern C++. We will also cover some of the most interesting use-cases and implementation details.

Deeply-embedded systems are often implemented in C instead of C++. Therefore, software developers forgo the C++ benefits of a strong type system, object-oriented programming and templates. One reason for this is insufficient expertise in how to use C++ in this realm, and the folklore about C++ having an inherent overhead, compared to C.

This presentation shows how C++ can be used successfully in deeply-embedded systems. For the most popular C++ language features, we analyze whether or not they incur an overhead in the executable code, and if yes, how large it is. The outcome is a useful subset of C++ language features that is suitable for use in deeply-embedded systems. We also report from our own experience in converting a large, operational, deeply-embedded code base from C to C++.

Modular Code Generation with lbuild

This is a short walk-through of lbuild, a modular Python3 code generator, focussing less on the technical aspects, and more on how we use it.

I'll gently introduce you to the benefits of code generation and then show you a few examples how modm uses lbuild to generate a HAL for almost 1000 microcontrollers.

lbuild: github.com/modm-io/lbuild

modm: modm.io

Talk: Data-driven HAL generation with modm

This talk explores how to use the modm library to generate a Hardware Abstraction Layer (HAL) for ARM Cortex-M microcontrollers written in C++. We will start with the boot process, describing commonalities and differences in the startup and linkerscript of the entire STM32F* device family, and continue our journey by setting up the clock and GPIO system and end on configuring more complex peripherals such as UART. Throughout we will discuss how you can use modm's templating system and device data to port a HAL to hundreds of devices and how you can use C++ to create very lean and efficient peripheral access.

Enable C++ multithreading in FreeRTOS.

FreeRTOS is a popular embedded OS written in C with all the burden of managing handles and void pointers. I have seen many projects trying to wrap this OS in custom C++ classes, have seen many questions why std::thread does not work on a bare metal system and only few attempts to make it happen. This short talk will present a library that actually makes standard C++ multithreading interface working with this popular RTOS.

Embedded Rust in 2019

Embedded Rust has been possible since before the language had its 1.0 release, however until last year things weren't considered stable. Now that this has changed, what kind of things can you do? More importantly, what can't you do? James will give a lightning tour of what developing an Embedded Rust program looks like in 2019, how the library and tooling ecosystem is growing, the powerful guarantees and conveniences the Rust compiler provides, and why Rust is such a perfect fit for developing embedded systems.

Execution tracing and code profiling on hardware

Unit tests and code profiling in simulation environments have their limits. How to simulate peripherals? How to make sure a firmware will also run on hardware?
Instead we want to run those tests on the actual device to see what really happens. This is achievable with a debugger and hardware tracing.

I will demonstrate how to use hardware instruction tracing not only to catch hard-to-find bugs, 
but also to run code coverage and profiling tests and get all information from the target in a non-intrusive way, without any need for code instrumentation.

Know your sanitizers!

Sanitizers are a recent development in modern compilers that add dynamic checks during compilation and report on erroneous behaviours during execution. We will look into the different sanitizers shipped with the current Clang/LLVM release such as the address sanitizer for detecting memory errors, the memory sanitizer for detecting unitialized reads, the UBSan for detecting undefined behaviour, as well as the thread sanitizer for detecting data races. Sanitizers play an essential role in fuzzing by crashing early as soon as the input is not handled correctly. But you can also benefit from them by building the debug version or running your test suite with sanitizers.