Jonathan Velez

Here's an uncomfortable truth: Most RTOS implementations in embedded systems are nothing but unnecessary overhead that makes developers feel sophisticated while actually introducing more problems than they solve. We've all been there, facing a complex embedded project and immediately reaching for that "industry-standard" RTOS solution. But let's be honest: in 80% of applications, an RTOS is like using a sledgehammer to crack a nut. The context switching overhead alone can consume precious CPU cycles that your resource-constrained device can't afford to spare. And don't get me started on priority inversion issues that turn your "deterministic" system into a timing lottery. I've spent countless hours debugging mysterious timing issues only to discover they were caused by the RTOS itself, nondeterministic interrupt latency, hidden system calls, and the inevitable memory fragmentation when dynamic task creation is involved. What we really need is a return to bare-metal programming with well-structured state machines and interrupt-driven design. It's not "old school", it's engineering discipline. When your microcontroller has 32KB of flash and 4KB of RAM, every byte counts, and every unnecessary abstraction is a liability. The next time you're tempted to drop an RTOS into your project, ask yourself: Do I really need it, or am I just avoiding the hard work of designing a proper architecture? 🔥 What's the most ridiculous RTOS-induced nightmare you've ever debugged? Share your war stories below, bonus points for priority inversion horror stories! #EmbeddedSystems #RTOS #BareMetal #Firmware #EmbeddedC #RealTimeSystems #LowLevelProgramming #TechTruth #EmbeddedEngineering

2,070

306 Comments

The Silent Killer of Embedded Projects 🚨   Hi folks, 💡 “This firmware should work… but it just doesn’t.” Ever been there?   One of the biggest silent killers in embedded development isn’t bad code—it’s unpredictable timing issues.   I’ve seen projects delayed by weeks just because of an interrupt priority issue or an RTOS task starvation problem. These aren’t errors that show up in logs. They’re the kind that make you stare at the screen for hours, thinking: “What the hell is going on?”   Common culprits: 🔴 Interrupts misfiring due to priority conflicts 🟡 Race conditions when two tasks access shared memory 🟢 Cache issues in multi-core MCUs leading to stale data 🔵 Watchdog resets due to unhandled blocking operations   The worst part? These bugs don’t appear immediately. You run your firmware 100 times, and everything works fine. But on the 101st run? Boom—mysterious crash.   ✅ How do you handle timing-related bugs in your projects? ✅ What’s the worst timing-related bug you’ve ever had to debug?   Drop a comment and let’s share some war stories! ⚔️   #EmbeddedSystems #Firmware #RealTimeSystems #Debugging

81

9 Comments

Hot take: printf won't solve your firmware bugs. Neither will advanced debuggers like SWD, JTAG with GDB combo. Because printf is just a multimeter for firmware debugging. It's just a probe. That's it. What really matters is your interpretation skill. The ability to understand your system flow and state is way more important. I've seen a senior embedded engineer help his junior fix a random pointer issue. "Let me see the crash message," he said. "Here, I literally don't understand!" The junior looked frustrated. "Oh," the senior whispered. "The crash is what you get when you create a string inside a function, and return the string pointer. It won't be valid anymore." A single line tweak instantly fixed the issue. "You're a godsend! THANK YOU!" the junior was ecstatic. That's when you have strong interpretation skills. Only crash message, brief code review, BAM! Done. I also once saw a junior engineer stuck in a debugging session, countless breakpoints everywhere. He literally was using a very advanced debugger right on his desk. And yet he couldn't understand what he was doing. Again, because of interpretation skills. Printf and advanced debuggers only show you the information. It's up to you how to transform that information into insights. And it's totally on you to turn those insights into a bugfix. Your brain > your tools.

139

21 Comments

Your choice between pass-by-value and pass-by-reference reveals more about your systems engineering skills than your resume ever could... In years of embedded systems work, I've seen catastrophic failures traced back to this seemingly simple decision: Pass-by-value: "Here's a COPY of my data" ✅ • Safe: Original data remains untouched • Costly: Creates memory duplicates • Risk: Stack overflows when copying large structures Pass-by-reference: "Here's the ACTUAL data" 🔑 • Efficient: No unnecessary copying • Powerful: Direct access to original data • Risk: Can silently corrupt system state without proper guards Most web developers can get away with not understanding this distinction. Embedded engineers cannot. Some real-world examples : • A medical device that crashed during surgery because a 2KB sensor struct was repeatedly copied, causing a stack overflow • A drone that suddenly lost calibration mid-flight when a function accidentally modified the gyroscope parameters it was only supposed to read • A smart home system that intermittently failed because defensive copying created memory fragmentation The difference isn't just academic—it's the difference between shipping reliable products and chasing phantom bugs for months. Pro tip: When passing by reference, use "const" religiously to prevent accidental modifications. When passing by value, be mindful of the structure size. What's the worst bug you've ever encountered due to this fundamental choice? #EmbeddedSystems #Cpp #Cprogramming #SoftwareEngineering #Firmware #Pointers #TechLead

