Freitag, 4. Dezember 2015

ILI9341 2,2" TFT - Display am Cubietruck


Vor ein paar Wochen habe ich mit bei AliExpress ein 2,2" TFT Display für meinen Cubietruck bestellt. Der Display-Controller auf bzw. hinter dem Display ist ein ILI9341. Leider gab es in der Lieferung des Displays und auch auf der Webseite des Shops keine
weiteren Informationen zu dem Produkt.

Ich bin während meiner Recherche auf diverse Seiten und Youtube-Videos gestoßen, bei denen entweder nur von Problemen berichtet wurde, unvollständig verschiedene Einrichtungsmöglichkeiten dargestellt, oder einfach nur simpel das Ergebnis - ein Display in Aktion - gezeigt wurde.

Um es kurz zu fassen... Das Display kann im Linux-System als Framebuffer-Device eingerichtet werden. Der Zugriff auf das Display geschieht mittels SPI-Bus. Auch ich werde an dieser Stelle nicht auf alle Details eingehen, aber zumindest die Punkte versuchen abzudecken die mir persönlich bei der Einrichtung gefehlt haben.

Das Display verfügt über 9 Pins, davon werden zwei für die Spannungsversorgung verwendet, vier für den SPI-Bus (MISO, MOSI, SCK und CS) und die restlichen drei werden für die Steuerung der LED-Beleuchtung, eine RESET-Leitung und eine Register-Select-Leitung verwendet.

Diese Pins müssen an einen passenden Pinheader des Cubietruck angeschlossen werden.
Im folgenden Bild habe ich dies für meine Hardware eingezeichnet.





Damit ist es das jedoch nicht gewesen, denn der Cubietruck weiß noch nichts davon das an den definierten Pins ein Display angeschlossen ist. Dies teilt man dem Kernel des Cubietrucks über eine Datei im /boot - Verzeichnis mit. Die Datei heißt script.bin. Um in diese die Konfiguration für das Display einzutragen muss man diese zunächst von ihrem Binären Format in ein menschen-lesbares Format umwandeln. Dies geschieht mittels einem normalerweise vorinstalliertem Tool - bin2fex.

root@cubietruck:/boot# bin2fex script.bin script.fex

Öffnen man nun die Datei mit einem Editor seiner Wahl sollte man nach den folgenden beiden Inhalten suchen und diese entsprechend den Beispielen unten anpassen.

Suchen nach spi2_para und die folgenden Anpassungen durchführen.
 

[spi2_para]
spi_used = 1
spi_cs_bitmap = 1
spi_cs0 = port:PC19<3>
spi_cs1 = port:PB13<2>
spi_sclk = port:PC20<3>
spi_mosi = port:PC21<3>
spi_miso = port:PC22<3>


Damit ist nun der SPI-Bus zum Display deklariert, es fehlen noch die übrigen Pins.

Suchen nach gpio_para und ebenfalls die folgenden Anpassungen durchführen.

[gpio_para]
gpio_used = 1
gpio_num = SET THE NUMBER OF DEFINED GPIO PINS
...
gpio_pin_3 = port:PB03<0><0>
gpio_pin_4 = port:PB04<0><0>
gpio_pin_5 = port:PB02<0><0>
...


Um das Display mit dem Cubietruck zu verbinden habe ich mir eine kleine Adapter-Platine erstellt (siehe Bild), diese kann man bei OSHPark.com ansehen und bestellen.




Achtung es kann sein das bereits gpio_pins deklariert sind, diese sollte man nicht anfassen sondern ggfls. die Nummerierung der neuen Pins anpassen. Zudem muss die Anzahl der zu verwendenden Pins im Kopf des Blocks korrigiert werden.

Wurden alle Änderungen durchgeführt muss die Fex-Datei wieder in sein binäres Pendant
umgewandelt werden. Dies geschieht mit dem Tool fex2bin.

root@cubietruck:/boot# bin2fex script.fex script.bin

Damit ist nun der Kernel und die Cubietruck-Hardware - nach einem Reboot - bereit auf das Display zuzugreifen.

Nun muss das Kernel-Modul geladen werden. Es handelt sich dabei um das fb_ili9341 von GitHub welches nun auch Bestandteil der Linux-Kernels ist.

root@cubietruck:/boot# modprobe fbtft dma=1
root@cubietruck:/boot# modprobe fbtft_device custom name=fb_ili9341 buswidth=8 \

                                                       gpios=reset:4,led:5,dc:3 busnum=2 rotate=270 bgr=1 \
                                                       mode=0 speed=64000000 txbuflen=64 fps=25 debug=1

