Operations | Monitoring | ITSM | DevOps | Cloud

Building a custom Linux OS for a device and integrating it with an OTA update solution can be a daunting task. Meet Rugix, the easy way to build a custom Linux OS for your device with builtin robust and secure over-the-air update capabilities. Rugix is an open-source tool suite aiming to simplify the development of embedded Linux devices and enable you to focus on what provides value to your users rather than system-level details.

In this article, I walk through how the growth of internal observability tooling for an AOSP device might look like, and the variety of pitfalls one might encounter as they scale from 1s to 10s to 1000s of Android devices in the field, based off my experience talking to AOSP developers and teams, and personally as an Android app developer working on AOSP hardware.

One of the core features of the Memfault Linux SDK is the ability to capture and analyze crashes. Since the inception of the SDK, we’ve been slowly expanding our crash capture and analysis capabilities. Starting from the standard ELF coredump, we’ve added support for capturing only the stack memory and even capturing just the stack trace with no registers and locals present.

Monitoring IoT applications is essential due to their operation in dynamic and challenging environments, which makes them susceptible to various operational and connectivity issues. Application Performance Monitoring (APM) is the key to identifying and resolving these issues in real time, ensuring uninterrupted data flow and functionality. Moreover, the insights gained from APM can optimize device performance, ensure reliability, and reduce operational costs.

This guide provides instructions for setting up an environment for developing, debugging, and programming embedded systems firmware in the Windows Subsystem for Linux (WSL2). WSL2 provides a convenient and stable Linux development environment for working on embedded systems firmware. If you’re curious about toolchain performance, check out this comparison of firmware development environments, but the summary is that WSL2 is about 2x the speed of Windows and similar to “bare metal” Linux.

At Ultrahuman, innovation is at the core of everything we do. Our health devices, powered by the nRF52840 SoC for BLE functionality, rely on Nordic Semiconductor’s renowned wireless technology. For years, the nRF5 SDK was the cornerstone of firmware development for these chipsets, but in 2018, Nordic introduced the nRF-Connect SDK(NCS), built on Zephyr RTOS, signaling a new era for BLE applications.

While using a full-blown filesystem for storing your data in non-volatile memory is common practice, those filesystems are often too big, not to mention annoying to use, for the things I want to do. My solution? I’ve been hard at work creating the sequential-storage crate. In this blog post I’d like to go over what it is, why I created it and what it does.

In this very Memfault-centric post, I’ll be talking about how we shipped our SDK as an ESP-IDF component. This is a continuation of our efforts to make it easier to integrate Memfault into your projects, specifically targeting ESP32-based projects.

Last week, a handful of Memfolks had the opportunity to travel to Austin to attend the first ever Embedded World North America1! Embedded World NA welcomed 3,500 visitors and 180 vendors across 3 days2. While it was surely a smaller showing than Nueremburg’s Embedded World, we still wanted to quickly touch on our takeaways from the event. In this post, we will cover what we learned from the first Embedded World North America.

About a year and a half ago, I decided to take a different approach to setting up a Zephyr environment for a new project at Intercreate. Instead of using my trusty VMWare Workstation Linux VM, I opted for WSL2. I was curious to find out: Would hardware pass-through for debugging work reliably? Would all of the tooling dependencies be supported? What about build system performance?