Embedded firmware is developed on a desktop computer. Code that is not directly dependent on hardware can be compiled with a conventional desktop compiler, and executed “off-target” on the host machine. This is very useful from the point of view of efficient development. Often unnoticed, there are a several structural reasons causing differences between the host- and target binaries.
The off-target approach is often chosen for the execution of unit tests because it avoids long compile-flash-debug loops through the microcontroller. However, if these tests are not also executed on target – with potentially different results! – a purely “perceived security” could quickly result.
This talk will analyze the most important reasons for changed behaviour during compilation and execution. We will take a look into factors such as architecture-dependent properties, the compiler, runtime-libraries and build settings.
Attendees will get to know criticial factors so that they are in a better position to estimate and subsequently prevent risks in their own projects.
A real-world example from an open source project will be used to demonstrate the hidden risks in off-target unit testing.
One of the fundamental parts of modern C++ is to use the standard library. The C++ standard even provides two versions of the standard library: hosted, the one most of us know and love; and freestanding that has been passed over from C and carries the bare minimum for C++ to be C++.
Proposal P0829 by Ben Craig proposes to add the parts that are useful in C++ and can be done without going to the OS.
Keeping away from OS calls not only enables writing an OS or bare metal system in C++, it also speeds up hosted C++.
The main problem is that there hasn't been any implementations.
Like many good programming stories, this one starts with a personal itch. The avr-gcc has no standard library at all.
This is the story of hacking libstdc++ (the gcc standard library) into an implementation of a proposal and how to use this implementation.
This talk will equip you to better know what parts of the standard library to use in embedded systems and how.
Software modelling has a bad reputation in the embedded world — at least for die-hard coders. On the other hand, non-code-savvy experts in embedded domains like electronic engineers prefere approaches like Matlab/Simulink, Ascet, or similar tools because (a) they offer high-level abstractions which are close to their mental models/their way of thinking and (b) source code will be automatically generated. mbeddr (http://mbeddr.com/) covers the middle ground between both worlds. It is a set of domain-specific languages (i.e., abstractions) for embedded software engineering and comes with an excellent IDE. Based on C99, these languages offer support for physical units, state machines, and component-based development. There is also support for testing, formal verification (e.g., of state machine), requirements, requirements tracing, documentation and more. These higher-level abstractions are then translated into efficient C (for embedded targets) as well as documentation, input to validation tools and so on.
Development teams fear the investment required to add higher-level abstractions to their toolbox. They, thus, prefer to keep using C. mbeddr is an open source tool offering these abstractions with great tool support. It has been around for several years and has been successfully used in many industrial projects. However, when asking embedded software developers — amongst them attendees of last year’s Meeting Embedded — I get the impression that many are not aware of mbeddr. In my experience, using approaches that significantly raise the level of abstraction while still offering well-defined execution semantics (i.e., C in mbeddr’s case) provide many advantages over traditional approaches without the drawback of mainstream modelling approaches such as UML and SysML. [Disclaimer: I’m just an mbeddr user (for research/teaching projects), I’m not part of the mbeddr development team.]
mbeddr is also an IDE that offers modern features like syntax highlighting, code completion, type checking, navigation, quick fixes, refactorings, debugging, and integration with version control systems. Based on the language engineering tool MPS, mbeddr uses projectional editing which enables total freedom of notation (instead of relying on purely textual notations) offering much more possibilities and flexibility. Text fragments can be combined with table views or graphical (e.g., lines-and-boxes) diagrams allowing to adjust notations to users’ needs by means of domain-specific notations. Because mbeddr is based on C, users can use the C expressions they know and love in higher-level abstractions while still getting IDE support (e.g., for type checking, auto completion, refactoring). This is a major advantage compared to other modelling tools which are usually not aware of the target implementation language (C in mbeddr’s case) and, therefore, cannot offer any of the features code-focused IDEs offer — adding to the bad reputation of model-driven approaches.
Because mbeddr languages are designed to be composable, users can choose which abstractions (physical units, state machines etc.) they want to use in a project. They only have to use the abstractions that make sense for them and their project. Also, mbeddr is extensible: by adding new languages domain-/project-specific abstractions can be added which are even closer to the user’s domain/mental model than the languages and notations provided by mbeddr out of the box.
Developing for Arduino/AVR, especially, with Modern C++ is not easy, it simply requires a lot of effort to start.
In this talk, we will explore a simple project together with some of the online tools such as:
* Design: Plant UML - https://bit.ly/2GRos5N
* Development: Compiler Explorer - https://godbolt.org/z/s64s9o
* Implementation/State Machine: SML - https://github.com/boost-ext/sml
* Unit Testing: UT - https://github.com/boost-ext/ut
* Simulation: Tinker Cad - https://www.tinkercad.com/things/9epUrFrzKP3
to lower the barrier of entry for the new kind of Modern C++ Embedded Developers.
Let's get ready to `Arduino` all the things at Meeting Embedded 2020!
The exceptions mechanism is a complex topic and has been enthusiastically discussed in the last WG21 committee meeting.
In this talk we will dive into the world of exceptions.
We will start by understanding the error handling mechanism.
Next, we will see its usage as part of the program, and analyze the overhead by breaking the exceptions mechanism to bits.
Last, we will describe and analyze the alternatives, and potential directions for the exceptions mechanism in a future C++ versions.