Works

Switching the CH32V003 System Clock to 48 MHz The previous article, Bare Assembly Bring-Up on the CH32V003, ended with the smallest useful program: reset vector, stack, .bss, GPIO, and an LED blink loop. That program can run from the reset clock. For a first blink, that is enough. The delay loop is not precise, and it does not need to be. The next step is to put the chip on a known system clock. On a CH32V003 board with a 24 MHz HSE crystal, the usual target is 48 MHz through the PLL. ...

at-os3 and PTGS: a Tiny Linux-Driven TinyGS Station TinyGS stations are usually thought of as single embedded devices: an ESP32, a LoRa radio, Wi-Fi credentials, MQTT/TLS, satellite scheduling, radio control, packet forwarding, and status reporting all living inside the same firmware. For my own station, I wanted a different split. The radio should stay small, deterministic, and close to the antenna. The network side should stay on Linux, where TLS, MQTT credentials, logs, TLE data, and station management are easier to inspect and replace. ...

Bare Assembly Bring-Up on the CH32V003 The CH32V003 is strange in a useful way: a RISC-V microcontroller with 16 KiB of flash, 2 KiB of SRAM, GPIO, timers, UART, SPI, I2C, and a price low enough to make experiments feel cheap. Most projects start from a vendor SDK, an IDE template, or a prepared C runtime. That is practical, but it hides the most interesting part: what happens between reset and the first useful instruction of your program. ...

RNode on OS3: a Minimal Reticulum Firmware for the CH32V003 I wanted to know how small a useful Reticulum transport could get. Not a mock-up. Not a “Hello World over LoRa”. Not a proof of concept that only works in a lab once. A real firmware image that can be flashed onto a cheap microcontroller board, detected by rnsd, and used with tools like Sideband and NomadNet. This release is the result: a small RNode-compatible firmware image based on OS3, targeting the CH32V003 and an E22-900M22S LoRa module built around the SX1262. ...

OS3: Architecture of a Deterministic Event-Driven Microkernel The Starting Point Most embedded projects inherit a mental model from desktop operating systems: threads, a scheduler, background tasks, preemption. These abstractions exist for good reasons in general-purpose computing. In deeply embedded systems, they introduce a specific problem: when something goes wrong, you cannot easily answer the question why did this happen now? OS3 starts from a different premise. The kernel has one purpose: preserve causal integrity in time. Every behavior must be traceable to an explicit cause. Latency is a signal. Ambiguity in the execution model is a defect, not a feature. ...