Vortrag auf der #GPN14

Wer um den 20.6.2014, in Karlsruhe, Besucher der GPN14 gewesen ist konnte meinen kurzen Vortrag über mein AmbiController-Projekt live anhören. Für alle die weder per LiveStream oder vor Ort sein konnten gibt es hier einen Mitschnitt.

Projektlog auf HackADay.io

Ich habe in den letzten Tagen auf HackADay.io dieses Projekt online gestellt und bereits einige Informationen dazu gepostet. Hier geht es direkt zu der Projektseite... 

Autonomous Light Controller - Hardware Synthese

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.

Autonomous Light Controller - Standalone-Hardware funktionstüchtig

Wie immer habe ich auf Twitter (@KaiLauterbach) seit ein paar Tagen oder Wochen immer mal wieder die eine oder andere Sache über den Fortschritt der Inbetriebnahme meiner Platine veröffentlicht. Den aktuellen Stand möchte ich hier aber auch nochmals festhalten.

Wie im letzten Post hier bereits beschreiben ist die Platine vollständig aufgebaut. Seit dem letzten Post habe ich also daran gearbeitet diese zum laufen zu bringen. Das ganze gestaltete sich jedoch nicht ganz so einfach wie es hätte sein können, da sich das eine oder andere wichtige Bauteil grundlegend verändert hatte - im Vergleich zum vorherigen Prototypen.

So wurde beispielsweise der FPGA aus dem ersten Prototyp (Turm-Version) durch eine deutlich kleinere Variante ausgetauscht. Kleiner im Sinne der Anzahl von Pins, dem verfügbaren Speicher und den verfügbaren Logik-Zellen etc.. Um diesen FPGA nun dazu zu bewegen weiter im System mitzuarbeiten musste die, für eine andere Hardware implementierte Hardware-Synthese entsprechend angepasst und getestet werden. Alleine der Aufwand hierfür nahm einige Wochen in Anspruch.

Auch in der Firmware mussten einige Änderungen vorgenommen werden. Zum einen bestehen diese Änderungen angefangen bei der Anpassung an die neuen Hardwarevoraussetzungen der Platine, bis hin zur Implementierung einer neuen Kommunikationsschnittstelle - welche per Bluetooth angesprochen werden kann.

Der Teil zur Verarbeitung analoger Videosignale ist damit vollständig lauffähig. 

Das Video zeigt die neue Platine in Aktion.

Autonomous Light Controller - Platine fertig aufgebaut

Wer mit auf Twitter (@KaiLauterbach) folgt, wird schon des öfteren von Neuigkeiten zu dem Projekt gelesen haben. Das Bild unten zeigt die vollständig aufgebaute Platine. Diese soll den Prototyp (oben) später vollständig ersetzen.

Die neue Platine Funktioniert bereits zu großen Teilen. Bis die Hardware jedoch komplett läuft, wird jedoch noch ein wenig Zeit vergehen. 

Autonomous Light Controller - Platine

Heute ausnahmsweise kurz und knapp - die Platine ist bestellt. Die folgenden Bilder zeigen Screenshots des Layouts aus SketchUp heraus und das Video am Ende soll nur einen kurzen Überblick über die einzelnen Bereiche darstellen. In 8-10 Tagen werden die drei bestellten Platinen eintreffen, es bleibt also spannend. Ich werde bei Gelegenheit weiter darüber berichten.

Autonomous Light Controller - Dizzying Signal Processing

Wie ich in meinem letzten Post geschrieben habe gibt es neben dem Mikrocontroller noch einen weiteren Prozessor, es handelt sich dabei um einen TVP5146M2, von Texas Instruments. Dieser ist ein Videoprozessor, der in der Lage ist analoge Videosignale zu digialisieren und über eine bitparallele Schnittstelle (10- oder 20Bit breit) taktsynchron weiterzuleiten. Er unterstützt alle gängigen analogen Videosignale, wie beispielsweise alle PAL- und NTSC-Varianten. Als Übertragungsmedium wird CVBS, Component RGB und Component YPbPr unterstützt. VGA oder ähnliches nicht.

Die von diesem Prozessor ausgegebenen Videodaten werden nach dem Videostandard ITU-R BT.656 kodiert. Hierbei werden volle Bilder in Halbbildern nacheinander übertragen. Dabei wird - eine im DSP einzustellende - Unterabtastung verwendet. Bei der Übertragung wird durch die Unterabtastung deutlich an Bandbreite eingespart, ohne das es zu erheblichen Qualitätseinbußen kommt.

Der Takt zur Datenübertragung beträgt bei PAL/NTSC, einem 10Bit breiten Datenbus (entspricht 10Bit Farbtiefe) 27MHz, was einem Datenstrom von 27MBit/s ergibt. Leider ist der ATXMega hierbei schon komplett überfordert, da die Datenworte, am Bu,s nur ca. 18,5ns (Nanosekunden) anliegen, und dies drastisch kürzer ist als der Mikrocontroller (selbst bei Übertaktung auf 54MHz, 32MHz ist die empfohlene Obergrenze) erkennen kann.

Die Idee das System mit einem AVR XMega und diesem DSP aufzubauen scheiterte also recht früh in der Entwicklung, da auch der DSP nicht weiter um konfiguriert werden kann um die Übertragungsgeschwindigkeit bzw. die Bildauflösung zu reduzieren.

Jetzt könnte man sagen, dass man einfach einen anderen Mikrocontroller verwendet oder einen anderen DSP. Aber nein - das wäre zu einfach.

Der Flaschenhals bei dem Thema ist der Mikrocontroller. Setzt man nun einen deutlich schnelleren ein, mit dem die ITU-R BT.656-Signale nun verarbeitet werden können, steht man kurz darauf vor dem nächsten Problem sobald man moderne (digitale und hochauflösende) Videosignale verarbeiten möchte. Bei der Bildübertragung eines FULL-HD-Signales mit knapp 1280x1080 Pixeln, selbst mit 10Bit Farbtiefe sind deutlich höhere Taktraten als 27MHz notwendig um die Bilddaten in akzeptabler Zeit zwischen den Prozessoren zu übertragen. Ein Datenblatt eines anderen Signalprozessors (auf den ich in einem Späteren Post eingehen werde) gibt hier Taktraten von etwa 250MHz an. Es wird schnell klar, dass ein bezahlbarer Mikrocontroller hierbei einfach nicht hinterher kommt, so einfach die Lösung auch sein mag. Daher hab ich mich dazu entschieden einen anderen Ansatz zu verfolgen und den einfachen Weg zu verlassen.

Allerdings ist dieser Ansatz bei weitem komplexer und aufwendiger als einfach mehr Rechenleistung zu kaufen. Es geht dabei darum eigene eigene Hardware zu entwerfen, welche die vom DSP übertragenen Daten in Realtime empfangen kann, in der Lage ist diese zeitnah zu verarbeiten, und dem Mikrocontroller vor verarbeitet und in kleinen Portionen zur Verfügung zu stellen. Dazu gibt es aber mehr in einem der nächsten Posts...

Wie jedes mal habe ich in das Git-Repository die dazugehörigen Schaltpäne übertragen.