Alessandro Partesotti

🔗 How Linux Kernel Automatically Matches Devices to Drivers in Embedded Systems Ever wondered how your embedded Linux system knows which driver to load for each hardware component? The magic happens in the platform bus subsystem! The Matching Dance 💃🕺 When you boot an embedded Linux system: 1️⃣ Device Registration: Hardware devices are registered with the platform bus (from device tree, ACPI, or board files) 2️⃣ Driver Registration: Platform drivers register themselves with matching criteria 3️⃣ Automatic Matching: The platform bus core compares device properties with driver capabilities 4️⃣ Driver Binding: When a match is found, the driver's probe() function is called Real Example: UART Controller 🖥️ Device Side (Device Tree - Platform Device): / { // Root node - direct children are platform devices uart0: serial@12340000 { compatible = "company,uart-v1.0"; reg = <0x12340000 0x1000>; // No bus specified = platform device! }; // Compare with non-platform devices: i2c0: i2c@12350000 { compatible = "company,i2c-v1.0"; reg = <0x12350000 0x1000>; // Children of i2c bus = i2c devices (not platform) sensor@48 { compatible = "company,temp-sensor"; reg = <0x48>; }; }; }; Key: Platform devices are typically: ✅ Direct children of root ("/") or simple bus nodes ✅ Memory-mapped devices (have reg property with addresses) ✅ NOT under a specific bus controller (I2C, SPI, PCI, etc.) Driver Side (Complete Platform Driver): // Step 1: Define what devices this driver supports static const struct of_device_id uart_match[] = { { .compatible = "company,uart-v1.0" }, { /* sentinel */ } }; // Step 2: Create platform driver structure static struct platform_driver uart_driver = { .probe = uart_probe, // Called when match found .remove = uart_remove, .driver = { .name = "company-uart", .of_match_table = uart_match, // Link to match table }, }; // Step 3: Register driver with platform bus module_platform_driver(uart_driver); Key Matching Methods 🔍 Compatible strings (Device Tree) Device names ACPI HIDs/CIDs Driver ID tables The beauty? It's all automatic! No manual driver loading needed. The kernel handles the complex matching logic, making embedded development more reliable and maintainable. #EmbeddedLinux #KernelDevelopment #DeviceDrivers #EmbeddedSystems #Linux #IoT #TechExplained

354

12 commenti

🔧 Do You Use VSCode/Cursor for Embedded Development? I do - and quite actively. IDEs like STM32CubeIDE I use exclusively for generating low-level peripheral initialization code. But for day-to-day embedded development and testing, VSCode or Cursor gives me a much smoother and more flexible experience. I rely on a Make-based build system. Here’s what makes VSCode/Cursor such a powerful environment for embedded projects: 📦 build.json: Versatile Build Configurations You can define multiple build configurations for your project - not just for your embedded target, but also for host-side PC projects. The latter are useful for unit testing your embedded code on your development machine. 🚀 launch.json: Flexible Launch Options This file lets you define various launch scenarios - for both embedded and PC projects. One powerful trick: I use launch.json to pipe logs directly from Segger RTT into the VSCode terminal. That way, you don’t need any extra RTT tools running in parallel - everything is right in the editor. 🧩 Must-Have Extensions for Embedded Work Here’s my personal list of extensions that make development easier and faster: - Cortex-Debug - C/C++ and C/C++ Extension Pack - SonarCube for IDE - Gruvbox Material (theme) - Makefile Tools - MemoryView - Numbered Bookmarks - RTOS-Views - TODO Tree - Peripheral Viewer - GitHub Pull Request 📁 Sample Repository I’ll share a link in the comments to a repository with working build.json and launch.json files that you can use as a starting point. 💬 What About You? Do you use VSCode or Cursor for embedded development? If so, I’d love to hear what tools and extensions you use. Let’s exchange tips! #EmbeddedSystems #VSCode #CursorEditor #EmbeddedDevelopment #Microcontrollers #STM32 #Makefile #RTOS #FirmwareDevelopment #CortexM #IoTDevelopment #DebuggingTools #SeggerRTT #DevTools #OpenSourceFirmware

506

53 commenti

The CH340 is one of the most common USB-to-Serial converters used in Arduino clones and other microcontroller boards. It connects your computer’s USB port to the ATmega328P’s UART (PD0/PD1), making programming and debugging possible. #Arduino #Microcontrollers #EmbeddedSystems

118

4 commenti

Configuring embedded software projects can be surprisingly complex, as it’s easy to get lost in a maze of header edits and build script changes. That’s where Kconfig comes in. Originally designed for the Linux kernel, Kconfig provides a unified way to select features, set parameters, and manage dependencies. A number of modern frameworks, including ESP-IDF, have adopted it to keep projects scalable and maintainable. In ESP-IDF, Kconfig powers the `idf.py menuconfig` tool. This allows you to enable or disable features, adjust settings, or even add your own custom configuration symbols. Instead of hardcoding values in your source code, you can expose them through Kconfig, making it much easier to adapt your firmware for different hardware revisions, debug levels, or deployment scenarios. I put together a new tutorial and video showing how to add a Kconfig file to an ESP-IDF project, create custom options, and use them to conditionally compile features. If you’re working with ESP-IDF for the #ESP32, check my tutorial here: https://lnkd.in/gQ-DcHEn #IoT #embedded #electronics #microcontroller #kconfig #programming Espressif Systems

189

2 commenti

