Why?
Anyone developing AUTOSAR stacks day in and day out knows the problem: the actual hardware is far away. Between the code I write and the chip it runs on sit configuration tools, build systems, integration processes, and usually an evaluation board that I share with the rest of the team.
Privately, I wanted something different. A board that belongs to me. A project I own from start to finish — requirements, architecture, implementation, CI/CD. No client, no process overhead, no compromise.
The BeagleBone Black was the obvious choice: ARM Cortex-A8, AM335x, Linux-capable, well documented, and established in the embedded community for years. Not a Raspberry Pi — the BeagleBone is closer to the hardware, and that was exactly the point.
What This Project Is
It is not a product and not a tutorial project. It is a platform where I try out things that interest me professionally — but under conditions that I fully control.
Concretely: an embedded system with a strict 5-layer architecture, a multi-language stack, and a complete CI/CD pipeline — the way I would build it in a professional project, just without the constraints of a client engagement.
The Hardware
Board: BeagleBone Black
Processor: Texas Instruments AM335x, ARM Cortex-A8, 1 GHz
RAM: 512 MB DDR3
Storage: 4 GB eMMC + microSD
Interfaces: GPIO, I2C, UART, SPI, USB, Ethernet
The AM335x is interesting because besides the Cortex-A8 it also includes two PRU cores (Programmable Real-Time Units) — for deterministic real-time behavior directly on the SoC, without a separate microcontroller.
The Software Architecture
The project follows a strict 5-layer architecture:
┌─────────────────────────────┐
│ Application │ ← Python / Go
├─────────────────────────────┤
│ Services │ ← Go
├─────────────────────────────┤
│ Hardware Abstraction │ ← C / Rust
├─────────────────────────────┤
│ Drivers │ ← C
├─────────────────────────────┤
│ Hardware │ ← AM335x / Linux
└─────────────────────────────┘Each layer only knows the layer directly below it — no bypass, no shortcuts. This is not an academic principle but a pragmatic decision: if I replace the driver for a peripheral six months from now, the rest of the system should not notice.
The Language Mix
C — drivers and HAL, where control matters
Rust — Hardware Abstraction Layer, where memory safety without performance overhead is needed
Go — services and REST API
Python — application layer, scripting, test automation
This is not a language mix for its own sake. Each language is used where its strengths lie.
The Infrastructure
A private project without proper infrastructure quickly degenerates into chaos. That is why the project has had a complete CI/CD pipeline from the start:
GitHub — Git repository and issue tracking
Drone CI — build pipeline, running as a Podman container
Cross-compilation — CMake with ARMv7 toolchain, build runs on x86
Deployment — automatically to the BeagleBone Black after a successful build
Every commit triggers the pipeline. Build, tests, deployment — automatic, reproducible, without manual steps.
Drone CI with Podman instead of Docker has its quirks — there is a dedicated post for that. |
Requirements Management
What sometimes frustrates me in professional projects: requirements that live somewhere in a Word document and have nothing to do with the code.
In this project I use StrictDoc — a document-based requirements management tool that links requirements directly to the code. Every requirement has an ID, every implementation references it. Traceability from requirement to test.
This is overkill for a private project — and that is exactly why I do it. If it works here, it works everywhere.
What Comes Next
This is the first post in a series about this project. All posts in order: