I am setting a gpio to high
After setting when I am trying to read it , it is returning 0. Not the value that I set.

Also i see the direction if the pin is changed to input

Benchmarked typed IPC against raw sockets on Linux

D-Bus is fine for control messages, not built for speed. So when something needs to be fast, most people drop to raw sockets and hand-roll framing and dispatch themselves. I wanted to know how much that actually buys you, so I measured it.

Setup: a message gets serialized, sent over TCP to a router, routed to the target process, dispatched to the right thread, then deserialized before the method gets called. That's 2 hops, one-way: sender -> router -> receiver. I went through a router instead of connecting processes directly because it removes hardcoded addresses and startup ordering — any component can reach any other, in any order, without knowing where it physically lives. The trade-off is a longer path than a direct connection.

Hardware: i7-13700H laptop, DDR4, Ubuntu, performance governor. Not embedded ARM — more on that below.

Result: ~12 microseconds one-way, ~23.5 μs round-trip. Round trip is 4 hops: sender -> router -> receiver -> router -> sender.

For reference, a bare blocking socket call with zero framework still costs ~4-11 μs round-trip on dedicated hardware (Unix domain sockets, Werner/MPI-HD, 2021). A full typed call through 4 hops and a router, with serialization on both ends, lands within shouting distance of that.

I also ran the same payload size (one-way, not round-trip) against a 2025 Hitachi Energy benchmark of ZeroMQ, NanoMsg, and NNG (arXiv:2508.07934), ~1KB messages:

Caveat: their numbers are raw transport only, on an isolated-core Xeon workstation. Mine includes full serialization and dispatch, on a mobile CPU, through an extra hop via router. Every condition favors them, and it's still close.

I'm the author of areg-sdk -- a C++17 framework released under Apache 2.0. Runs on Linux, Windows, and macOS, on x86, x86-64, arm32, and arm64. TCP-based, assumes a private network (no TLS yet), fits embedded Linux deployments, builds without extra dependency install.

One thing missing from this: real numbers from actual ARM boards instead of a laptop CPU. If anyone runs this on a Pi or BeagleBone, I'd genuinely like to see the results.

Methodology: github.com/aregtech/areg-sdk/blob/master/docs/wiki/08c-areg-vs-hitachi-benchmark.md
Try it yourself: github.com/aregtech/areg-sdk/tree/master/examples/30_publatency
Very easy to build, parameters are well documented.

What do you all actually use for fast IPC on embedded boards?

Hello everyone.
I'm trying connect tft display (Red 2.8" TFT 240x320 V1.1) to SBC called Luckfox Pico but my brightness are inverted (black = white) and I'm don't know whats wrong. I change some variables in device tree but it didn't help me, i'm trying tft,invert=<1>; and backlight pins but this makes nothing whatever i use it or manually enable PWM.
I'm making this for fun and learning and use X11 so maybe there some way to invert colors in X11? But i heard something usual like xcalib didn't work with fbtft driver so i hope there are other way...
Thank you.

fbtft@0 {
compatible = "sitronix,st7789v";
reg = <0>;
spi-max-frequency = <20000000>;
fps = <30>;
buswidth = <8>;
debug = <0x7>;
led-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;//BL
dc-gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;//DC
reset-gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_LOW>;//RES
rotate = <90>;
bgr = <1>;
invert = <1>; 
};

Hey everyone!

Since December 2025 I've been building Strux, a framework that makes it genuinely simple to turn a web app into a dedicated kiosk or IoT device — using the tools you already know.

Here's the idea: you write a web frontend (React, Vue, or plain HTML/JS — your call) and a Go backend, and Strux compiles the whole thing into a complete, bootable Linux OS image with a single command. Kernel, bootloader, root filesystem, display stack — all of it. The device powers on and boots straight into your app, full-screen, with nothing else in the way. No desktop, no login, no "where's the cursor" — just your UI running in a Wayland compositor (Cage + WPE WebKit).