Zunächst wird DMA aktiviert und daraufhin das Kernel-Modul mit einer Standard-Konfiguration geladen. Wichtig hierbei ist das der Parameter gpios die korrekten Pin-Nummern angegeben werden. Der LED-Pin kann bei Bedarf auch weggelassen werden.
Möchte man Problemen auf den Grund gehen kann man beispielsweise den Parameter debug auf den Wert 7 setzen, um die Detailtiefe der Debug-Ausgaben im Syslog drastisch zu erhöhen. Die Bildwiederholrate reduziert sich bei höheren Debug-Leveln jedoch sehr stark. So dauert es beispielsweise auf meinem System um die 35 Sekunden um ein Bild auf dem Display anzeigen zu lassen, wenn die Option debug auf den Wert 7 eingestellt ist.

Ist das Modul korrekt geladen wird unter /dev ein neues Framebuffer-Device eingefügt. Die LED-Beleuchtung wird nach dem erfolgreichen Ladevorgang ebenfalls eingeschaltet, sofern man den LED-Pin im gpios-Parameter angegeben hat. 

Der Parameter rotate gibt in Grad an wie das Display ausgerichtet sein soll. Mit der Option busnum wird angegeben welcher SPI-Port für die Kommunikation mit dem Display verwendet werden soll.
Im Beispiel oben ist der Wert 2 angegeben, dies liegt daran das oben in der Konfiguration der GPIO-Ports für die Hardware SPI2 konfiguriert wurde.

Der Wert 64 bei dem Parameter txbuflen gibt an wie groß der Byte-Buffer zur Datenübertragung an das Display verwendet werden soll. 
ACHTUNG, hier darf der Wert 64 nicht überschritten werden, da die Kommunikation sonst nicht funktioniert. Zumindest nicht mit meiner Hardware - diese hat dedoch auch geneu 0 kB DMA-Buffer zur Verfügung.

Ein Forums-Thread zu dem Problem existiert bereits.

Um zu testen ob das Display korrekt arbeitet kann man z.B. mit dem Tool fbi ein Bild darauf anzeigen.

root@cubietruck:/boot# fbi -d /dev/fb2 -T 1 -noverbose -a

Interessanterweise funktioniert das korrekte Laden des Kernel-Moduls per /etc/modules.conf - Datei nicht. Zumindest nicht auf meinem Armbian Linux. Ich habe die oben stehenden Aufrufe von modprobe in die /etc/rc.local eingetragen.

Möchte man nun noch ein Terminal auf das Display binden kann man das mit der folgenden Zeile einrichten. Auch diese habe ich in die rc.local eingetragen.

root@cubietruck:/boot# con2fbmap 1 2

Damit wird tty1 auf das Framebuffer-Device /dev/fb2 gebunden. !!!ACHTUNG nachdem das Kernel-Modul geladen wurde muss einige Zeit gewartet werden bis con2fbmap aufgerufen werden darf, da das Laden des Moduls einige Zeit im Hintergrund benötigt bis das Laden abgeschlossen ist!!!

Das Ergebnis wird dann in etwa wie auf dem folgenden Bild aussehen.




Wenn jemand mit hier einen Tipp hat wie oder was man verbessern könnte, dann bitte gerne einen Kommentar auf diesen Beitrag hinterlassen. Diese werden aber nicht direkt hier im Blog freigegeben. Ich werde diese dann bei Gelegenheit durch gehen und entsprechend manuell freigeben.

Ich hoffe das dieser kurze Artikel anderen weiter helfen wird und das Mysterium um das ILI9341 - Display etwas deklassiert. Im Nachhinein muss ich jedoch auch sagen das es deutlich einfacher gewesen ist alles einzurichten und das es auch dieses mal deutlich einfcher hätte sein können wenn die bereits vorhandenen Dokumentationsbeispiele detailierter und etwas mehr über den "Tellerrand" beschrieben worden wären.

Die Größte Hilfe bei der Einrichtung bot mit ein in russischer Sprache geschriebener Kommentar zu einem Youtube-Video welches das Display in Aktion zeigt. Dank dem Google-Translator war die sprachliche Hürde an dieser Stelle zu meistern.


Mittwoch, 5. August 2015

AmbiController v0.4.1 - Umfrage Sammelbestellung

Um es kurz zu machen, es gäbe da eine Möglichkeit vollständig aufgebaute AmbiController geliefert zu bekommen. Also von einer Firma professionell aufgebaute AmbiController - Systeme die ohne Kenntnisse über Elektronik und Löten direkt verwendet werden können.


Dazu benötige ich jedoch eine Liste von interessierten Personen um entsprechende Angebote einholen zu können. Die minimale Stückzahl, welche einen annehmbaren Preis ermöglichen würde, liegt jedoch im Bereich um die 30 - 40 Stück oder natürlich mehr.

Daher habe ich eine Umfrage eingerichtet in der sich jeder interessierte seine Wünsche eintragen kann.

Sollten mindestens 30 Personen Interesse signalisieren werde ich den Aufwand auf mich nehmen und versuchen ein passendes Paket zu schnüren.

Dienstag, 30. Juni 2015

AmbiController v0.4.1 - auf tindie.com

