Talks at Meeting Embedded 2018

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.

Embedded software often runs on highly safety-critical systems such as cars, aeroplanes, or medical devices. Due to this unique environments, coding guidelines play a crucial role in embedded software. Guidelines such as the well-known MISRA C++ from 2008, the newer AUTOSAR C++14, or the community-driven C++ Core Guidelines have one goal in mind: make programming with the quite challenging programming language C++ safer and more predictable.

First, I give you an overview to the three guidelines and present their pros and cons. Then, I dive more into the details of the C++ core guidelines. I believe that the C++ core guidelines are the only guidelines which stay in the long run in lockstep with the highly dynamic C++ language. This insight includes the guidelines support library, which is part of the C++ core guidelines and helps you to check your code. This insight also includes the most valuables rules from the C++ core guidelines for making your code safer.

Introducing a CI/CD pipeline to improve the quality and delivery speed of release binaries for almost any project is a must nowadays. This is no less important in embedded and IoT, where guaranteeing build reproducibility, security and process robustness is essential to update the devices. Also, setting up the compiler and toolchain, testing tools, environment variables and hardware conditionals are some of the additional pains that can be solved managing a binary pipeline.

 
Taking advantage of Conan to manage C/C++ dependencies and toolchains to create binaries for different devices, with Docker for build environment reproducibility, Jenkins to control all the pipeline steps and Artifactory as a powerful binary storage solution, can definitely boost the automatic distribution of trusted software releases for embedded and the IoT. This talk will present all the necessary pieces and how to integrate them in a full demo.

The Beagleboard X15 is a relatively low-cost single-board computer with a single TI AM5728 SoC featuring 12 processor cores running four different ISAs. In this talk I will talk through the design of the AM5728, and how the RemoteProc Linux kernel driver can be used to communicate between the primary cores that run Linux, and the subsidiary cores running bare-metal code. I will then introduce the Rust programming language and demonstrate it's applicability to embedded software development by demonstrating a Rust Linux application communicating with a bare-metal pure-Rust application running on one of the Cortex M4 subsidiary cores.

Many Developers of Bare-Metal-Systems are using low-level commands to implement their programs. Often without type-safety or by using other techniques that are more than 20 years old. Code-size is often mentioned as the main reason to implement it this way. This Talk provides examples of what is possible with modern Hardware-Abstraction-Layers and why the future will be much less painful, faster and less frustrating.

IoT is one of the hottest buzzwords in the industry, and everyone wants to learn about it, so you decided to share your knowledge and love for the subject and create an IoT workshop.

Soon enough you discover that knowing the bits-and-bytes is only the beginning of this journey and that creating training sessions for engineers requires a different skill-set than engineering.

Since time and resources are always limited, there are decisions to be made: What are the most important building blocks that are crucial for this topic? What should the learning experience be like - theoretical, or “hands-on”?

In this talk, I will share how I addressed these issues and highlight the things which are worth considering when creating a tech workshop from scratch.

Like most comparable tracks, at the Technical Informatics specialization of the HBO-ICT institute of the Hogeschool Utrecht (Netherlands) we used the traditional sequence of first teaching C, and then switching to C++ in subsequent courses. For the C course we tried to avoid teaching things that had to be unlearned in a C++, but there are some subjects that can't be avoided (like printf and naked arrays). Last year we took the step to eliminate C altogether: after a lightweight 'introduction to programming' course in Python (that we must share with other specializations) our next course is now 'procedural programming in C++' (no OO). In this talk we share our experiences with this approach (which are so far very positive), the problems we faced, and the choices we made.

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. In this talk, I will present the vision of a small group of bare metal experts who have come together to fundamentally rethink the entire technology stack, best practices, and paradigms we use to program bare metal systems. 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.

Beginning of 2018 the version 5 of the MQTT protocol standard has been published. As client and server implementations are about to get released by various providers, it is time to dig into the new features and changes within this version.

Most prominently the new concepts of properties, topic aliases and enhanced authentication will be discussed, before going into some tips and tricks when dealing with publish and subscribe patterns.

After a comparison with other pub/sub protocols, the session will end presenting an overview of existing clients and servers providing MQTT5.