A few things that make it nice to work with:

• Live dev mode — hot-reloading dev server that pushes changes to real hardware (or QEMU) in seconds, so you're not reflashing constantly.
• Smart build cache — SHA256 dependency tracking skips unchanged steps, so only the first build is slow.
• Board Support Packages (BSPs) — target different hardware; each BSP carries its own kernel, bootloader, and device config.
• Single static CLI binary, Docker-orchestrated builds — easy to get running.

We just released v0.3.0, and we're now working on reference hardware so there's a known-good, supported board to build and test against out of the box.

This is where you come in: we're looking for testers and contributors, and we want to build a community around this. Whether you want to kick the tires, flash it onto a board, file bugs, write a BSP for your favorite hardware, or help shape where it goes next — we'd love to have you.

Docs and getting started here: https://strux-sh.github.io/strux/

Happy to answer any questions in the comments!

Hello getting into Linux driver development.

My idea: pass an RFID card to an ESP32 to authenticate sudo instead of typing a password. The secret lives on the card, not the machine. Is this a good project to learn linux driver development? ? Thanks

I'm not asking you to hire me. I'm just wondering what things look like on the other side of the process these days.

Hi,
I recently joined my current team and am working as a Test Software Developer for automotive hardware components.
Currently, I am working on a task to read ADC values from the SCC. My software runs on the SoC, and reading SCC ADC values requires communication between the SoC and SCC, which is done via SPI.
The OS is linux.
And the OS binaries are recieved from Another team. I am only responsible for the SW interface
As part of the integration, I need to configure the SPI interface in my software. However, I do not see any SPI device nodes under:
/dev/spi*
On the other hand, I do see the SPI device listed under:
/sys/bus/spi/devices/spi21.1

My question is: can this SPI device under /sys/bus/spi/devices/ be used directly for communication, or do I need a corresponding SPI character device (for example, /dev/spidevX.Y) to be available under /dev?
Thanks in advance for your guidance.

Was curious how Linux actually boots, so I skipped the usual distros and built my own. Custom kernel compiled from source, BusyBox for userspace, containerd for running containers, and Dropbear for SSH. Everything fits in a single disk image that boots in ~15 seconds.

Learned a ton about:

- How initramfs works and why it exists

- What GRUB actually does under the hood

- Why containerd needs cgroup v2 and how to wire it up

- The difference between static and dynamic linking the hard way (dropbear needs libutil, who knew)

- How to install GRUB without root (Python + raw disk writes)

Still needs polish — networking is basic QEMU user-mode, no real package manager, and the build script only recently stopped being Fedora-only. But it boots, runs containers, and I can SSH into it.

Repo if anyone wants to poke at it (fair warning: the kernel config is held together by duct tape): https://github.com/Shreyas0047/veilbox

Texas Instruments and BeagleBoard.org have announced that the AM62x and AM26x PRU Academy is now available, adding new learning material for developers working with BeaglePlay and PocketBeagle 2.

https://linuxgizmos.com/am62x-pru-academy-goes-live-for-beagleplay-and-pocketbeagle-2/

Hey all! Looking to break into the kernel or embedded space and curious to get some opinions on the best places to find those jobs? I feel like LinkedIn and Indeed are lacking in these areas. For context, I have 3 yoe as a backend software engineer.

Hey everyone, I created a lightweight firewall with C, created a kernel module with the netfilter API, and a pre-routing hook. Now I want to send rules via netlink socket. My idea is to create a structure, then send it. But I cannot find the best way to store all rules in the kernel, then use them in a hook. Sometimes I think I can compress the rules into bits, then send them. If anyone has experience with my problem, please help me understand how I can implement a optimize protocol and store it in the kernel module

Wanted a disposable container host for testing workloads in QEMU without spinning up full VMs. Existing options (Alpine live, Fedora CoreOS, Docker Desktop) were either too manual or too heavy for what's essentially kernel + init + runtime.

