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...