Ivo Brandão

Brutal Reality: Hardware abstraction layers are often more trouble than they're worth Let’s address a brutal reality: Most hardware abstraction layers (HALs) in embedded systems create more problems than they solve, adding layers of indirection that hide critical timing characteristics and introduce performance penalties you can’t afford. We’ve all been there: Told to "abstract the hardware" for portability, only to discover that the abstraction layer is now the bottleneck. You can’t toggle a GPIO without going through three function calls. You can’t optimize DMA usage because the HAL hides the register details. And when something goes wrong, you can’t debug it because the abstraction layer is a black box. I’ve debugged systems where the HAL consumed 60% of the CPU budget doing nothing but parameter checking and function call overhead. I’ve seen abstractions that prevented critical optimizations like register caching or DMA chaining. And I’ve watched teams waste months trying to make their "portable" HAL work on a new MCU, when rewriting the drivers from scratch would have been faster. Real embedded experts know that true portability comes from clean architecture, not thick abstraction layers. They understand that hardware-specific code should be isolated but not hidden. They know that sometimes, the best abstraction is no abstraction at all. 🔥 What's the most disastrous HAL you've ever worked with? Share your abstraction layer horror stories below, bonus points for performance numbers that made you cry! #EmbeddedSystems #HAL #HardwareAbstraction #Firmware #EmbeddedC #LowLevelProgramming #TechTruth #EmbeddedEngineering

821

255 commentaren

That RTOS crash you blamed on code? Check your DMA buffers first. I learned the hard way. Picture this: A medical ventilator froze like clockwork every 72 hours. Debugging it felt like chasing a ghost. The system? FreeRTOS with ADC DMA. The problem? Task Control Blocks (TCBs) trashed at address 0x20001000. Here’s the culprit: → DMA buffer: 0x20000C00 (size: 1024 bytes). → DMA burst mode: 16 transfers (overran by 16 bytes). → Result: TCB’s stack pointer corrupted → task deletion → system deadlock. The brutal truth about DMA corruption: ✅ Debuggers halt the CPU, but DMA keeps running. ✅ MPUs often exclude peripheral regions. ✅ Stack analyzers don’t check DMA boundaries. Invisible, right? 💀 Here’s how we fixed it: → Dedicated MPU region for DMA buffers: ```c MPU->RBAR = 0x20000C00 | MPU_REGION_VALID; MPU->RASR = MPU_SIZE_1KB | MPU_NO_ACCESS; ``` → Added hardware flow control (DMA request/acknowledge). → Memory guards (0xDEADBEEF patterns) around buffers. Lesson learned: Your RTOS is only as safe as your DMA configuration. Now I’m curious-what’s the weirdest RTOS crash you’ve debugged? Was DMA silently wreaking havoc? #EmbeddedSystems #RTOS #Debugging #DMA #Firmware #Engineering

232

43 commentaren

Here's an uncomfortable truth that will trigger many developers: Dynamic memory allocation has absolutely no place in 95% of embedded systems, and engineers who use malloc() in production firmware are playing Russian roulette with system stability. We've all seen it, projects where malloc() and free() are sprinkled throughout the codebase like confetti. Then come the late-night debugging sessions, hunting down memory leaks that only appear after 47 hours of operation, or mysterious crashes caused by heap fragmentation that suddenly leaves your system unable to allocate a critical buffer. In resource-constrained environments, deterministic behavior isn't just a nice-to-have, it's a requirement. Every call to malloc() introduces non-determinism that can't be tolerated in systems that need to run reliably for years without rebooting. I've spent weeks of my life tracking down heap corruption issues that manifested as completely unrelated failures. These problems are notoriously difficult to reproduce and even harder to diagnose. The most robust embedded systems I've worked on used static allocation or carefully managed memory pools with fixed-size blocks. What we need is a return to engineering discipline, understanding our memory requirements at design time, allocating appropriately, and accepting that in the embedded world, the convenience of dynamic allocation comes at an unacceptable cost. The next time you reach for malloc() in your embedded code, ask yourself: Am I solving a real problem, or just creating a future nightmare for myself or some other developer? 🔥 Defend or condemn: Is malloc() EVER acceptable in safety-critical embedded systems? Drop your stance and one concrete example below, let the debate begin! #EmbeddedSystems #Malloc #MemoryManagement #Firmware #EmbeddedC #StaticAllocation #SoftwareReliability #LowLevelProgramming #NoMalloc #EmbeddedEngineering

499

261 commentaren

