Embedded systems often require a careful eye to where memory resources are being spent, especially runtime memory utilization like stack and heap memories. This article is intended to shed some light on strategies for measuring stack memory usage on a small embedded system.
Selecting a build system is an essential decision when creating a project. Changing is always painful, especially in a mature repository. Therefore the choice should be made carefully. With this article, I will try to describe a few advantages of what Bazel can provide in the context of an embedded repository and show how to set up a build environment with a cross compiler from scratch.
Zephyr includes many built-in features like stacks for networking and BLE, Flash storage APIs, and many kernel services. These components allow you to quickly get up and running with a project and maintain less code! Taking advantage of these is a huge win for small firmware teams and was a huge motivation in bringing Zephyr to my teams. This post covers Zephyr’s built-in ring buffer API, a component commonly used in producer-consumer scenarios.
Recently, our team at Meteksan Defense is upgrading its development environment to use newer versions of many tools and programming languages. One of the more difficult transitions has been the upgrade of our C++11 code base to C++17 for our embedded applications. In this article, I will be showing some features of C++17 that can also be helpful in the embedded world. Note that the migration from C++11 to C++17 covers C++14 also, hence I will touch upon some aspects of it as well.
A core belief of Memfault is that we can ship faster when we have good infrastructure in place. An essential piece of this infrastructure is tools to send firmware updates over the air. It enables the team to ship more often and spend more time building features. In this article, we look specifically at what is required to ship over-the-air firmware updates for Linux systems. A good OTA setup should allow you to quickly prepare updates and ship them with confidence.
Separate “debug” and “release” builds are very common in embedded development. Typically the notion is improved debug capabilities (less aggressive compiler optimizations, more debugging information like logs) vs. highly optimized and hardened production release builds. I’m here to describe disadvantages to this practice, and why it might make sense to consolidate to a single build! Like Interrupt? Subscribe to get our latest posts straight to your mailbox.
Stack overflows have notoriously plagued the development processes. They often can go undetected and can present themselves in obscure ways. We have implemented software mechanisms to protect against them, but these have limitations and still don’t protect against all conditions. With the maturity of the ARM architecture, wouldn’t it be better to have a fool-proof mechanism for detecting overflows?
IoT devices have become ubiquitous. Given the number of new devices being deployed all over the world and far from the desks of developers, it is imperative to have a solid set of tools to manage them without being directly connected to them via JTAG, USB, or SSH. The necessary tasks in the IoT device lifecycle include device deployment and management, remote monitoring, and over-the-air (OTA) software updates.
Lua is one of the many great interpreters that can be run on embedded devices. It’s fast, uses little memory, is written in ANSI C, and is known by plenty of developers. These are a few of the many reasons why the team at Panic chose to include a Lua interpreter on their Playdate device and allow games to be written in it. You can think of Lua as an alternative to the MicroPython (Python) or JerryScript (Javascript) interpreters. However, there’s a problem.
This article provides a few tips and tricks for diagnosing ccache misses, to keep your C/C++ build nice and snappy!