6,438

166 Comments

Know what’s better than a great hire? A great rehire. I was just talking to a candidate I headhunted for an Embedded Systems Engineering role. He said, “I know the company - one of my coworkers used to be there… and is going back.” That caught my attention. Turns out, his colleague worked there for 6 years, left for 2, and now? He’s rejoining the team. I love stories like this. Because people don’t always leave because something was wrong. Sometimes they leave to grow. To try something new. To stretch into a new challenge. And when they come back? They bring more experience. More skills. A broader perspective. And often, even more loyalty. I’ve seen it with engineers, with salespeople, with marketers. It’s not the same as a counteroffer. Those are usually reactive. A boomerang hire is intentional. On both sides. You already know them. They already know you. And if the timing and fit are right? It can be a win-win. So here’s the question: If one of your best former employees wanted to come back… would you say yes?

43

6 Comments

One of often-cited claims is that 8-bit microcontrollers are great for teaching early classes on embedded systems. The claim stems from the argument that 8-bit micros are simple and that complexity is bad if you are learning something. What this claim gently ignores is, that you don't have to show or use this complexity if you don't want. Now I happen to have some hard data on this. Earlier this year I started teaching class of IoT software development. It all happened in a rather ad-hoc mode. I agreed to lead these courses with just one condition: We'll ditch Arduinos which were previously used in the course into e-waste and we'll use Raspberry Pi Pico board with magnificent RP2350 microcontroller instead. Yes, we went straight to 32-bit and never looked back at Arduino IDE. Those who know me may have heard that my opinion on Arduino used in education is that its existence is something like 11th biblical punishment. Was this change just about 32-bits are better than 8-bits? Absolutely not! The aim here was to let my students to work with as real-world environment as possible while keeping the budget low. What's the difference so significant it was worth using Pico instead Arduino? The most important difference was the ability to use debugger. While Arduino got this feature a few years ago, it is flaky, supported only on some devices (which are usually not 8-bits) and the whole ecosystem mostly ignores this feature anyway (just use printf). My students have seen that the experience they have from writing desktop software is achievable on embedded devices too. They understand the principle of probe and target and know what the debugger interface is. Another aspect that I wanted to show them is that embedded development SDKs are no magic black boxes. We intentionally avoided any platform that would confine us within pre-packaged IDE and used VS Code, CMake and ARM toolchain. It is good to know that tools you work with are accessible and understandable by human beings. It must have failed you say? ARM is too complex? The result? In some 3.5 months this course ran in this form we got from zero - no prior experience with embedded development or ARM micros to working IoT application that did local measurements and communicated via wireless with server. Yes, still far from fully featured, safe and reliable embedded system. Yet you have to start somewhere. Complexity? None of programs we wrote was longer than some 100 lines of code. There's no need for it. It wasn't due to presence of a thick SDK. It was due to the fact that even the basic Pico SDK for C development offers strong functions while being reasonably thin. Do you still think that I have failed and shall teach students 8-bit and Arduino instead? Why?

619

235 Comments

Interested in learning FPGA development without spending a fortune?  If you're a junior engineer in the US looking to break into the space or aerospace industry, here’s a solid list of free tools to get started.    This list comes from FPGA engineer Josue Ortiz:  1. VS Code + Extensions  • Sigasi – powerful HDL editor  • Open SSH – useful for remoting into a server  • Tcl bitwisecook – for clean, efficient Tcl scripting  2. Intel ModelSim  • A Siemens HDL simulator  • Very similar experience to Questasim  3. Vivado  • Design software for AMD FPGAs  • Free to use with most AMD development boards ModelSim and Vivado offer a professional development environment. VS Code with Sigasi makes HDL work more accessible and enjoyable, even for those used to Vim, Emacs, or Notepad. Pair these tools with a dev board like the Avnet ZU-1CG and you're set up to build real experience. Got other recommendations?     Share your thoughts in the comments.  #FPGAdevelopment #JuniorEngineers #SpaceTechCareers 

35

4 Comments

