The latest articles on Forem by Shreyash (@shreywritesblogs). https://forem.com/shreywritesblogs https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3819872%2F24bc0967-2d24-43e3-bf8a-f189ddeb81b2.jpg https://forem.com/shreywritesblogs en Shreyash Tue, 07 Apr 2026 11:56:34 +0000 https://forem.com/shreywritesblogs/introduction-to-embedded-linux-3nnh https://forem.com/shreywritesblogs/introduction-to-embedded-linux-3nnh <h2> Context </h2> <p>Most developers are familiar with software that runs on laptops, servers, browsers, or mobile phones. But there is another world where software does not run in isolation. It runs on devices that interact with the physical world — routers, gateways, industrial controllers, cameras, infotainment systems, and many other smart devices.</p> <p>That world is where embedded Linux comes in.</p> <p>At first glance, it may look like “just Linux,” but embedded Linux is really about using the Linux ecosystem to run software on resource-constrained devices that have a specific purpose. It sits between pure firmware and general-purpose computing, which makes it one of the most interesting areas in embedded development.</p> <p>This article is a simple introduction to what embedded Linux is, why it is used, and what a beginner should understand before diving deeper.</p> <h2> What is Embedded Linux? </h2> <p>Embedded Linux is a Linux-based operating system designed to run on embedded hardware.</p> <p>Unlike desktop Linux, which is made for general-purpose computers, embedded Linux is usually customized for a specific device. That means it may include only the components needed for that product and nothing extra.</p> <p>In simple terms:</p> <ol> <li>The hardware is built for a specific job</li> <li>The Linux system is trimmed and configured for that job</li> <li>The application runs on top of it and controls the device</li> </ol> <p>This makes embedded Linux very powerful for devices that need:</p> <ul> <li>Networking</li> <li>Multitasking</li> <li>File systems</li> <li>Driver support</li> </ul> <h2> How Embedded Linux Differs from Firmware </h2> <p>This is one of the most important things to understand.</p> <p>In firmware development, you often work very close to the microcontroller. You control peripherals directly, and the software usually runs as one main program.<br> In embedded Linux, the system is layered.</p> <p>A typical stack looks like this:</p> <ul> <li>Bootloader: Starts the hardware and loads the kernel</li> <li>Linux kernel: Manages hardware, memory, processes, and drivers</li> <li>Root filesystem: Contains system libraries and user programs</li> <li>User-space programs: Actual software logic of the product</li> </ul> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F1o02t60626k8glgt7i16.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F1o02t60626k8glgt7i16.png" alt=" " width="800" height="657"></a></p> <h4> This layered structure makes embedded Linux more complex than bare-metal firmware, but also much more capable. </h4> <h2> Cross-Compilation: A Key Concept </h2> <p>One of the first surprises for developers entering embedded Linux is that you usually do not compile directly on the target board.</p> <p>Instead, you often use cross-compilation.</p> <p>That means:</p> <ol> <li>Your development machine builds the software</li> <li>The output binary is meant for a different CPU architecture</li> <li>The target board runs the compiled result</li> </ol> <p>This is common because embedded boards may use ARM, MIPS, RISC-V, or other architectures.</p> <p>Cross-compilation is one of the first practical hurdles, but once you understand it, the workflow becomes much smoother.</p> <h2> Final Thoughts </h2> <p>Embedded Linux is not just “Linux on a small board.” It is a complete ecosystem for building real products that need hardware control, networking, and application logic in one system.</p> <p>The learning curve can feel steep at first because it combines so many topics at once. But once the pieces start making sense — bootloader, kernel, device tree, root filesystem, and user-space applications — the entire system becomes much easier to understand.</p> <p>If you are coming from firmware or full-stack development, embedded Linux is a great next step because it teaches you how operating systems and hardware work together in real products.</p> <p><em>It is one of the best places to learn how software meets hardware in the real world.</em></p> linux Shreyash Thu, 12 Mar 2026 11:41:26 +0000 https://forem.com/shreywritesblogs/switching-from-full-stack-development-to-embedded-firmware-2k2j https://forem.com/shreywritesblogs/switching-from-full-stack-development-to-embedded-firmware-2k2j <h2> Context </h2> <p>Most developers start their careers building software that runs on servers, browsers, or mobile devices. I started there too. My early work involved typical full-stack development — APIs, databases, backend services, and frontend applications.</p> <p>But over time I became curious about something deeper :<br> The layer between a software and hardware, something that binds software to hardware for devices used in real time systems.</p> <p>Almost two years later, I now work primarily on embedded firmware. This transition completely changed how I think about software engineering, debugging, and system design.</p> <p>This article is not about one specific project. Instead, it's about the mindset shift required when moving from web software to firmware development.</p> <h2> Why I Moved from Full-Stack to Firmware ? </h2> <p>Full-stack development is powerful. You can ship features quickly, deploy globally, and iterate rapidly.</p> <p>But embedded systems offer a different kind of challenge:</p> <ol> <li>You interact directly with hardware peripherals</li> <li>Debugging often happens without logs or stack traces.</li> <li>Every byte and millisecond matters.</li> <li>Problems often span hardware + firmware + communication protocols. That complexity is what pulled me in.</li> </ol> <p>Working closer to hardware forces you to understand systems from the ground up.</p> <h2> Learning to Read Datasheets Efficiently </h2> <p>One of the most important firmware skills is extracting the right information from a datasheet quickly.<br> Datasheets can be hundreds of pages long. Reading them linearly rarely works.</p> <ol> <li>Find the system overview first and understand the architecture:</li> </ol> <ul> <li>communication interface (UART, I2C, SPI, CAN)</li> <li>data format</li> <li>initialization sequence</li> </ul> <ol> <li>Identify the register map or command structure</li> </ol> <ul> <li>registers</li> <li>binary commands</li> <li>structured packets</li> </ul> <p>Once you understand the structure, the rest becomes easier.</p> <h2> Debugging in Firmware for a sensor feels Different </h2> <p>Firmware debugging often looks like this:</p> <ul> <li>Send a command to a device</li> <li>Capture the raw response</li> <li>Decode the bytes manually</li> <li>Verify checksum</li> <li>Compare with documentation</li> <li>Repeat until behavior matches expectations</li> </ul> <p>Sometimes the problem isn't even in your code. It maybe a sensor issue, hardware issue, connector wires issue and anything related to hardware and that's why the debugging process sometimes feel tiring.</p> <p><em>If you're a software developer curious about embedded systems, I highly recommend exploring this space. The learning curve is steep, but the insights you gain are incredibly valuable.</em></p> webdev firmware controllers