Es ist soweit, ich habe auf Tindie einen Artikel angelegt. Es handelt sich dabei um die die jeweils aktuelle Version der Platine. Heute die Version v0.4.1. Diese beinhaltet alle für die v0.4 - Hardware beschriebenen Funktionen.

Bei einer Bestellung lege ich voraussichtlich die folgenden Inhalte der Lieferung bei:
  • Die Platine (siehe hier, nur ohne Bugs)
  • Anleitung (deutsch) in der der Aufbau der Platine und der LED-Streifen beschrieben ist
  • Liste der benötigten Werkzeuge (mechanische als auch elektronische)
  • Liste der benötigten Bauteile für den Aufbau
  • Liste der optional benötigten HDMI-Geräte
  • Angaben zu dem benötigten LED-Streifen und zum Netzteil
  • CDROM/DVD mit einem Snapshot der aktuellen Software und Konfigurationsdateien


Was die Lieferung nicht enthält:
  • Bauteile/Kabel etc.
  • Optionale HDMI-Hardware
  • AVR XMega/Altera Cyclone IV kompatible JTAG-Programmieradapter
  • Netzteil
  • LED-Streifen
  • Ein Gehäuse für den AmbiController


Die Lieferzeit wird einige Wochen dauern, da ich keine Platinen sowie keine der oben genannten Inhalte auf Lager habe. Als eine weitere Option werde ich voraussichtlich ein Paket an Bauteilen zusammenstellen welche optional mitbestellt werden kann. Weiterhin bin ich daran zu testen ob ich eine teilweise vorgefertigte Platine liefern kann, auf der zumindest die ICs aufgelötet sind und ggfls. die Software und das FPGA-Design bereits geflasht worden ist. Auch werde ich prüfen ob es mir möglich sein wird vorgefertigte LED-Streifen anzubieten.

Eine vollständig aufgebaute Platine werde ich nicht anbieten, dies liegt an den Bestückungskosten. Der Preis liegt für kleine prototypischen Stückzahlen bei ca. 350€ pro Platine.

Wie dem Aufmerksamen Leser sicher aufgefallen ist befindet sich das Ganze im Aufbau, Änderungen behalte ich mir also vor.

Ich freue mich auf die ersten Anfragen und vor allem auf konstruktive Rückmeldung/Anregungen.

Dienstag, 9. Juni 2015

AmbiController v0.4 - Bugfix

Wie ich in meinem letzten Post bereits angekündigt hatte war es mein Ziel LED-Streifen an meinem TV anzubringen. Das ist nun erledigt und die neue Hardware wurde ausgiebig getestet. Hier ein paar Bilder dazu.





Hierbei ist noch ein Problem aufgefallen das zu immer schlechter werdenden Farben der Beleuchtung und zu einem starken Flackern geführt hatte. Es handelte sich dabei um ein Temperatur-Problem das dazu geführt hatte, dass der FPGA vom Videoprozessor fehlerhafte Daten empfangen hat. Dies lag aber nicht, wie zu erwarten wäre, daran das der Videoprozessor falsche Daten gesendet hätte. Sondern der FPGA hatte scheinbar ein Problem damit das sich der Eingangs-Tackt des Videoprozessors zum FPGA in Abhängigkeit zu der Temperatur verändert hatte. Der Videoprozessor, inklusive einem der dazugehörigen Spannungsregler, innerhalb von 1-2 so warm das man diesen nicht mehr mit der Hand oder einem Finger berühren konnte.

Da man sich das ganze nur schwer vorstellen kann habe ich das Problem aufgezeichnet.
Man beachte das während der Aufnahme mehrmals das Signalkabel abgezogen und wieder verbunden wurde, so dass der Videoprozessor zeitweise ein komplett schwarzes Bild übertragen sollte. In den beiden Videos (siehe unten) ist gerade in diesen "schwarzen" Videoanteilen deutlich zu sehen das diese nicht schwarz sind, sondern mehr und mehr fehlerhafte Pixel enthalten. Das eigentlich dargestellte Bild, sobald ein Signal angelegt gewesen ist, war hier nicht relevant.



Hier im zweiten Video ist der Videoprozessor bereits sehr viel wärmer geworden, die Auswirkungen auf das Gesamtsystem sind deutlich zu sehen. 



Das Problem im FPGA wurde damit korrigiert das der der HDMI-Support komplett entfernt worden ist. Damit wurde das Timing in der Synthese deutlich toleranter gegenüber Veränderungen geworden. Als nächster Schritt wird jedoch noch jeweils ein passiver Kühler auf einem der Spannungsregler und auch auf dem Videoprozessor angebracht.

Mit dem entfernen des HDMI-Support aus der Synthese sind damit alle Bildprobleme, welche auf der neuen Hardware aufgetaucht waren, entfernt. Weiterhin habe ich nun noch die Kommunikation des AVR mit dem Flash des FPGA auf 7kB/s herauf optimiert, welche aufgrund eines Compiler-Upgrades zunächst gar nicht mehr funktionierte und zuletzt doch ganze 700 Byte/s erreicht hatte.