7 numbers stand between you and a real embedded career. Most stuck engineers track 0. If I could restart, I’d track these from day one. They’re simple ratios that tell you if you’re moving up or just watching tutorials. 1. Hands-On Rate – “Am I learning by doing?” Target: 50%+ hands-on Formula: Build hours ÷ Total learning hours Example: 10 build hrs on 16 total = 62% 2. Portfolio Growth – “Is my portfolio getting deeper?” Target: +1 real subsystem/month Formula: (This month’s deep projects – last month’s) ÷ last month’s Example: 3 – 2 = 1 → 50% growth 3. Public Proof Ratio – “Can people see my work while I sleep?” Target: 50% public Formula: Public repos/demos ÷ Total projects Example: 4 public on 7 total = 57% 4. Time Expense Split – “Am I spending time with purpose?” Easy target split: • 30% C/MCU coding • 30% debug & tools (JTAG/LA/logs) • 20% datasheets, drivers, RTOS • 20% README, docs, LinkedIn post Example on 20 hrs/week: 6 + 6 + 4 + 4 5. Emergency Skill Reserve – “Can I take a hard interview today?” Target: 3–6 projects you can walk through end-to-end Formula: Ready-to-demo projects (no fresh prep) Example: UART-DMA, I²C sensor, FreeRTOS tasks = 3 6. Asset-to-Tutorial Ratio – “Do I actually own anything?” Target: 2:1 or better Formula: Owned assets (from-scratch code, labs, docs) ÷ Tutorial clones Example: 6 ÷ 2 = 3.0 7. Return on Learning – “Do my choices improve my life?” Question: Did this skill cut debug time, reduce stress, or get calls? Example: One clean FreeRTOS demo → interviews without referrals If you’re not tracking, you’re guessing. Guessing is how you stay stuck. Want these numbers to move fast? Book a slot with me. Link in the comments Comment “RATIO” and I’ll share the ratios card for you to track your numbers

24

4 Comments

Ever shipped firmware that worked flawlessly on your bench — then blew up the moment it hit real hardware? That pain is why system-level TDD exists. Most embedded teams build bottom-up. → Drivers first. → Middleware next. → Application logic last. By the time you hit “system testing,” your design is already locked in concrete. That’s when bugs turn into rewrites. Now flip that model. Start from the top. Write a failing system-level test before touching a single GPIO. Define what the entire system should do — not what one driver should handle. Here’s why it changes everything: → You can run full system tests early, in simulation or emulation, before hardware even shows up. → You validate actual behaviour — not just “does it boot?” → You can automate everything using a proper testing framework so results are consistent, measurable, and repeatable. → You still follow TDD’s rhythm — fail → code → pass → refactor — but now your design is driven by intent, not cleanup. For firmware engineers, that means: → You catch design flaws months earlier. → Your codebase stays modular and testable. → Your CI pipeline becomes your safety net — not an afterthought. Start testing from the system down, not the hardware up. Do that, and you’ll never dread integration week again. #EmbeddedSystems #FirmwareEngineering #TDD #SystemLevelTesting #EmbeddedTesting #CleanCode #CI_CD

100

3 Comments

Why 80% of engineers fail Embedded interviews (and how to not be one of them) After spending years in Embedded Systems and seeing both sides of the interview table, I’ve noticed a clear pattern. Most engineers don’t fail because they are bad engineers. They fail because they focus on the wrong things. Here are the 4 biggest reasons: 1️⃣ Shallow C knowledge – Knowing syntax isn’t enough. Interviewers test your depth: pointers, memory, volatile, bitwise, concurrency. 2️⃣ Ignoring fundamentals – People rush to RTOS, drivers, and advanced stuff without mastering basics like data structures, OS concepts, and debugging skills. 3️⃣ Theory over practice – Reading PDFs or watching lectures won’t help if you haven’t written bare-metal code, worked with registers, or debugged on hardware/simulators. 4️⃣ Lack of clarity – When asked “What is your contribution in this project?”, many can’t give a crisp, confident answer. That’s a red flag. 👉 So, how do you NOT become part of this 80%? Get your C fundamentals rock solid. Build small but real projects (UART driver, I2C communication, FreeRTOS task scheduling). Learn to explain your work simply, like you’re teaching a junior engineer. Interviews don’t need you to know everything. They need you to show clarity, fundamentals, and problem-solving ability. Follow RAHUL MEHTA for getting help for your next embedded system interview .

176

4 Comments