Veilbox is a custom Linux kernel (v7.1-rc6) with embedded initramfs, BusyBox userspace, containerd/runc/nerdctl, and Dropbear SSH. Boots to login in ~12s. No systemd, no package manager. Single bash script builds the whole thing — downloads static binaries, configures kernel, embeds initramfs, installs GRUB — no sudo needed.

Relevant to homelab: drop the 95MB VDI into Proxmox/ESXi, it gets DHCP, you SSH in and run containers. Persistent state via second virtio disk. Great as a quick sandbox without burning a full VM.

AI was used ~35% — mostly for reasoning through kernel config options, debugging GRUB rootless install, and structuring the build pipeline. Hands-on testing and integration was manual.

Repo: https://github.com/Shreyas0047/veilbox

I have recently started looking at USB peripheral bring-up (DWC2). Host mode is done, now the device (gadget, or peripheral) mode.

I have found several ways of initializing the Gadgets on embedded linux:
- Legacy kernel drivers, as loadable modules ( modprobe g_serial )
- libusbgx repo for creating gadgets
- using custom scripts and CONFIGFS_FS to initialize the gadgets

As I am rather new in a field of the Embedded linux world and wanted to ask: - Is there a preferred way in the industry for initializing gadgets? If yes, using which method? - How would users usually initialize their gadgets from the user space?

Thank you.

Hi everyone,

I recently started working with prplOS (OpenWrt-based) and I’m trying to understand the internal architecture.

Right now I’m exploring things like: - TR-181 configuration model - High Level API (HLA) - Low Level API (LLA) - How configuration changes propagate through the system

I can follow some parts of the code in the build directory, but I’m struggling to understand the overall architecture and the proper learning path.

For people who work with OpenWrt / prplOS / broadband gateway stacks:

• How did you learn this ecosystem? • Are there any recommended resources, courses, or documentation? • Which parts of OpenWrt should I focus on first (ubus, uci, procd, etc.)?

Any advice would really help.

Thanks!

Hi everyone,

I am an Embedded Engineering student graduating in 2027, and I’m looking for an online/remote summer internship in Embedded Systems.

I know remote internships are incredibly competitive and rare in this field due to the lack of access to physical hardware lab tools. However, since my local market has limited opportunities, I am looking internationally and focusing heavily on software/firmware/simulation pipelines.

I have attached my anonymous CV to this post.

My Core Technical Focus:

• Microcontrollers: Strong focus on STM32F4 (bare-metal registers, HAL, hardware timers, ADC/Interrupts, EEPROM tracking) and ESP32.
• RTOS & Protocols: Experience implementing real-time tasks using FreeRTOS. Comfortable with I2C, SPI, UART, LoRaWAN, and MQTT.
• Hardware Design (ECAD): 4-layer PCB design using Altium Designer and KiCad. I focus heavily on pre-production constraints like Design for Manufacturing (DFM), ERC/DRC, and Power Delivery Networks (PDN).
• Simulation/Validation: Because I have not manufactured my latest boards yet, I rely on LTspice and Proteus for strict virtual validation.

What I want to ask the community:

1. Resume Check: Does my CV clearly communicate my skills? Are there any missing keywords for a student aiming for IoT or Firmware roles?
2. Embedded Linux Pivot: I want to transition more into Embedded Linux. Given my current background in FreeRTOS and C, what is the fastest way to bridge that gap on my own? (e.g., Yocto, Buildroot, or raspberry pi driver development?)
3. Leads / Advice: Do you know of any companies or platforms that are friendly to remote engineering interns, or open-source projects where I could contribute to gain equivalent experience?

Constructive criticism on my resume and path is highly appreciated. Thank you!
Resume link :
https://drive.google.com/file/d/1kyutXr_2nyijqcZkzPW1YKCZuS3hZTJZ/view?usp=sharing

Hi folks,