Ich bin nun zufrieden, wenn es auch wie immer etwas zu tun gibt ;)

Es wird in den kommenden Wochen voraussichtlich trotzdem eine neue Platine geben, da wie bereits in einem früheren Beitrag beschrieben, ein paar wenige Kleinigkeiten verbessert werden können. Das einzige größere Problem bei der aktuellen Version ist das die 5-Volt Eingangsspannung (von USB) nicht mit den Spannungsreglern auf der Platine verbunden ist. Das verhindert natürlich eine Verwendung bei der nur ein USB-Anschluss verwendet werden soll, hindert aber nicht daran das System mit einem der anderen beiden Anschlüsse mit Spannung zu versorgen. Alle weiteren Änderungen sind lediglich zur Verbesserung der Optik gedacht oder um beispielsweise die Wärme besser von den Chips abführen zu können.

Ich werde wie immer darüber berichten.

Samstag, 30. Mai 2015

AmbiController v0.4 - Fertig

Nachdem ich doch eine ganze eine Weile an der Platine gearbeitet habe ist diese endlich fertig aufgebaut. Erfreulicherweise ergaben sich dabei keine gravierenden Probleme in der Platine selbst. Lediglich eine Leitung musste ich nachträglich - per Kupferlackdraht/Fädeldraht - einfügen. Insgesamt ein guter Schnitt, ich bin zufrieden!


Was meine Auswahl der Teile bei der Bestellung angeht sind mir zwei Fehlbestellungen untergekommen. Zum einen Waren die Taster minimalst größer als die benötigten.



Und zum anderen war das Quarz für den Videoprozessor nicht etwa ein einfaches Quarz, sondern ein Oszillator der mit Spannung versorgt werden muss und ein eigenartiges Rauschen erzeugt wenn man diesen dennoch verbaut hat. Die Alternative bot sich aus einem Quarz das ich noch als Ersatzteil für einen anderen Prototypen übrig hatte.


Was die Software angeht habe ich nach einem Update des AVR-GCC diverse Anpassungen machen müssen, damit die Firmware wieder vollständig funktionstüchtig ist. Zudem musste ich in der Routine - welche für das Update des FPGA-Flashes per USB zuständig ist - ein Delay in der Kommunikation einbauen um der USART-Verbindung zum FTDI-Chip die Möglichkeit zu geben die Daten auch tatsächlich übertragen zu können.

Den Schaltplan und das Layout der Platine habe ich bereits angepasst, so dass bei der nächsten Bestellung voraussichtlich keine Überraschungen mehr auftreten werden.

Das einzige was mich nun noch stört bei diesem Projekt ist der Aufbau der Hardware. Mir wäre es recht wenn die eine Firma für mich erledigt. Leider sind die Preise für die Bestückung von einzelnen Prototypen weit über dem Betrag welchen ich mir dafür vorgestellt habe.

Als nächstes werde ich einen weiteren Fernseher mit einem LED-Streifen ausrüsten, hinter meinem Monitor sieht es bereits sehr gut aus!




Mittwoch, 20. Mai 2015

AmbiController v0.4 - Status zum Aufbau

Da ich schon auf Twitter sehr viele Bilder während dem Aufbau gepostet habe möchte ich diese hier nicht unbedingt vollständig nachreichen. Vorenthalten möchte ich die Bilder der (fast) vollständig aufgebauten Platine jedoch nicht...



Momentan arbeite ich an der Inbetriebnahme. Die meisten Elemente sind bereits vollständig eingerichtet und funktionieren.

Sonntag, 10. Mai 2015

AmbiController v0.4 - Platinen wurden ausgeliefert

Und sie sehen wirklich sehr gut aus... mehr muss man da nicht dazu sagen!

Ich werde auf Twitter in den folgenden Wochen den Fortschritt im Aufbau und der Inbetriebnahme regelmäßig online stellen.



Mittwoch, 15. April 2015

AmbiController v0.4 Bestellung/Features

Heute habe ich die Bestellung für drei (3) Exemplare der neuen v0.4 Hardware aufgegeben.
Ich bin sehr gespannt wie diese aussehen werden.

Hier ein paar Fakten:

  • Größe: 74x62mm
  • Platinenhersteller: OSH Park
  • Anzahl der Layer: 2
  • Design-Spec: OSH Park
  • Bestellte Platinen: 3
  • Bauteile:
    • FPGA: Altera Cyclone IV EP4CE6 (50 MHz Takt; 276480 Bit On-Chip-RAM; 6272 LogicCells)
    • 2 MBit Flashspeicher
    • Mikrocontroller: Atmel XMega 192A3 (8/16Bit MCU; 32MHz; 16kB RAM; 192kB Flash; 4kB EEPROM)
    • USB: 1x USB Mini-B Buchse - FTDI 232 RL
    • Video Prozessor: 1x TVP5146M2
    • 1x CVBS - Eingang (Cinch)
    • Reset-Taster
    • Funktions-Taster
    • 6x Status-LEDs (USB/FPGA/AVR)
    • 4x Spannungsregler (1,2V; 1,8V; 2,5V; 3,3V)
    • 1x DC-Buchse (5V)
  • Die Platine kann per USB betrieben werden (ohne Beleuchtung)
  • Kann häufig mit einem USB-Anschluss des TV betrieben werden
  • Die LED-Streifen müssen gesondert mit Strom versorgt werden
  • Die Platine kann ber den Anschluss der LED-Streifen mit Spannung versorgt werden
  • Die Platine kann mit einem 5V Netzteil betrieben werden
  • Software-Stand:
    • Firmware 0.8 (für den v0.4 Hardware-Support)
    • Unterstützung für WS2811/WS2812B LED-Streifen
    • Maximal Anzahl der LEDs auf den LED-Streifen: 320 (~ 5,333 Meter länge bei 60 LEDs/Meter)
    • Software-Update des AVR und FPGA per USB möglich
    • Konfiguration der Software per USB möglich
    • Verarbeitung von vollen 25 Bildern pro Sekunde
    • Kommandozeilen-Tools für die Konfiguration und Steuerung
    • TTY - Emulation
    • Anzeige des verarbeiteten Bilddatenstroms mittels "FrameView"-fähiger Software (BCTool)
    • Automatische Signalerkennung
    • Energiesparmodus
    • Diverse Einstellungsmöglichkeiten:
  • Verarbeitungsgeschwindigkeit
  • Helligkeit der LEDs
  • Grundfarbe
  • Sleep-Timer
  • Weißabgleich
  • Farbe beim verlust des Eingangssignals
  • Unterstützung diverse Bildschirm-Größen (bis zu 55")
  • Verwaltung der "Channel Config" (mit grafischer Oberfläche)

Die beschriebene Software liegt seit heute auf GitHub.


Mittwoch, 8. April 2015

Altera FPGA Konfiguration per SPI Flash im Active Serial-Modus

In meinem AmbiController-Projekt verwende ich einen Cyclone IV EP4CE6 FPGA von Altera. Da in diesem Chip kein persistenter Speicher enthalten ist benötigt dieser einen externen Speicherbaustein wie beispielsweise den EPCS16. Dieser ist jedoch recht teuer. Alternativ kann auch ein einfaches serielles SPI Flash mit z.B. 16MBit Speicher verwendet werden. Wie zum Beispiel ein MP25P16, den ich verwende. Dieser ist schaltungstechnisch identisch zum EPCS16 mit dem FPGA verbunden uns wird per SPI angesteuert. Die maximale Frequenz die bei der Kommunikation verwendet werden kann liegt bei 50 MHz.

Für die Konfiguration des FPGA/Flash habe ich bisher immer einen Altera USB-Blaster - China-Clon verwendet, dieser piept zwar hochfrequent wenn man ihn verwendet aber er tut seinen Zweck sonst einwandfrei. Als Software verwende ich Alteras Quartus II bzw. den "Programmer" welcher dort mitgeliefert wird.

Zum Ablauf: Das Flash wird über den FPGA, welcher per JTAG über den USB-Blaster - Clon beschreiben. Hierzu kommt ein "JIC"-File zum Einsatz damit das Design des FPGA persistent im Flash abgelegt wird. Das funktioniert einwandfrei.

Allerdings muss ich dazu sagen, dass ich damit nicht wirklich zufrieden bin. Das Problem ist, dass man in jedem Fall die doch recht unhandliche Quartus II - IDE benötigt. Und das auch in dem Fall um nur kurz ein neues Design auf den Flash übertragen zu können. Wirklich sehr umständlich!

Ich halte mein AmbiController - System jedoch gerne vollkommen frei von Entwicklungsumgebungen, also überdimensional großen Tools wie ein ATmel-Studio oder auch Altera Quartus II. Es ist daher schon immer mein Ziel gewesen die Firmware des Mikrocontrollers als auch das Design des FPGA per USB aktualisieren zu können. Da der Update-Vorgang eines Mikrocontrollers per USB bereits eher Standard ist, gehe ich hierauf nicht groß weiter ein.

Für das Update des FPGA-Flash-Inhaltes ist jedoch bei weitem mehr zutun als am Anfang gedacht...

Zum gewünschten Abauf:
Der Plan war zunächst den AVR XMega per SPI (parallel) zum FPGA anzuschließen und bei Bedarf auf den SPI Flash zuzugreifen. Per USB wird zum Mikrocontroller eine Verbindung aufgebaut, dieser darauf hin in einen Zustand gebracht in dem der Flash zugängig ist (schreibend und lesend) und das Update kann durchgeführt werden.

Leider steckt hier der Teufel im Detail. Prinzipiell ist SPI auf einem Mikrocontroller eine standardisierte Schnittstelle welche - simpel - mittels ATmel Application notes und kurzen Beispielen quasi direkt verwendet bzw. integriert werden kann.

Leider ist es bei SPI jedoch nicht vorgesehen ein MultiMaster-System aufzubauen - bei SPI kann es immer nur einen Master geben welcher mit allen Slaves selektiert kommuniziert. Aufgrund dieser Gegebenheit muss also der FPGA zunächst in einen Zustand gebracht werden in dem er alle SPI-Spezifischen Pins/Leitungen unberührt belässt. Im Aktiven Zustand würde dieser die Signale des AVR grundsätzlich verfälschen, was natürlich nicht erwünscht ist. Mit unberührt ist hier übrigens gemeint das alle Pins des FPGA als hochohmig konfiguriert sind, also keine messbaren Auswirkungen auf die SPI-Leitungen haben.

In meinem Fall habe ich hierzu die Chip-Enable-Leitung (nCE) des FPGA auf High gesetzt, und die nConfig-Leitung des FPGA auf Low. Damit verfällt der FPGA in einen unkonfigurierten Zustand - zum Glück gibt es bei derart schwer zu findenden Antworten auf derartige Probleme noch nette Leute in öffentlichen Foren - in dem alle Pins hochohmigen geschalten sind. Hochohmig bedeutet, dass hier keine Spannungen (durch den FPGA) anliegen und auch kein (messbarer) Strom in irgend eine Richtung an den betreffenden Pins fließt.

Ist der SPI Bus nun vom FPGA losgelöst kann im Mikrocontroller die SPI-Schnittstelle konfiguriert und verwendet werden. Ist hingegen der FPGA aktiv sollten alle SPI-Spezifischen Pins des Mikrocontroller hochohmig gesetzt worden sein, damit diese nicht die Kommunikation des FPGA mit dem Flash stören. Nachdem der Mikrocontroller die SPI-Schnittstelle nicht mehr benötigt sollte diese also wieder deaktivert werden, die Pins hochohmig geschalten und daraufhin der FPGA wieder in den "normalen" Betrieb geschalten werden. Der FPGA lädt sich daraufhin aus dem Flash das neue Design, sofern es aktualisiert wurde, und beginnt seine Arbeit.

Betrachtet man die einzelnen Aufgaben getrennt voneinander gestaltet sich das "Bild" nun deutlich einfacher, aber der Weg bis dahin kann sich ziehen wenn Informationen fehlen oder - wer hätte das gedacht - wenn die Hardware streikt.

Das interessante während der Entwicklung des Verfahrens war also das an meiner AmbiController - Hardware verwendete ATXMega192A3 den Betrieb der SPI-Schnittstelle verweigerte. Letztendlich habe ich drei (3) SPI-Implementierungen getestet, welche alle die interne SPI-Funktionalität verwenden. Und keine einzige hat auch nur ein einziges mal die Clock- oder MOSI-Leitung angesteuert.

Laut einschlägigen Foren ist natürlich dies absolut unmöglich... Vor allem da die Software, welche ich testen durfte von Personen stammte die sie ja erfolgreich seit Jahren auf anderen Controllern verwenden...
Leider hält sich mein Mikrocontroller aber nicht an deren Überzeugung und verweigert dennoch den Dienst. Auch mit gutem zureden war nichts zu bewege. Abhilfe hat mir dann eine Softwareseitige Implementierung einer Master-SPI-Schnittstelle gebracht. Diese ist vermutlich nicht ganz so performant und kompatibel bzw. generisch implementiert, jedoch fehlerfrei und funktionstüchtig.

Ich habe dann einige Zeit mit den Tests der SPI-Kommunikation verbracht, um einen Treiber zu implementieren welcher die Kommandos des SPI-Flashs beinhaltet, wie beispielsweise Pages zu schreiben oder lesen zu können.

Als Gegenstück dazu implementierte ich ein Kommandozeilen-Tool welches in der Lage ist per USB/Serielle Schnittstelle Daten aus dem Flash per Mikrocontroller auszulesen. Die ersten Tests verliefen zufriedenstellend, es kamen Daten aus dem Flash zurück. Der Sieg über Hard- und Software erschien mir sicher. Zumindest zunächst...

Auf den zweiten Blick hin wurden auch Muster, im Vergleich zu den von Quartus II erstellten Image-Dateien sichtbar. Jedoch mit einigen Unterschieden. Zu vielen Unterschieden...

Beispielsweise waren nur die Muster, also die Verteilung der Bytes in den Hexdumps der Dateien ähnlich/gleich. Nicht jedoch die einzelnen Byte. Dies lag daran das in den SOF- und JIC-Dateien - welche Quartus II einem erstellen kann - noch diverse weitere Header und Footer enthalten sind, und in den Flash-Daten selbst nicht mehr enthalten sind.

Weiterhin besteht der Grund für die Unterschieder ALLER Bytes im Flash zu den Quelldaten darin, dass alle Bytes einzeln nochmal bitweise umgekehrt werden (Bsp.: aus 0b0101_1000 wird 0b0001_1010). Mit einem Script, um Bytes in Dateien umzukehren, wurde der Vergleich des Flash-Inhaltes mit den Quelldateien einfacher.

Leider waren diese noch immer nicht identisch. Das Problem war natrlich das Datenformat der im Flash enthaltenen Daten. Es werden für das Konfigurieren eines FPGAs verschiedene Formate verwendet, welche abhängig sind von der verwendeten "Übertragungsform" und dem Flash (jedenfalls sind das die Hauptaussagen aus diversen Foren). Bei mir ist die Übertragungsform "Active Serial" - und damit eine SPI-Schnittstelle zwischen FPGA und einem seriellen Flash, wobei der FPGA der Master ist und sich die Daten aus dem Flash lädt. Der FPGA unterstützt dabei zudem auch eine Kompression der Daten.

Das untersuchen des Flash-Inhaltes nahm also noch kein gutes Ende. Als nächstes verglich ich verschiedene komprimierte und unkomprimierte - von Quartus II erzeugte - Dateien im RBF-Format (Raw-Binary-File) mit dem Flash-Inhalt. Dort hatte ich im Kopf der Dateien größere Unterschiede als im Rest der Dateien, und jede Zweite Page - im Flash - enthielt im letzten der 256 Bytes einer Page den Wert 0x05. Das RB-File enthielt dort weniger einheitliche Werte. Mein Tool zum Zugriff vom PC aus auf den Flash war zu diesem Zeitpukt bereits weiter entwickelt und nun auch in der Lage Daten in den Flash schreiben zu können...

Warum die Daten unterschiedlich waren konnte mir zunächst niemand sagen - wie auch - es lag an meiner Implementierung. Das letzte Byte einer zu schreibenden Page wurde nie korrekt verarbeitet. Diesen Leichtsinnsfehler/Tippfehler korrigiert, und schon waren die Images nahezu identisch. Lediglich in der ersten Page sind aktuell noch Unterschiede enthalten.

Der Grund ist hierfür angeblich, dass RBF nur für parallele Konfgurations-Arten verwendet werden. Der Header der Datei ist also noch unterschiedlich und das Image damit auch nicht lauffähig.

Was ist aber dann die Alternative?

Eine nette Person wies mich darauf hin, dass man mit den beiden Tools "sof2image" und "objcopy" Images erzeugen kann, welche auch beim konfigurieren mit "Active Serial" verwendet werden können. Die Verwendung ist einfach - sofern man keine Scheu vor einer Kommandozeile hat - es wird die mit Quartus II mitgelieferte NIOS2-Kommandozeige benötigt. Dort laufen alle benötigten Tools einwandfrei (bei Quartus II 13.1 auf Win7 Prof. 64bit und mti 14.x auf Win8.1 und Linux) und man kann die Konvertierung einer SOF-Dateirepräsentation des FPGA-Designs in ein Image vornehmen das dem tatsächlich
benötigten Flash-Inhalt entsprechen soll. Die NIOS2-Kommandozeile ist übrigens unter Windows nur eine "DOS-Box" (cmd.exe) in der ein Cygwin läuft.

Hier ein Beispiel für die Konvertierung:

$ sof2flash --input=fpga_design.sof --output=fpga_design.srec --compress --epcs --verbose
$ objcopy -I sreg -O binary fpga_design.sreg fpga_design.epcs_img -v

Vergleicht man nun die erzeugte Datei mit dem tatsächlichen Flash-Inhalt sind aber auch hier weiterhin Unterschiede vorhanden. Um genau zu sein 3 Byte in der ersten Page. Warum ist unklar - zumindest mir - aber interessanterweise funktioniert das erzeugte Image problemlos.

Damit ist für meinen AmbiController eine größere aber umso spannendere Hürde gemeistert, das FPGA Design per USB aktualisieren ohne die vollkommen überladene Quartus II - Umgebung von Altera verwenden zu müssen.

Was die Übertragungs-Geschwindigkeit angeht, mit der die Daten in den SPI Flash geschrieben werden, möchte ich bei Gelegenheit noch Tests durchführen.

Ich jedoch bereits Übertragungsraten von bis zu 60 kByte/s (lesend) vermessen können. Beim schreiben sinkt diese jedoch auf etwa 5,4 kByte/s (Win8.1 + Cygwin) und ca. 18kByte/s unter Linux.

Da die zu schreibenden Datenmengen jedoch sehr klein sind ist diese Geschwindigkeit noch nicht an bzw. über der Grenze zum unerträglichen.


Fossil-SCM to gource converter

Seit nun mehr als 1 1/2 Jahren verwende ich als Source Control Management - System fossil-scm und visualisiere gerne den Verlauf in der Entwicklung per gourceLeider ist gource nicht in der Lage die sogenannte fossil Timeline direkt zu interpretieren, mal davon abgesehen das fossil diese auf verschiedene Arten ausgeben kann. Und nun suche ich seit einigen Monaten nach einer Möglichkeit die Timeline/History durch gource anzeigen lassen zu können, aber ohne erfolg...

Daher habe ich mir nun selbst einen kleinen Parser in Python implementiert, diesen gibt es auf github.

Usage:
# fossil timeline to txt with names changed files
fossil timeline -n 99999 -v > timeline.txt
# convert timeline to gource custom log format and pipe to gource
python fossil_timeline_to_gource.py timeline.txt | gource

Im Repository sind jedoch auch zwei Scripte enthalten welche die Anwendung des Tools exemplarisch abbilden. Zum einen das "test.sh" welches eine ".fossil" - Datei als Parameter erwartet, und lediglich gource aufruft um die Timeline per gource anzeigen zu lassen. Und zum anderen das "covnert.sh" welches zwei Parameter (".fossil" - Datei und der Video-Datei-Name) erwartet und direkt die Timeline direkt in ein per gource visualisiertes MP4-Video konvertiert.

Hier wieder ein Beispiel-Video...




Donnerstag, 2. April 2015

Die AmbiController - Hardware geht in eine neue Runde

In den letzten Monaten gab es einige Erkenntnisse was den letzten Stand der meine AmbiController-Hardware angeht. Wie ich bereits auf Twitter gepostet habe gab es einige Fortschritte was den ADV7611 angeht, der sich um die HDMI-Verbindung kümmern soll. Leider ist die Software und Hardware hierbei noch nicht soweit voran geschritten um daraus einen neuen Hardware-Release erstellen zu können. Die Idee, an deren Entstehung auch wieder der fu86 stark beteiligt war, ist es dieses mal die bestehende Version v0.2.18 auf einen Stand zu überführen welcher stabil läuft und von jedem direkt benutzt werden kann.
Um dies bewerkstelligen zu können beinhaltet die dadurch entstandene v0.4 - Platine die folgenden Eigenschaften:

- USB 2.0
- Analoger CVBS - Eingang
- Software-Update per USB
- Konfigurations-Interface per USB

Heraus gefallen ist das folgende:

- Bluetooth
- Android App - Unterstützung
- HDMI
- RGB-/YPbPr- und mehrfache CVBS-Eingänge

Zu der Entscheidung die oben genannten Komponenten zu entfernen bin ich gekommen, da ich auch in meiner aktuellen v0.2.18 - Hardware nicht mehr verwendet habe. Dies erleichtert zudem die Bedienung des Gesamtsystems deutlich und man kann drastisch weniger "verkonfigurieren".

Zum UseCase: In meiner aktuellen "Multimedia-Hifi-Welt" existieren verschiedene Geräte wie eine Spielkonsole, ein Receiver und ein optionaler PC, welche alle an einem TV per HDMI angeschlossen werden sollen. Dies geschieht über einen HDMI-Switch. Und zwischen TV und Switch ist zudem ein HDMI-Splitter vorhanden, welcher das Signal zum einen an den TV sendet und zum anderen an einen HDMI zu CVBS - Wandler. Dieser Wandler wiederum ist an den CVBS-Eingang des AmbiControllers angeschlossen. Ganz einfach... siehe Skizze... ;-)



