Warum überhaupt?
Wer täglich AUTOSAR-Stacks entwickelt, kennt das Problem: die eigentliche Hardware ist weit weg. Zwischen dem Code den ich schreibe und dem Chip auf dem er läuft stecken Konfigurationswerkzeuge, Build-Systeme, Integrationsprozesse und meistens noch ein Evaluierungsboard das ich mir mit dem Rest des Teams teile.
Privat wollte ich das anders haben. Ein Board, das mir gehört. Ein Projekt, das ich von Anfang bis Ende selbst verantworte — Anforderungen, Architektur, Implementierung, CI/CD. Kein Auftraggeber, kein Prozess-Overhead, kein Kompromiss.
Der BeagleBone Black war die naheliegende Wahl: ARM Cortex-A8, AM335x, Linux-fähig, gut dokumentiert, und seit Jahren in der Embedded-Community etabliert. Kein Raspberry Pi — der BeagleBone ist näher an der Hardware, und genau das war der Punkt.
Was das Projekt ist
Es ist kein Produkt und kein Tutorial-Projekt. Es ist eine Plattform auf der ich Dinge ausprobiere, die mich beruflich interessieren — aber unter Bedingungen, die ich vollständig kontrolliere.
Konkret: ein Embedded-System mit einer strikten 5-Schicht-Architektur, mehrsprachigem Stack und einer vollständigen CI/CD-Pipeline — so wie ich es auch in einem professionellen Projekt aufbauen würde, nur ohne die Constraints eines Kundenprojekts.
Die Hardware
Board: BeagleBone Black
Prozessor: Texas Instruments AM335x, ARM Cortex-A8, 1 GHz
RAM: 512 MB DDR3
Storage: 4 GB eMMC + microSD
Schnittstellen: GPIO, I2C, UART, SPI, USB, Ethernet
Der AM335x ist interessant weil er neben dem Cortex-A8 auch zwei PRU-Cores (Programmable Real-Time Units) mitbringt — für deterministisches Echtzeit-Verhalten direkt auf dem SoC, ohne separaten Mikrocontroller.
Die Softwarearchitektur
Das Projekt folgt einer strikten 5-Schicht-Architektur:
┌─────────────────────────────┐
│ Applikation │ ← Python / Go
├─────────────────────────────┤
│ Services │ ← Go
├─────────────────────────────┤
│ Hardware Abstraction │ ← C / Rust
├─────────────────────────────┤
│ Treiber │ ← C
├─────────────────────────────┤
│ Hardware │ ← AM335x / Linux
└─────────────────────────────┘Jede Schicht kennt nur die Schicht direkt darunter — kein Durchgriff, keine Abkürzungen. Das ist kein akademisches Prinzip, sondern eine pragmatische Entscheidung: wenn ich in sechs Monaten den Treiber für ein Peripheriegerät austausche, soll der Rest des Systems das nicht merken.
Der Sprachenmix
C — Treiber und HAL, dort wo es auf Kontrolle ankommt
Rust — Hardware Abstraction Layer, dort wo Speichersicherheit ohne Performance-Overhead gefragt ist
Go — Services und REST API
Python — Applikationsschicht, Scripting, Testautomatisierung
Das ist kein Sprachenmix um des Sprachenmixes willen. Jede Sprache ist dort eingesetzt wo ihre Stärken liegen.
Die Infrastruktur
Ein privates Projekt ohne vernünftige Infrastruktur degeneriert schnell zum Chaos. Deshalb hat das Projekt von Anfang an eine vollständige CI/CD-Pipeline:
GitHub — Git Repository und Issue-Tracking
Drone CI — Build-Pipeline, läuft als Podman-Container
Cross-Kompilierung — CMake mit ARMv7-Toolchain, Build läuft auf x86
Deployment — automatisch auf das BeagleBone Black nach erfolgreichem Build
Jeder Commit triggert die Pipeline. Build, Tests, Deployment — automatisch, reproduzierbar, ohne manuelle Schritte.
Drone CI mit Podman statt Docker hat seine Tücken — dazu gibt es einen eigenen Post. |
Anforderungsmanagement
Was mich an professionellen Projekten manchmal frustriert: Anforderungen die irgendwo in einem Word-Dokument leben und mit dem Code nichts zu tun haben.
In diesem Projekt verwende ich StrictDoc — ein dokumentenbasiertes Anforderungsmanagement-Tool das Anforderungen direkt mit dem Code verknüpft. Jede Anforderung hat eine ID, jede Implementierung referenziert sie. Traceability von der Anforderung bis zum Test.
Das ist Overkill für ein privates Projekt — und genau deshalb mache ich es. Wenn es hier funktioniert, funktioniert es überall.
Was als nächstes kommt
Das ist der erste Post einer Serie über dieses Projekt. Alle Posts in der richtigen Reihenfolge: