Vor der Weiterentwicklung müsste man sich noch Mal in die build pipeline reinlesen, das war immer großer Krampf. Der code hängt von irgendwelchen Bibliotheken ab, bin unsicher welche gerade.
Aktuell existiert ein funktionierendes C-Programm, das einen Buffer für Pixeldaten bereitstellt, einen TCP-Server öffnet und die Pixel aus dem Buffer direkt an den VGA-Ausgang schickt.
Der TCP-Server nimmt Pixeldaten als rohe bytes aus Paketen entgegen und speichert diese direkt in den Buffer.
Da der Buffer durchgängig über VGA gerendert wird, kann man so durch gehend das aktuelle Bild sehen.
Der code hängt von irgendwelchen Bibliotheken ab, bin unsicher welche gerade.
In den pico-examples und den pico-extras findet man aber Code, der sehr ähnlich ist.
Die Build-Pipeline war immer sehr wackelig und ich hab nicht ganz verstanden was da passierte...
# Rewrite in Rust
Ich würde gerne Rust lernen, das ist eine Sprache etwa auf der gleichen Abstraktionsebene wie C++.
Mit Rust könnte die Build-Pipeline etwas einfacher/ordentlicher werden. Da nerven keine Makefiles und man muss nich wissen was nen Headerfile is, omg C ist SO ALT.
Die Roadmap dafür ist aktuell:
- [] Blinky: on board LED blinken lassen mit Rust Programm
- [] Netzwerk: mit dem Netzwerk-Chip kommunizieren
- [] VGA: pixeldaten über das VGA-Board an den Anschluss senden, noch keine Bild-Generierungs-Logik, nur erstmal schauen, obs klappt
- [] SD-Karte: schauen wie daten auf die Karte geschrieben / von der Karte gelesen werden
## Ressourcen und Notizen
Der Chip auf dem Pico ist ein RP2040.
"rust runs on EVERYTHING (no operating system, just Rust)" von Low Level
Kleine Anleitung Blinky in Rust auf den R-Pi Pico zu übersetzen. Benutzt rp2040_hal
https://www.youtube.com/watch?v=Yi0WRF5WPFw
rp2040_hal: Der Hardware Abstraction Layer ist eine Rust-Bibliothek (Crate), die die Kommunikation mti dem rp2040-Chip vereinfacht/ermöglicht.
https://docs.rs/rp2040-hal/latest/rp2040_hal/
Embassy: Ein Framework für Microcontroller. Hier gibt es einiges um mit der Netzwerk-Hardware zu arbeiten. Das könnte sehr gut sein.
Außerdem zielen die drauf ab parallele Ausführung (async) zu verwenden. Was wichtig werden könnte. Wie sich Embassy mit dem R-Pi verhält weiß ich noch nicht.
https://embassy.dev/
Wenn die builds wieder gut klappen, könnte man folgendes weiter umsetzen:
# Ziele für die kommende Version
- UDP statt TCP, aber muss man vielleicht nochmal abwägen, is auch nich so wichtig hm
- Validierungsmechanismus, dass wirklich alle Pixel-Zeilen angekommen sind
- anderer Ansatz für das buffering
- Lesen von Bildern von der SD-Karte
- Speichern von Netzwerk-Übertragenenen Bildern auf die SD-Karte
- Steuerprogramm für den Show-Rechner/Kontroll-Rechner