Damit können sämtliche Geräte mit dem AmbiController verwendet werden und da alle auch bereits HDCP unterstützen gibt es hier auch keine Probleme mehr. Und wenn ich ein zweites älteres Gerät verwenden möchte, das per CVBS angeschlossen wird, kann ich auch einfach umstecken oder ein ~1 Euro Cinch - T-Stück dazwischen setzen... 
Das Layout der Platine befindet sich gerade noch in der Prüfung, das Layout steht jedoch bereits fest. Hier ein Beispielfoto wie die Platine aussehen könnte.



Der Vorteil dieser neuen Platine ist, dass diese wieder nur auf zwei Layern abgebildet ist, was die Produktionskosten deutlich verringert und das sich die Anzahl der Bauteile auch deutlich reduziert hat. Weiterhin kann die Software der vorherigen Hardware direkt und ohne große Änderungen verwendet werden. Am FPGA - Design ändert sich auch nichts. Für Anfänger ist das Löten jedoch weiterhin nichts.

Ich hoffe, dass ich in den nächsten Wochen dazu kommen werde die Platine fertig zu stellen und dann in Auftrag geben zu können. Ich hoffe auch auf den einen oder anderen fleißigen Helfer die dann jeweils eine Platine aufbauen dürfen und testen dürfen
ob das ganze praktikabel ist.


UpConverter fixed

Vor einiger Zeit berichtete ich darüber das mein Versuch einen UpConverter für mein rad1o zu bauen leider fehlgeschlagen ist. Es lag an der...