<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>embedded on toorun.dev</title><link>https://toorun.dev/tags/embedded/</link><description>Recent content in embedded on toorun.dev</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Wed, 20 May 2026 10:00:00 +0000</lastBuildDate><atom:link href="https://toorun.dev/tags/embedded/index.xml" rel="self" type="application/rss+xml"/><item><title>Command Injection in C/C++: Why system() with User Input is Dangerous (with Practical Examples)</title><link>https://toorun.dev/posts/command-injection-in-c/c-why-system-with-user-input-is-dangerous-with-practical-examples/</link><pubDate>Wed, 20 May 2026 10:00:00 +0000</pubDate><guid>https://toorun.dev/posts/command-injection-in-c/c-why-system-with-user-input-is-dangerous-with-practical-examples/</guid><description>Command Injection in C/C++: Why system() with User Input is Dangerous Command injection is one of the most common and dangerous security vulnerabilities in C/C++ applications—especially in Linux utilities, embedded systems, and IoT devices. This post explains what command injection is, why it happens, and how to avoid it, with practical examples and secure coding tips.
What is Command Injection? Command injection occurs when an application constructs a shell command using user input and executes it.</description></item><item><title>RTOS vs Bare Metal vs Embedded Linux: A Real-World Guide for People Who Actually Need to Decide</title><link>https://toorun.dev/posts/rtos-vs-bare-metal-vs-embedded-linux-a-real-world-guide-for-people-who-actually-need-to-decide/</link><pubDate>Mon, 18 May 2026 09:30:00 +0000</pubDate><guid>https://toorun.dev/posts/rtos-vs-bare-metal-vs-embedded-linux-a-real-world-guide-for-people-who-actually-need-to-decide/</guid><description>RTOS vs Bare Metal vs Embedded Linux: A Real-World Guide for People Who Actually Need to Decide If you are building an embedded product and your brain is shouting:
&amp;ldquo;Should I go bare metal? RTOS? Linux?&amp;rdquo;
You are not alone. This is one of the most common engineering crossroads.
The short version is simple:
Bare metal is great for tiny, focused, ultra-fast jobs. RTOS is great when you need multiple real-time tasks and still want control.</description></item><item><title>Embedded World 2026: Conference Report and Hardware Ecosystem Observations</title><link>https://toorun.dev/posts/embedded-world-2026-conference-report-and-hardware-ecosystem-observations/</link><pubDate>Fri, 15 May 2026 08:00:00 +0000</pubDate><guid>https://toorun.dev/posts/embedded-world-2026-conference-report-and-hardware-ecosystem-observations/</guid><description>hardware electronics travel germany description: &amp;ldquo;My first experience at Embedded World 2026 in Nuremberg: exploring booths from NXP, STMicro, AMD, Infineon, Digi-Key, Farnell, and more. Freebies, hands-on demos, and why I’ll be back next year.&amp;rdquo; draft: false Embedded World 2026: My First Visit to Nuremberg’s Ultimate Tech Playground This April, I finally made it to the legendary Embedded World Exhibition &amp;amp; Conference in Nuremberg, Germany. The 2026 show ran from April 14–16, and let me tell you—it’s every bit as wild, nerdy, and fun as you’ve heard.</description></item><item><title>From 2000 Lines of 8051 Assembly to 20 Lines of Arduino: A Microcontroller Generational Leap</title><link>https://toorun.dev/posts/from-2000-lines-of-8051-assembly-to-20-lines-of-arduino-a-microcontroller-generational-leap/</link><pubDate>Sun, 10 May 2026 05:00:00 +0000</pubDate><guid>https://toorun.dev/posts/from-2000-lines-of-8051-assembly-to-20-lines-of-arduino-a-microcontroller-generational-leap/</guid><description/></item><item><title>License Plate Reader – Edge Detection Based Recognition for ARM64</title><link>https://toorun.dev/posts/license-plate-reader-edge-detection-based-recognition-for-arm64/</link><pubDate>Wed, 06 May 2026 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/license-plate-reader-edge-detection-based-recognition-for-arm64/</guid><description>Project Overview The License Plate Reader is a two-stage license plate detection pipeline designed for real-time operation on resource-constrained devices like the Raspberry Pi. It prioritizes lightweight computation over accuracy, using edge detection and contour analysis instead of machine learning frameworks.
The system is structured as:
Stage 1: Edge detection using Canny edge detection to identify plate-like regions Stage 2: Contour analysis with aspect ratio filtering to isolate license plates Stage 3: Tesseract OCR for text extraction and recognition This approach eliminates dependency on heavy ML frameworks, making it suitable for deployment on embedded ARM64 systems where memory and CPU are limited.</description></item><item><title>Debugging i.MX6 DDR Calibration: Diagnosing Memory Instability in Embedded Systems</title><link>https://toorun.dev/posts/debugging-imx6-ddr-calibration/</link><pubDate>Tue, 07 Apr 2026 08:00:00 +0000</pubDate><guid>https://toorun.dev/posts/debugging-imx6-ddr-calibration/</guid><description>The Problem: Random Crashes Without Pattern Our custom embedded system based on the i.MX6 processor was experiencing mysterious, unpredictable crashes. The system would lock up or reboot at random intervals with no discernible pattern. We couldn&amp;rsquo;t reproduce the issue on demand, making it nearly impossible to debug using traditional methods.
The symptoms suggested hardware instability, but we had no clear indication of what was failing. It could be:
The CPU? The bootloader?</description></item><item><title>About This Technical Blog: Electronics, Embedded Linux, and Real-World Troubleshooting</title><link>https://toorun.dev/posts/tech-notebook-diary/</link><pubDate>Sun, 29 Mar 2026 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/tech-notebook-diary/</guid><description>This blog is not a polished magazine. It is my personal tech notebook — a place to capture what I learn, remember why I built things, and keep a clear trail of my experiences.
Who I am I am an electronic engineer with more than 15 years of software development experience across the full stack of embedded and systems work. My background starts at bare metal and microcontrollers, extends through embedded Linux and embedded systems, and also includes desktop application development and practical infrastructure work.</description></item><item><title>Embedded RF Testing: Lab Methods and Troubleshooting for Wireless Devices</title><link>https://toorun.dev/posts/embedded-rf-testing-lab-methods/</link><pubDate>Sun, 29 Mar 2026 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/embedded-rf-testing-lab-methods/</guid><description>RF Testing in Embedded Systems Overview RF testing requires devices to support a dedicated test mode that allows controlled configuration of radio parameters.
Typical capabilities include:
Fixed channel selection TX power configuration Bandwidth and modulation selection RX-only mode (disable transmission) Continuous transmission mode These capabilities are required for both wireless interfaces when multiple radios are integrated.
Test Mode Implementation RF test mode is typically implemented based on vendor documentation.
In this case, the implementation follows:</description></item><item><title>Linux WiFi TX Power Configuration and Regulatory Constraints</title><link>https://toorun.dev/posts/linux-wifi-tx-power-regulatory-configuration/</link><pubDate>Sat, 29 Nov 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/linux-wifi-tx-power-regulatory-configuration/</guid><description>WiFi TX Power Configuration Overview WiFi configuration typically allows runtime control of parameters such as channel selection.
However, TX power is not always dynamically configurable and may require configuration during driver initialization.
This is done by providing a TX power configuration binary to the driver.
TX Power Configuration Flow The general workflow:
Generate TX power configuration binary\ Place it in firmware path\ Load driver with configuration\ Verify applied limits Generating TX Power Configuration A configuration file is used to generate a binary representation of TX power limits.</description></item><item><title>NMEA 2000 Implementation: Address Claim, Heartbeat, and Alarm Messages</title><link>https://toorun.dev/posts/nmea-2000-implementation-address-heartbeat-alarm/</link><pubDate>Thu, 29 May 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/nmea-2000-implementation-address-heartbeat-alarm/</guid><description>This is not a full specification reference. It is a practical note to remember how NMEA 2000 works in real systems, what matters during implementation, and what I learned while working with it.
What NMEA 2000 is NMEA 2000 is a communication protocol used in distributed systems over CAN bus.
At the lowest level, it is standard CAN:
250 kbps bus multi-node shared network On top of that, it defines:</description></item><item><title>Embedded RED Cybersecurity Compliance (EN 18031): Requirements and Implementation</title><link>https://toorun.dev/posts/embedded-red-cybersecurity-en18031/</link><pubDate>Sat, 29 Mar 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/embedded-red-cybersecurity-en18031/</guid><description>RED Cybersecurity (EN 18031) Overview The RED cybersecurity standard (EN 18031) defines requirements to ensure that radio equipment is secure and does not negatively impact networks, users, or services.
It is structured around three main articles:
3.3.d: Protection of networks and prevention of service degradation 3.3.e: Protection of personal data and privacy 3.3.f: Protection against fraud Applicability Depending on the system design, not all articles may apply.
Typical example:
Systems without user data → privacy requirements may not apply Systems without financial interaction → fraud-related requirements may not apply Network interaction → usually relevant and must be addressed Requirements Structure Each article is divided into:</description></item></channel></rss>