🔧 Why C Still Reigns Supreme in the World of Systems and Embedded Development Despite the flood of modern programming languages, C is not going anywhere and for very good reasons. If you're an aspiring embedded systems engineer, systems programmer, compiler developer, or even working in IoT, automotive, aerospace, medical devices, robotics, OS kernels, or performance-critical AI systems—you need to know C. Not just surface-level, but deep—pointer-arithmetic, memory models, linker behavior, and beyond. 💡 Why Is C Still So Important? ✅ Foundational to Modern Software C forms the core of modern operating systems, device drivers, microcontroller firmware, networking stacks, and more. Linux, Windows kernel components, embedded RTOSs, and most bootloaders are all written in C. ✅ Portability + Performance With its ability to compile directly to machine-level instructions and fine-grained control over memory and CPU usage, C enables highly efficient and deterministic code—crucial in embedded and real-time systems. ✅ Hardware-Level Control C gives you direct access to registers, memory addresses, and low-level operations. That’s why ARM Cortex-M, AVR, STM32, PIC, and even bare-metal RISC-V systems are taught and programmed in C. ✅ Toolchain Ecosystem Toolchains like GCC, IAR, Keil, Clang, and GHS are optimized for C. Most debugging tools, static analyzers, and safety certification tools are designed with C in mind—especially in MISRA, AUTOSAR, ISO 26262, and DO-178C compliant industries. ✅ Ubiquity in Industry Interviews Whether it's NXP, Infineon, Qualcomm, Intel, or Bosch—C questions dominate embedded interviews. From bit manipulation to memory maps to ISRs, you can’t escape it. 📍 Where Is C Used? Microcontrollers & Bare Metal Programming (e.g., STM32, AVR, MSP430) Kernel and OS Development (Linux Kernel, Windows NT) Drivers and Firmware (USB, UART, I2C, SPI, CAN) IoT Platforms (Contiki, RIOT OS, Zephyr) Automotive Software (AUTOSAR BSW modules) Medical and Aerospace Systems (Safety-critical environments) Compiler and Interpreter Backends Network Stack and Protocol Implementation 🔍 How Much C Should You Know? ➡️ Enough to design your own OS kernel modules and bootloaders. But practically, you should master: 🧠 Pointers and Memory Management Pointer arithmetic, const correctness, double/triple pointers Dynamic/static memory regions (stack/heap/data/bss) 🛠️ Bitwise Operations & Memory Mapping Efficient register-level manipulation (critical for peripheral drivers) 🔁 Control Flow, Optimization, and Inlining Loop unrolling, reducing function call overhead 📎 Linkers, Compilers, and Makefiles Understand .data, .bss, heap, and stack behavior Learn gcc, ld, nm, objdump and make 🧪 Unit Testing and Safety Coding Standards CppUTest and MISRA C compliance 🧬 Interrupts and ISRs Handling concurrency, atomic operations, volatile, and memory barriers 💻 Toolchain Knowledge Cross-compilation, flashing, and JTAG/SWD debugging #CProgramming

2.519

143 commenti

One principle I teach modern embedded engineers is this: There is no hardware. Only data. Of course, the hardware doesn’t literally disappear. It’s still there. But it gets abstracted away. And when you understand this principle, your focus shifts. You stop obsessing over registers and peripherals. You start obsessing over the thing that actually matters: data. Because at the end of the day, every embedded system exists to gather data, process data, and store data. That’s it. This shift forces you to think less about program flow and more about data flow. It shows you how to design your system around the data, not the board. How do you do that? By following SOLID principles. By decoupling your business logic from the hardware itself. Here’s the truth: most of the time, your end users don’t care about the hardware. So why would you keep designing your architecture around it? When you embrace this principle, you open up an entirely new world: - You can simulate and test most of your application logic without ever touching the board. - You can plug into modern practices like CI/CD, unit testing, and HIL simulation. - You can deliver faster and with fewer bugs. Stop tying your code to the hardware. Start tying it to the data.

141

60 commenti

Exciting update for #STM32 developers! STM32Cube for VS Code just got its first update since the May pre-release, bringing new features and improvements based on developer feedback. 🔍 Key updates: ▶️ Live data watch: monitor variables in real-time during debugging ▶️ New ST Arm Clang toolchain: improved code speed and size with LLVM-based tools ▶️ Build analyzer improvements: clickable memory sections and Clang/LLVM binary support Discover all the details and how these updates can accelerate your development process here 👉 http://spkl.io/6049AJSxc #EmbeddedDevelopment #VSCode #STM32Cube

290

10 commenti

🚫 ROS 2 developers, stop using logs for debugging! That’s exactly what I told the team last week - and for good reason. Debuggers exist for a reason and once you start using them properly, life gets so much easier. At Botronics, we work in VS Code, and here’s what we set up: For Python: configure your IDE exactly as if you were launching a normal Python script (yes, you can still pass arguments, parameters, etc.). For C++: I took inspiration from this great tutorial : https://lnkd.in/ec3AxzZG . In short: I start the node I want to debug with gdbserver and then attach VS Code to it. This change has made a huge difference in productivity. And now, we’ve got a new team rule: 🍩 Donuts for every "dummy log" found in a PR! Logs are very useful for troubleshooting a live issue, not for debugging your current development. #ROS2

129

27 commenti

Linux Kernel Training: Day 1 🚀 Want to level up from microcontrollers to building complex embedded systems? Understanding the Linux Kernel is your next critical step. I'm kicking off a new training series, and this first video is your essential starting point. We'll cover: ✅ The story of Linus Torvalds and the birth of the Kernel. ✅ Evolution of Linux and key milestones. ✅ Linux distributions and their connection to the Kernel. ✅ Contributing to the Kernel. ✅ The Kernel's directory structure and design goals. This video is for anyone who wants to add this vital skill to their toolkit. 🔗 Watch the full video here: https://lnkd.in/gsyPD3ge What are you hoping to learn about the Linux Kernel? Share in the comments! 👇

129

6 commenti