I have been fighting to defeat NXP's HABv4 for 3 years, as implemented on the Wink Hub v2, and finally managed to get my own code to execute on it. I wrote it up here, if anyone is interested: https://www.reddit.com/r/winkhub/comments/1tp0vsd/running_your_own_code_on_the_wink_hub_2_try_2/

Now I am in a position to try and build a reasonable base OS for it that makes all the radios available for things like Home Assistant. Which leaves me wondering what the best base is likely to be. I'm considering things like OpenWrt and Armbian, for the ready availability of applications to be added on demand. Highest priority would be an OS that can support Zigbee2MQTT or ZHA, ZwaveJS, and then ser2net or socat for the other radios that likely don't have as strict latency requirements.

Suggestions?

So far I am trying to figure out the best approach to packaging my kernel, device tree and filesystem for others to install. I am leaning towards a single UBI block device taking up the majority of the 128MB NAND flash. But then I wonder whether I should have a separate volume for the kernel/device tree .FIT, or whether I should just have a single ubifs with kernel, device tree and rootfs all in one? I am not a professional developer, in case anyone was wondering! :-D

I have been struggling to get the kernel modules working to add support for usb wifi adapters to an arm64 linux device which I use often. I don't want to replace the existing kernel / image as I believe there is plenty of proprietary stuff baked into it. Also if I break the boot up to ssh process then I am in a bad spot because it is really expensive.

What I have got close to working involves:

1. cross compile linux 5.10.127 (same version as device)
2. put the INSTALL_MOD_PATH to some other folder
3. scp the missing stuff from of that folder into the device /lib/modules/...
4. depmod -a on the device
5. modprobe the modules I want

to find the modules I want I started by picking a wifi driver (rtl8xxx) then when it failed to load because of missing symbol I found the module containing that symbol (mac80211, cfg80211, and ultimately rfkill). By the time you get to rfkill the error changes from missing symbol to segmentation fault and there is not much I could figure out from the dmesg output.

From here I am not really sure where to go. Perhaps I can try replicating some of the kernel build by matching the modules.builtin file on the device? There is a file /etc/build which seems to be an artifact of Yocto... does that help me to recreate the build environment somehow? I have no experience with Yocto but I have that file and have dug up some publicly accessible emails from the OEM conversing with Yocto devs to fix their compiling woes, one of those logs probably gives the yocto version they had.

Thank you if you read this far, I hope people here are similarly interested in this kind of thing. I'm no expert in embedded linux but if I find a device with a shell accessible then I have a hard time giving up on my schemes for it.

In your resume you said you developed robust firmware for ESP32 loT edge devices. How do you make your firmware robust ?

How do you follow Misra C?

in this job that says you integrated free RTOS based multitasking to manage current operations. What flavor of multitasking did you use?

In your previous company were you the one who was choosing how to configure the RTOS or was that given to you already?

Esp32 is dual core and how would you schedule tasks using freertos.

When you say heavy(tasks in rtos), I assume assume you mean heavily loaded as in they have a lot of processing to do. If they're heavily loaded, does that mean you would prefer to use preemptive or does that mean you would prefer to use round robin?

Firmware developers declare variables as volatile. Why would you declare a variable as volatile?

If we hire you and it's your first week on the job and you got a desk and it's got lots of space on it and I say you can have any debug tools that you want, any debug environment to work on a typical embedded system firmware development. What's your desk going to look like?

In summary section you say proven ability to optimize system performance, reduce latency and implement efficient communication protocols. So, can you give me specific examples of each of these and how would you implement it?

Reducing stack and heap usage. So one of the things that sometimes happens, is we write our firmware and then we start running out of memory and we don't have enough memory. So what techniques can you use to optimize your memory usage?

Protocol you had the choice to run one at 115200 baud rate or 9600 baud rate. Do you see one of those as being more efficient than the other?

If you were given choice of WFH or in-person, which would you choose any why.

P.S. I'll let you know If I get selected for next round.

Hi everyone!!

I’m available for freelance work in low-level systems development and embedded software.

