Und dann war da noch die Sache mit dem FPGA. Bevor ich mit diesem Projekt angefangen habe wusste ich nichts darüber, außer das die Dinger schnell sein müssen. Schneller als ein CPLD zumindest, damit hatte ich schon einmal Kontakt als es darum ging Linux mittels einem PassMe auf einem Nintendo DS booten zu können. Das gute beim ersten Kontakt mit dieser Art Baustein war, dass man es mit JTAG ansprechen konnte. Und wenn man in ein Entwicklungs-Board wie das DE0-Nano investiert sogar komfortabel per USB damit arbeiten kann. Allerdings ist so ein FPGA (wiedererwarten) alles andere als ein besserer Mikrocontroller- so meine erste Annahme. Ein FPGA ist für mein Empfinden mittlerweile eine Spielwiese der nur die eigene Rechenkapazität im Gehirn eine Grenze setzt (ja ich weiß sehr hochgestochen).
Die erste Sache die man sich als Software-Entwickler aus dem Kopf schlagen muss, wenn man mit einem FPGA arbeiten möchte, ist das man da ein Programm für schreibt das darauf läuft. Zumindest wenn man VHDL (Very High Speed Integrated Circuit Hardware Description Language) sieht das dann sogar noch wie ein Programm aus. Es verhält sich aber in sehr vielen Punkten einfach so wie man es erwartet. Das fängt an bei parallelen Prozessen, dass Variablen einen bösen Beigeschmack haben können und endet bei der Synchronisierung von Signalen in verschiedenen Clock-Domains. Beißt man sich jedoch durch das Thema durch hat man jedoch ein wirklich sehr komfortables und mächtiges Werkzeug in der Hand um verschiedenste Probleme lösen zu können.
Wie ich bereits in einem früheren Post geschrieben habe, verwende ich für den analogen Teil einen DSP, der in der Lage ist analoge Videosignale in ITU-R BT.656 kodierte Daten zu transformieren. Diese Daten werden in meinem Fall mit 27MHz bitparallel aus dem DSP mit einer Farbtiefe von 10Bit heraus getaktet.
Für den von mir verwendeten XMega deutlich zu schnell wenn man bedenkt das dieser mit 32MHz läuft und ca. 1-2 Takte benötigt um einen einzelnen Pin auszulesen.
Mit der richtigen Hardware-Synthese im richtigen FPGA sind diese Laufzeiten jedoch kein Problem. Was also muss die Hardware-Synthese tun damit das Ergebnis für Ausgabe auf LED-Streifen als Hintergrundbeleuchtung für einen Bildschirm verwendet werden kann. Es ist recht simpel. Der FPGA muss die Pixeldaten taktgesteuert annehmen, puffern, herunter skalieren (von beispielsweise einer PAL-Auflösung) auf eine vom XMega verarbeitbare Pixel-Größe, und ausgeben des Ergebnisses an den XMega. Und all das so, dass mindestens 25 Bilder pro Sekunde verarbeitet werden können um unschönes Geflacker zu vermeiden.
Meine Logik auf dem FPGA realisiert genau das. Zur Laufzeit werden alle Pixeldaten (eines Halbbildes) eingelesen und in einen kleinen OnChip-RAM gepuffert. Gleichzeitig wird über einen Hardware-Algorithmus die Auflösung des Eingangs-Bildes auf 20x20 Pixel skaliert. Warum nur ein Halbbild verwendet wird liegt daran, dass es unnötig ist die volle Auflösung beim Eingangs-Bild zu verwenden wenn man es Bild danach auf ein gerade noch verwendbares Minimum zu skalieren.
Die Übertragung zum Mikrocontroller erfolgt darauf hin direkt aus dem OnChip-RAM heraus. Der Mikrocontroller lädt die Pixel einzeln und komponentenweise, mittels einer Taktleitung und bitparallel über einen 12Bit-Bus aus dem FPGA. Wurden alle Daten übertragen beginnt dieser damit aus den Pixeldaten die Farben für die LEDs heraus zu rechnen. Parallel dazu verarbeitet der FPGA das nächste Halbbild. Der beschriebene Ablauf verarbeitet damit alle 25 empfangenen Halbbilder des Eingangssignals. Die Ausgabe der LED-Farben erfolgt ebenfalls mit 25 "Bildern" pro Sekunde.
Aufgrund der Performance des Gesamtsystems war es sogar notwendig einen Puffer in die Software einzufügen, damit die ausgegebenen Farben mit dem angezeigten Bild synchronisiert werden kann. Der AmbiController ist deutlich schneller in der Bildverarbeitung als mein TV-Gerät.