Debugging Live Embedded Systems? Stop Crashing Them. Traditional tools (printf, breakpoints) sabotage production devices by disrupting timing-critical operations. Want to observe behavior without altering it? → Deep dive into non-intrusive tracing techniques in my latest article: https://lnkd.in/gp4agUZA 3 Techniques That Fix What Intrusive Tools Break: 1️⃣ Hardware Tracing (ETM/PTM): Capture every cycle with zero overhead. 2️⃣ RTOS-Aware Tools (Tracealyzer): X-ray task collisions & ISR bottlenecks. 3️⃣ Lightweight SW Tracing: Log silently to RAM; extract via debug probes. Real-World Rescue: A medical wearable crashed randomly in-field. Intrusive tools made it worse. Solution: ETM tracing + Tracealyzer exposed a deadly priority inversion. Result: Fixed in 48 hours. $2M recall avoided. Need Engineers Who Master Non-Intrusive Debugging? At RunTime Recruitment, we source experts who: → Slash debug time on live systems (ETM/SWO/SEGGER), → Solve timing ghosts in RTOS & multicore environments, → Ship reliable systems, not fire drills. Hire Embedded Talent Who Debug Like Surgeons → DM me or book a call https://lnkd.in/gY55GDjS Explore the full case study & techniques: Read the Article - https://lnkd.in/gp4agUZA #EmbeddedSystems #Firmware #RTOS #DebuggingSavesLives

30

9 commentaren

FPGA engineers are among the most technically gifted people in engineering, often sitting at the intersection of hardware, low-level software, and performance optimization. Many FPGA experts are working on incredible projects in aerospace, defense, telecom, or automotive, but haven’t explored the world of HFT and electronic trading, where their skill sets are directly transferable, and hugely valued. In trading, the hardware isn’t just a support function, it’s the competitive edge. Latency is measured in nanoseconds, and every FPGA design decision can impact millions in daily PnL. Here’s why I think a move into the trading industry can be a game-changer for FPGA engineers: ·        Impact – Your work directly influences real-time performance and trading outcomes. ·        Compensation – Packages in top HFT firms often far exceed traditional engineering sectors. ·        Technology Freedom – Small, elite teams using cutting-edge boards, NICs, and custom toolchains — minimal bureaucracy, maximum performance. ·        Environment – Surrounded by software and hardware engineers from the world’s best quantitative firms, all pushing limits of what’s possible in hardware acceleration. If you’ve ever wondered what it’s like to apply your FPGA expertise where every nanosecond counts, the HFT space is worth a serious look. #FPGA #HFT #Engineering #Hardware #LowLatency #Trading #Careers

229

3 commentaren

Let's have a look at the position of Firmware Engineer in Semiconductors. I’ve noticed that this role is often somehow misunderstood. In simple terms, a Firmware Engineer in Semiconductors is responsible for developing the low-level software that controls hardware components in semiconductor devices. So what is firmware? Firmware is a type of software that is embedded directly into a chip or microcontroller, enabling it to function correctly within a system. Some of the key parts of this position: * They write and optimise firmware. A firmware engineer creates code that interacts directly with hardware, ensuring that chips, processors, or embedded systems operate efficiently. * Another part of the job is debugging and testing firmware. They troubleshoot and optimise firmware to improve performance, power efficiency, and reliability. * And last, but not least their work ensures that semiconductor devices can communicate correctly with other system components, such as sensors, memory, or networking interfaces. When searching for Firmware Engineers, these are some of the misconceptions I have seen over the years: 1️⃣ "Firmware is just software." → Firmware runs closer to hardware, often without an OS, Needing a strong understanding of the limits and capabilities of the hardware. 2️⃣ "It's just about writing code." → Debugging, optimisation, and hardware collaboration are just as important as coding. 3️⃣ "Any software engineer can do it." → Firmware requires low-level programming, memory management, and hardware knowledge beyond standard software development. From my experience hiring firmware engineers, the biggest mistake I see is assuming that any software developer can do the job. But the best firmware engineers aren’t just good coders. They understand how hardware and software interact at a deep level. They know how to optimise for power efficiency, debug complex low-level issues, and work within the constraints of memory and processing power. When hiring for these roles, I’ve found that focusing on hardware experience, embedded systems knowledge, and problem-solving skills makes all the difference. A firmware engineer doesn’t just write code, they ensure the entire system runs smoothly and efficiently.

385

23 commentaren