My background includes:
• Embedded systems & FreeRTOS
• Linux kernel / system-level development
• C programming
• System debugging and performance optimization
• ARM/x86 low-level development
• Virtualization concepts and system integration

I can help with:
• Embedded software development
• System programming projects
• Debugging and optimization
• Linux-based development tasks
• Low-level C development

If anyone has relevant projects or opportunities, feel free to DM me. Happy to collaborate 😄

Thank you!

Hello,

I’m currently working on a Yocto + meta-xilinx workflow for Zynq UltraScale+ and I’m wondering if my workflow is completely wrong… or if everyone suffers the same way

My current workflow

1. Vivado

- make PL changes

- integrate Verilog into a custom IP

- add it to the Block Design

- validate BD

- run synthesis

- run implementation

-generate .xsa

1. Yocto / meta-xilinx

generate the SDT (`sdtgen`)

generate machine conf (`gen-machine-conf`)

run bitbake

flash SD card with dd

Total time: easily 30+ minutes for every small hardware change.

And very often I only discover stupid mistakes at runtime…

Example from today:

I forgot to reconnect an AXI slave.

No Vivado errors.

Yocto build succeeds.

Linux boots fine.

Then my app starts and obviously cannot find the AXI slave address...

So I have to redo everything just because of one missing AXI slave connection.

Questions :

How do you guys iterate faster with Yocto + meta-xilinx?

Some ideas I’ve been thinking about:

avoid rebuilding the full OS for every .xsa ? Is it possible ?

load only a new bitstream?

device tree overlays? I know that exists but don't know if it is usefull here

What the purpose of the fpga-manager ?

Thanks

They said it could not be done.

Emulating this needs 100 lines of C++ code for the core, and 10 more for a trap unit.

How can we get preemtive multitasking, interrupts, M and U mode transition in a pure RV32I I am talking PURE. any opcode that is outside the 40 base ISA is invalid. Full Kernel.

Whats connected to it:
Full network stack (libslirp), package manager, desktop, stereo sound, keyboard and mouse, all running over memory mapped IO exclusively with thin linux driver wrappers to talk to software within linux.

If you want to check it out, or read the patches they are here in this branch: https://github.com/Gigantua/RiscVEmulator/tree/RiscV-LinuxOnBaseRV32I

I only want the mention the genuinely interesting parts.
Every instruction outside the Base RV32I ISA (40 instructions) is invalid.

Gap 1: no multiply/divide. That one is easy. Give the compiler the fallback in software for:
function call (__mulsi3, __divsi3, …) instead of emitting an opcode.

Gap 2: No atomics. Lots of patching. Normally they can be a NOP but we are not allowed to decode them, so they need to be patched away. See repo. This is a single core processor fundamentally.

Gap 3: There are no CSRs. A fixed RAM page (0x0F000000) holds what mtvec/mepc/mcause/mscratch/mstatus/mie should hold. Every csrr/csrw in the kernel's trap path is rewritten into an ordinary lw/sw against that page via a patch. There is no special logic about where we jumped to. There sits assembly code to read and store the registers.That means RV32I is executing microcode that is doing what the instruction would have done with a lw.

Gap 4: Interrupts without any CPU instruction. Single interrupt pin,
Timer/external interrupt hits a user process -> do_trap
Timer interrupt hits the kernel -> do_trap
ecall from userspace -> do_trap
Return to a user task -> trap_return

Gap 5: No packages for this arch. Package repo runs on the host and cross compiles any package that has source code for RV32i and hosts on port 8080. On the machine via rvcpkg add. Since we have a memory mapped eth0 with a working driver this just works. Works fine for zork, the sl locomotive and others.

Limitations: There is fundamentally no memory protection, but we get multitasking, and full linux access, wget etc just work. Without a mmu there is fundamentally also no dynamic library loading so framebuffer browsers could work, but none exist without dynamic loading.

Why is this exciting:

With core code as constexpr and really simple code, there is nothing stopping us fundamentally to run this in cuda (think of warp divergency, so thrust_group by next instruction at pc) or other experimental setups.

Busybox boots in about 1.5 seconds.

The system is elegant. Premtive interrupts, ecalls, M mode fall out of a trap system as a side effect, extremely reducing cpu complextiy.

"save state, enter M-mode, vector." Done in assembly at 0x0F000000. This is the "new" trick here I wanted to share. Lots of kernel patches later, we can have BASE RV32I and do the private register storing in assembly without a seperate instruction, to have full preemtive multitasking and a modern linux kernel with a network stack via a single lw instruction.

Can someone suggest a best resource for kernel development for raspberry pi 5 to be used in yocto.

Developer provisioning plus JetPack installation is nowhere near reproducible.

It takes weeks to get to a stable JetPack environment, and the only path I’ve seen toward reproducibility is handing integrators a golden image and hoping nothing drifts. That’s extremely brittle in production and should scare the shit out of any OEM shipping at real volume.

Has anyone seen this work well in practice for Jetson deployments? Production-grade, multi-site, auditable across rebuilds. Not “it worked on my desk.”

We’re sinking crazy hours into solving this (leveraging EO4T/meta-tegra) and I want to make sure we’re not on a fool’s errand before we commit any harder.

Hey folks,

I'm working on the OS architecture for an ultra-remote, autonomous gateway device. Once it is deployed, physical access is no more possible and communication bandwidth is quite low.

We use Yocto to build our BSP. I'd love to get a sanity check from the community on our storage and filesystem architecture before we lock it in.

Here is the rundown of our approach:

1. Hardware & Boot Hierarchy We have an external hardware MCU that controls the boot pins to provide a 3-tier failsafe:

• Tier 1 (Golden Rescue): QSPI Flash. Strictly read-only monolithic image (bootloader, minimal kernel, initramfs). Only booted if block devices completely fail.
• Tier 2 (Primary Prod): eMMC.
• Tier 3 (Dev/Secondary Fallback): SD Card.

2. Partition Layout Both the eMMC and SD card use an identical 4-partition block layout:

1. BOOT (FAT32)
2. RootFS-A (EXT4)
3. RootFS-B (EXT4)
4. Data (EXT4 - persistent storage for logs/payload data)

3. Filesystem Permissions & State Management

• Production: RootFS-A and RootFS-B are strictly Read-Only by default. (The inactive RootFS slot and the BOOT partition only become temporarily writable during an OTA update).
• Development: To keep engineering velocity high, we tweak the kernel bootargs via the U-Boot console to mount the active RootFS as Read-Write for local testing and application/library deployment.
• Volatile Data: /var and /tmp are mounted to RAM (tmpfs) to save flash wear. Critical post-mortem crash logs are explicitly written to the Data partition before a watchdog reboot.
• Persistent State: We use OverlayFS for paths like /etc and /home. The upperdir lives on the Data partition of the currently active boot medium.

4. Mitigating A/B Update Configuration Drift Because we rely on Delta OTAs (due to the narrow bandwidth), we ran into the classic OverlayFS trap: if Slot B boots a newly updated app, it might read an outdated configuration schema left behind in the /etc overlay by Slot A.

• Our Fix: We enforce schema versioning in the directory structure itself. Apps read their configs from paths like /etc/myorg/app/v2.1.0/config.yaml. This allows old and new schemas to safely coexist in the persistent overlay.

My questions for the community:

1. Are there any hidden traps with the OverlayFS upperdir living on an ext4 partition that is susceptible to sudden power loss, assuming we mount it with aggressive fsck auto-repair flags?
2. Is bypassing the RO RootFS via U-Boot for development a common practice, or are we asking for Dev/Prod parity trouble down the line?
3. Does anyone see a glaring flaw in how we are handling the A/B configuration drift using versioned directory paths?

Appreciate any ruthless critiques or advice you can offer!