DenisDolya

Hi HN, I started this project because I was tired of BMP libraries that hide allocations, pull half of libc, or solve only one small part of the problem. There are many libbmp-style repos, but the functionality feels scattered: one does decoding, another does encoding, another works on embedded, another is single-header. In real projects this often means depending on 5–10 small libraries just to load and display images. I wanted one predictable library instead: no allocations, one header, full control over buffers, and usable both on desktop and on microcontrollers. Something where you always know where memory comes from and where it goes. Over time, I got more and more into it and started optimizing around what I call ESS: Energy, Speed, Small binary. I added fast paths for common 24/32bpp BMPs, removed unnecessary branching in hot loops, and focused on predictable performance. For embedded systems, I added a streaming decoder that can write directly into LCD/DMA via callbacks, and even decode only a clipped rectangle to save CPU time and power. The result is TurboLibBMP: a single-header, stb-style BMP decoder and encoder in C, with no allocations, no stdio, no hidden buffers, and full user control over memory and behavior. It is GPL-3.0 and works in both C and C++. I built this mainly for my own low-level and embedded projects, but I’m sharing it in case others find it useful. I would really appreciate feedback on the API design, edge cases, and whether this approach makes sense in real projects. Repo: https://github.com/Ferki-git-creator/turbo-lib-bmp

Hi HN,

I started this project because I was tired of BMP libraries that hide allocations, pull half of libc, or solve only one small part of the problem. There are many libbmp-style repos, but the functionality feels scattered: one does decoding, another does encoding, another works on embedded, another is single-header. In real projects this often means depending on 5–10 small libraries just to load and display images. I wanted one predictable library instead: no allocations, one header, full control over buffers, and usable both on desktop and on microcontrollers. At some point I got so into it that I added a streaming embedded decoder and kept everything stb-style. The result is TurboLibBMP. I would really appreciate feedback on the API design, edge cases, and whether this approach makes sense in real projects.

Repository: https://github.com/Ferki-git-creator/turbo-lib-bmp

I recently came across this small ESP32 project and found the design ideas behind it very interesting.

BPU (Batch Processing Unit) is a lightweight embedded scheduling core focused on keeping output pipelines stable under pressure (UART backpressure, limited bandwidth, bursty producers).

Instead of blocking or growing unbounded queues, it: enforces per-tick byte budgets, coalesces redundant events, degrades gracefully under sustained load, exposes detailed runtime statistics.

The repository includes design notes, flow diagrams, and real execution logs, which makes the runtime behavior very transparent.

Repo: https://github.com/choihimchan/bpu_v2_9b_r1

I’ve been working on an ESP-IDF backend for it, and reading through the docs gave me a lot of ideas about observability and backpressure handling in small systems.

Curious what others think about this approach.

I’m exploring ways to write data from userspace to Linux terminals (stdout/stderr) with minimal CPU cycles, syscall overhead, and binary size, beyond the common methods I’ve considered write(), writev(), splice(), sendfile(), and io_uring—and I’d like to learn about other techniques or kernel interfaces that experienced developers use, including any lesser-known approaches, optimizations, or trade-offs; for each method, please indicate what makes it faster, more energy-efficient, or lighter in binary size, and share concrete examples, references, or microbenchmarks if available, so that I can compare options and understand real-world advantages and limitations.