C++ memory management is often the Achilles' heel in embedded systems development. Many teams still overlook the intricacies of dynamic memory allocation, leading to unpredictable behavior and hard-to-trace bugs. For instance, consider a firmware application that allocates memory without proper checks. A memory leak can cause crashes during critical operations, compromising safety and performance. The challenge lies in enforcing best practices, like using smart pointers and limiting dynamic allocation. This isn’t just about avoiding crashes; it’s about building robust systems that perform consistently under pressure. Are your engineers employing RAII (Resource Acquisition Is Initialization) principles effectively? - Are they aware of the consequences of heap fragmentation? - Do they properly manage lifetimes of objects? - Are they using tools to detect memory issues during testing? Ignoring these details can lead to catastrophic failures, especially in automotive or medical applications where reliability is paramount. The industry often underestimates the importance of rigorous memory management, leading to costly recalls or safety incidents. Practical takeaways include: - Prioritize static allocation where possible. - Conduct regular code reviews with a focus on memory usage. - Implement automated testing for memory leaks. In the end, a culture that values meticulous memory management can set your team apart. Curious how your hiring process stacks up against top embedded teams? I’ll benchmark it in 10 minutes. DM me — or book a quick 15-min call here: https://lnkd.in/grmaYWmg #EmbeddedSystems #MemoryManagement #C++

12

Building safer, cleaner embedded code just got easier for Zephyr RTOS developers Zephyr RTOS now offers native support for IAR C-STAT, making it easy to run Static Code Analysis (SCA) directly in the west build system, no hacks or extra scripts. With this integration, you can: +Catch bugs early +Prove compliance with MISRA & CERT +Seamlessly integrate into CI/CD Learn how to enable C-STAT, part of the IAR platform, in Zephyr’s west builds, and ship reliable, standards-compliant software faster in our latest blog: https://lnkd.in/dfmgpVg9 #ZephyrRTOS #StaticCodeAnalysis #MISRACompliance #EmbeddedDevelopment #SecureCoding #EmbeddedSystems

49

Last week, Bootlin engineer João Marcos Costa delivered our popular "Embedded Linux system development" training course on-site in Germany for Mobileye! Thanks to this training course, participants could learn about: 👉 Embedded Linux architecture 👉 Cross-compilation toolchains 👉 Booting embedded platforms: bootloaders, TF-A, OP-TEE 👉 Linux kernel configuration, build and booting 👉 Linux root filesystem architecture 👉 Accessing hardware in Linux: kernel drivers, Device Tree, etc. 👉 Filesystems for block and flash storage 👉 Cross-compilation and build systems such as Yocto or Buildroot 👉 Developing and debugging user-space applications

124

8 commentaren

Not every function belongs in an FPGA. And not everything should be left to software. When you’re architecting an embedded system, one of the first questions you should ask is: What belongs in the FPGA? And what’s better left to software? Here’s how to think through that decision. #fpga #fpgadesign #embeddedsystems #embeddeddesign #embeddedengineer #embeddedsoftware #embeddedhardware #systemdesign

29

MCUViewer 1.2.0 is here! 🎉 The long-awaited release is finally out - and it’s a big one. This version introduces the recorder module, built to capture and visualize high-speed signals even on low-cost MCUs like #M0, or in situations where your SWD bandwidth is limited. And yes - #MacOS is now fully supported! Just run the installer and start analyzing your embedded target! Apart from the technical improvements, there’s also an important update I want to be transparent about: 👉 MCUViewer is transitioning from open source to a closed source model, with a free mode for non-commercial use. Why? Because building and supporting tools like this takes time - and I want to keep improving it with features that actually help you move faster. But don’t worry! The free version lets you test all features with no time limit, just with a few usage restrictions. It will always stay free for hobbyists and makers. 📬 Sign up for the newsletter at mcuviewer.com so you don’t miss what’s next! #MCUViewer #Debugging #Firmware #PowerElectronics #MotorControl #LLC #PFC

105

3 commentaren

C++ in Embedded Systems: A practical transition from C to modern C++  by Amar Mahmutbegović — is your go-to guide to elevate code readability, maintainability, and performance in real-world firmware projects.   This practical guide empowers you to: 🔺 Debunk myths about C++ in embedded systems 🔺 Set up build automation in resource-constrained environments 🔺 Use strong types to improve type-safety 🔺 Apply techniques like Resource Acquisition Initialization (RAII) 🔺 Leverage Domain-Specific Languages (DSL) with Boost SML 🔺 Adopt software best practices like SOLID for embedded applications Who this book is for: This book is for embedded developers who primarily use C and want to adopt a modern C++ approach. It covers fundamental C++ concepts, making it accessible to beginners, while assuming basic familiarity so that you can fully leverage advanced features like compile-time computation. Even those with some C++ background will learn new ways to apply modern best practices, resulting in more efficient and maintainable embedded applications.   📖 Pre-order now on Packt or Amazon — print or Kindle purchase includes a free PDF eBook 🔗 Packt: https://lnkd.in/d4NZBtng 🔗 Amazon: https://lnkd.in/dhVUxxzm

81

2 commentaren

For Embedded Engineers considering a move in 2026, a few honest observations from the market. The strongest engineers I speak to are not the ones who know every RTOS or MCU family. They are the ones who can explain why a system was architected a certain way, how they handled failure modes, and what tradeoffs they made under real constraints. What is coming up repeatedly in interviews right now Ownership of firmware architecture, not just feature delivery Clear experience with real hardware bring up and debugging Comfort working cross functionally with EE and Mechanical teams The ability to talk through decisions, not just list tools On the flip side, the best companies are Having engineers interview engineers Keeping technical panels practical, not academic Being clear on impact, scope, and expectations early If you are evaluating opportunities this year, focus less on job titles and more on ownership, decision making, and the problems you will actually be trusted to solve. In the end, the engineers who stand out are the ones trusted with decisions, not just code. #beUneek #EmbeddedEngineers #Embedded

323

6 commentaren

Great FPGA engineers are rare for a reason. None of them start as “FPGA engineers.” Their resumes are a mix of embedded systems, low-level software, hardware bring-up, sometimes signal processing. Titles often don’t line up. But talk to them (we love to) and it clicks fast. They’re the people teams end up needing when, latency targets start slipping timing gets unpredictable software optimizations stop moving the needle This is also why FPGA hiring trips companies up. If you try to hire for it like a standard embedded role, you miss the best candidates entirely. It’s not a niche skill, It’s a different kind of embedded engineer. And we know this because we actually have a handful of these engineers just registered from a search we ran for another company (sadly the jobs on hold for now) If you are struggling to hire for your Company I'm here to help ...

242

25 commentaren

The configuration chain is currently the most used configuration protocol for the FPGA architectures which are supported by OpenFPGA. To the best of my knowledge, it has been validated by almost 10 tapeouts. The configuration protocol is a non-negligible factor on an FPGA, which could consume >30% of the chip area. Especially the dynamic power consumed by the configuration protocol can be significant if not optimized, resulting in challenges in IR-drop when designing your power network. OpenFPGA has upgraded its configuration chain support, where users can not only customize the number of configuration chains, but also the number of programming clocks. Through the architecture description language, you can pick the configuration chains which will be controlled by each programming clock. The benefits of multiple programming clocks is significant. Assume there is only 2 configuration chain and 1 programming clock, during each programming cycle, all the flip-flops may flip (considering a worst case). If each configuration chain is controlled by an independent clock, only 50% of the flip-flops will flip, which leads to a 50% reduction on configuration power. OpenFPGA Github: https://lnkd.in/gFnjFJuk OpenFPGA Documentation: https://lnkd.in/gP5cS4AC Configuration chain description language: https://lnkd.in/gmbZtCt6

123

1 commentaar

🔍 FPGA vs ASIC: what electronics engineers prefer in 2025 - and why? One question I often get from hiring managers in Belgium: “are candidates still interested in ASIC roles - or is FPGA taking over?”. After hundreds of conversations with engineers across embedded systems, RTL design, and hardware architecture, here’s what I’m seeing - it’s not one-size-fits-all - but trends are emerging. ⚡ FPGA: popular for speed & scope - more engineers are telling me they prefer FPGA work when they want: ➡️ Faster design-test-iterate cycles ➡️ A tighter link to system-level work (e.g., embedded, signal processing) ➡️ Broader roles in smaller teams (often in medical, industrial, or aerospace) 🧠 ASIC: Still strong for depth & scale - ASIC is far from out of fashion. Many engineers still prefer ASIC for: ➡️ High-performance applications (e.g., wireless, AI, semiconductors) ➡️ Exposure to large-scale SoC development ➡️ Deeper specialization in low-power, timing closure, or physical design 💼 What this means for employers: FPGA hiring is highly competitive, especially for engineers who also bring embedded/system knowledge. ASIC roles still attract top candidates - but they’re looking for clear technical challenge, mentorship, and long-term roadmap visibility. Curious how your role compares to the market? Or struggling to fill a digital design position in Belgium? Happy to share what’s working.

19