I used to think RTL was just about writing logic. Until I realized… I wasn’t just writing code. I was designing real, scalable hardware. In this post, I’ve broken down why RTL isn’t just about Verilog syntax — It’s about: 🔹 Thinking in clock cycles 🔹 Building modular, reusable blocks 🔹 Structuring your design like a real chip 🔹 Writing with synthesis, testing, and scaling in mind ✨ RTL is where software logic ends and digital architecture begins. And once you make that mindset shift — You don’t just write better code… You design smarter chips. — 📚 Featured references: 🔗 IEEE – High-Level RTL Modeling ( https://lnkd.in/gQDCTQ3S ) 🔗 IEEE – RTL Design for Low Power ( https://lnkd.in/gywH2xbw ) 🔗 IEEE – RTL in SoC Integration ( https://lnkd.in/gFCEHi3y ) — #vlsi #rtl #verilog #digitaldesign #chipdesign #modulardesign #vlsidesign #hardwarearchitecture #cmosdesign #hardwareengineering #rtlverification #fpga #synthesisready #systemonchip #digitalcircuits #hdl #hardwaremindset #clockdrivenlogic #learnvlsi #architecturematters

101

5 Comments

A lot of junior engineers think embedded systems = "C programming on microcontrollers." But that’s just 20% of the job. Real embedded development means: Understanding hardware registers, peripherals, and memory layout Managing timing, power, and interrupts Working with protocols like CAN, LIN, SPI, I2C Reading datasheets like they're documentation Dealing with real-time constraints, not just logic You can write perfect code and still fail… if it doesn’t respect the hardware. Embedded systems require a systems mindset — not just good code.

123

5 Comments

What truly defines a well-rounded embedded engineer? It’s not just about writing flawless C code or designing intricate circuit boards. It’s about the balance between hardware and software skills that brings real-world products to life. Consider a firmware engineer tasked with developing an automotive control system. If they understand both the software architecture and the limitations of the hardware, they can write efficient code that optimally interacts with sensors and actuators. A missed connection here can lead to performance degradation or, worse, safety issues. This isn’t about mastering one discipline; it’s about understanding how hardware and software coalesce to form a cohesive whole. Ask yourself: - Can your team members debug at both the hardware and software levels? - Do they understand timing constraints and power management? - Are they aware of how software decisions impact the physical design? When engineers lack this dual perspective, projects can easily derail. For instance, a firmware update that ignores hardware constraints can lead to overheating or system crashes - problems that ripple through the development cycle and erode trust with stakeholders. As you build your team, prioritize candidates who exhibit this hybrid skill set. They will not only contribute more effectively but also drive innovation. If your last hire missed expectations, I’ll help you fix the upstream filters - not the symptoms. DM me - or book a quick 15-min call here: https://lnkd.in/gKupUiug #EmbeddedEngineering #FirmwareDevelopment #TechnicalRecruitment

24

🔍 Linker Scripts & Memory Maps — The Hidden Power Behind Embedded Systems 🚀 When most people think of “embedded development,” they picture firmware, drivers, or real-time control logic. But there’s an unsung hero that decides exactly where every byte of your program lives — the Linker Script. 📌 What is a Linker Script? A linker script is a configuration file used by the linker (like ld in GCC) to control how your program’s sections are placed in memory. Think of it as the blueprint that decides: Where code goes (Flash, ROM) Where data lives (RAM, EEPROM) How startup and initialization happen How memory is partitioned for stack, heap, and custom buffers In other words, the linker script is the final authority between your compiled code and your target hardware. 🗺 What is a Memory Map? A memory map is the real estate plan of your embedded system. It defines: Physical memory regions (Flash, RAM, peripherals) Their start addresses Their sizes Their access types (read-only, read/write, executable) The linker script uses this memory map to tell the linker where each section of the program should be placed. ⚙️ Typical Embedded Example Memory Map (Example for STM32F407) ld MEMORY {   FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1M   RAM  (rwx) : ORIGIN = 0x20000000, LENGTH = 192K } FLASH → Stores .text (code), .rodata (read-only data) RAM → Stores .data, .bss, stack, heap Section Placement ld SECTIONS {   .text :   {     *(.isr_vector)  /* Interrupt vector table */     *(.text)     /* Application code */     *(.rodata)    /* Read-only data */   } > FLASH   .data :   {     *(.data)   } > RAM AT > FLASH   .bss :   {     *(.bss)     *(COMMON)   } > RAM } This ensures: Code & constants live in Flash Initialized variables load from Flash → copied to RAM at startup Uninitialized variables live directly in RAM 🎯 Why It’s Critical Precise Control – You can align sections, reserve memory, and place critical code in fast RAM. Bootloaders & OTA – Custom regions can be reserved for bootloaders or over-the-air update storage. Memory Optimization – On small MCUs, every byte matters; linker scripts make every byte count. Security – Segregating code/data can prevent exploits by making memory non-executable. 💡 Real-World Use Case 📍 Imagine you’re working on an IoT device with: Firmware in Flash Log buffer in external SRAM Critical ISR code in internal SRAM for speed By customizing your linker script, you can: Place ISR code in fast internal RAM Map log buffers to external SRAM Keep bootloader in a protected Flash sector Ensure application firmware never overwrites reserved regions Without the right linker script, these optimizations are impossible. #EmbeddedSystems #Firmware #Microcontrollers #LinkerScript #MemoryMap #STM32 #BareMetal #IoT #RTOS #LowLevelProgramming #ARM #CProgramming #EmbeddedC #MCU #TechDhaba

26

1 Comment