Wir schreiben den FPGA-Loader in LabVIEW. Teil 2

Laden Sie die Konfiguration über USB auf das FPGA herunter oder zerlegen Sie FTDI MPSSE
Wir schreiben den FPGA-Loader in LabVIEW. Teil 1

Im ersten Artikel haben wir den Ladealgorithmus auf dem guten alten C getestet, im zweiten Artikel haben wir herausgefunden, wie man ein Programm in LabVIEW organisiert und eine einfache Benutzeroberfläche implementiert. Dieses Mal werden wir uns mit neuen Arbeitsmethoden in LabVIEW vertraut machen, die Funktionen der Fehlerbehandlung analysieren und das Projekt abschließen: Wir implementieren das Protokoll zum Laden der Konfigurationsdatei in das FPGA.

Fehlerbehandlung

Öffnen Sie den Quellcode und analysieren Sie die Funktion MPSSE_open. Trotz der algorithmischen Einfachheit (Funktionen werden nacheinander aufgerufen) müssen einige D2XX-API-Elemente importiert werden: FT_ResetDevice , FT_Purge , FT_SetUSBParameters , FT_SetChars , FT_SetTimeouts , FT_SetLatencyTimer , FT_SetFlowControl , FT_SetBitMode Wie im vorherigen Artikel gezeigt , wird der Import von Funktionen über den Call library Function Aufrufbibliothek ausgeführt. Dieser Knoten verfügt über dedizierte Terminals zur Fehlerkontrolle. LabVIEW hat eine einfache Regel: Alle VIs müssen Fehler verfolgen und Fehler melden, die von Fehlerterminals zurückgegeben werden. Die meisten eingebauten VIs folgen genau dem. Ich hoffe, jeder versteht, wie wichtig es ist, Fehler zu kontrollieren und zu behandeln, insbesondere in der Debugging-Phase, aber es gibt einen anderen Grund, warum dies so wichtig ist, dass es für "klassische" Programmierer nicht offensichtlich ist. LabVIEW enthält im Blockdiagramm keine strikte Reihenfolge der Geräte: Das Gerät wird ausgeführt, wenn Daten an seinen Eingängen bereit sind. Wenn die Daten von der Ausgabe eines VIs auf die Eingabe eines anderen VIs übertragen werden, ist klar, dass zu Beginn das erste VI funktioniert, erst danach das zweite. Was aber, wenn keine Datenübertragung stattfindet und die VIs unabhängige Aktionen ausführen? Natürlich können Sie die umständliche "Flat Sequence Structure" verwenden, aber es ist viel bequemer, die Geräte durch einen Strom von Fehlern miteinander zu verbinden.

Beim Importieren von D2XX-Funktionen treten zwei Arten von Fehlern auf. Der erste - dies ist ein direkter Importfehler - gibt den Call library Function Aufrufbibliothek selbst zurück. Der zweite ist ein Fehler der Bibliothek selbst, der von fast jeder Funktion über FT_STATUS . Alle möglichen Werte werden in der Header-Datei ftd2xx.h als enum beschrieben. Obwohl es ausreicht zu wissen, dass der FT_OK Wert das Fehlen eines Fehlers ist und alle anderen Werte Fehlercodes sind, möchte ich nicht nur die Tatsache des Fehlers selbst verfolgen, sondern auch, welcher Fehler aufgetreten ist und wo genau er aufgetreten ist.

In LabVIEW werden Fehlerdaten über Fehlercluster weitergegeben. Dies ist ein spezieller dedizierter Datentyp. LabVIEW verfügt über viele VIs und Funktionen, mit denen Sie arbeiten können. Der Fehlercluster besteht aus drei Elementen: einer logischen Variablen - zeigt den Status an, eine ganzzahlige vorzeichenbehaftete Zahl - einen Fehlercode, eine Zeichenfolge - die Fehlerquelle. Der Status gibt an, ob ein Fehler aufgetreten ist, der Fehlercode bestimmt seinen Typ und wird von speziellen VIs zum Generieren eines Berichts verwendet. Die Zeile gibt eine detailliertere Vorstellung davon, wo genau der Fehler aufgetreten ist. LabVIEW akzeptierte, dass wenn der Status TRUE , dies ein Fehler ist, wenn der Status FALSE ist, der Code jedoch nicht Null ist und die Beschreibungszeile nicht leer ist, dies eine Warnung ist , wenn der Status FALSE , der Code Null ist und die Zeile leer ist - es gibt keinen Fehler.

LabVIEW enthält eine interne Datenbank, in der jeder Fehlercode seiner Beschreibung zugeordnet ist. Für jeden Fehlertyp wird ein spezieller Bereich von Codewerten zugewiesen. Für die mit dem Betrieb des Netzwerks verbundenen Fehler werden beispielsweise mehrere Bereiche zugewiesen: von –2147467263 bis –1967390460, von 61 bis 65, von 116 bis 118 und 122, 1101, 1114, 1115, 1132 bis 1134, von 1139 bis 1143 und von 1178 bis 1185 Für benutzerdefinierte Fehler sind zwei Bereiche von –8999 bis –8000 und von 5000 bis 9999 reserviert. Aus diesen Bereichen können Werte für die Fehlercodes der D2XX-Bibliothek ausgewählt werden.

Erstellen wir ein VI, das den Status der D2XX-Funktion als Eingabe empfängt und diesen Status in einen LabVIEW-Fehlercluster konvertiert. Die meisten Funktionen und VIs in LabVIEW, die am Eingang Error In Status TRUE erhalten haben, führen ihren Code nicht aus, sondern übertragen Fehlerinformationen an das Terminal Error Out . Auf diese Weise können Sie effektiv Informationen über die Quelle über die gesamte Kette an den Fehlerbehandler übertragen, wodurch die Ausführung von Code im Notfallmodus entfällt. Es ist wünschenswert, dass sich unsere VIs ähnlich verhalten.

Lassen Sie uns die Liste der D2XX-Status in Form einer enum anordnen und in einen separaten Typ einfügen (im vorherigen Artikel haben wir dies mit FTDI-Typen getan).

Wir speichern das neue VI unter dem Namen FT_error.vi. Wir fügen Error Out Frontpanel zwei Cluster Error In und Error Out Sie finden sie im Panel "Array, Matrix & Cluster". Wir verbinden sie mit den Klemmen am Anschlussfeld in der unteren linken bzw. unteren rechten Ecke, wie bereits im vorherigen Artikel erwähnt. Dies ist die Position der von LabVIEW übernommenen Fehlerflussklemmen. Wir fügen die Case dem Blockdiagramm hinzu, geben den Error In Cluster an die Eingabe für die Error In ändert die Case ihre Farbe und teilt zwei Unterdiagramme: "Kein Fehler" - grüne Farbe und "Fehler" - rote Farbe. Im Fehlerfall übertragen wir den Fehlercluster vom Auswahlterminal direkt in den Ausgangstunnel am rechten Rand. Und im grünen Fall fügen wir je nach Status einen weiteren Case , der bestimmt, ob ein Fehler erstellt werden soll (Status ist nicht gleich FT_OK) oder unverändert bleibt: Überspringen Sie den Eingabefehlercluster, um ihn ohne Änderung zu beenden.

Um den Fehlercode technisch in einen Cluster zu konvertieren, können Sie das VI- Error Cluster From Error Code VI . Dieses SubVI fügt der Fehlerbeschreibung eine Aufrufkette hinzu, sodass wir nicht nur feststellen können, was passiert ist, sondern auch, wo es passiert ist.

Verwenden Sie den Eigenschaftsblock, um den dem Eingabestatus entsprechenden Text (FT_Status) auszuwählen: Wählen Sie "RingText.Text". Der Fehlertext wird an die error message des Error Cluster From Error Code VI gesendet.
Vergessen Sie nicht, ein "sprechendes" Symbol zu zeichnen.

Um FT_error zu testen, können Sie ein leeres VI erstellen, das erstellte VI dort hinzufügen und sehen, wie sich der Wert beim Start ändert, wenn verschiedene Status angewendet werden.

Nach jedem Funktionsaufruf von der D2XX-API verwenden wir nun SubVI FT_error.vi. Eine Gruppe von Fehlern durchläuft alle VIs in der Anrufhierarchie.

In den VIs der obersten Ebene müssen wir entscheiden, was mit dem erkannten Fehler geschehen soll: Sie können eine Meldung im Dialogfeld anzeigen, in die Berichtsdatei schreiben, ignorieren oder die Anwendung einfach "leise" beenden. Das Dialogfeld ist die einfachste und beliebteste Methode, um Fehler zu melden. Es ist auch praktisch für einen unerfahrenen Programmierer, da es nichts zu tun gibt. In jedem VI ist der automatische Fehlerbehandlungsmodus standardmäßig aktiviert ( Aktivieren Sie die automatische Fehlerbehandlung in der Kategorie Ausführung des Menüs VI-Eigenschaften). Dies funktioniert folgendermaßen: Wenn in einem Knoten das Error Out Ausgangsterminal nirgendwo angeschlossen ist und in diesem Knoten ein Fehler auftritt, hält LabVIEW die Anwendung an und zeigt ein Dialogfeld an. Wenn das Error Out Terminal des Knotens angeschlossen ist, breitet sich der Fehlerstrom wie programmiert aus und es werden keine zusätzlichen Aktionen ausgeführt. Das Nachrichtenfenster kann jedoch programmgesteuert aufgerufen werden. Dazu müssen Sie die VIs General Error Handler und Simple Error Handler (im Bereich Dialog & Benutzeroberfläche) verwenden. In diesem Fall können wir die Fehlerinformationen verwenden, um das Programm zu vervollständigen. In einem Blockdiagramm sieht es ungefähr so ​​aus:

Klickbares Bild

Wenn ein Fehler auftritt, wird das Programm angehalten, ein Berichtsfenster wird angezeigt. Nach dem Schließen des Fensters wird das Programm korrekt beendet.

Öffnen und schließen Sie FTDI

Also zurück zur Funktion MPSSE_open . Erstellen Sie ein neues VI . Fügen Sie zunächst die Terminals für den Fehlerstrom hinzu. Fügen Sie eine Auswahlstruktur hinzu und wählen Sie Error In Eingabe auf dem Selektor. Im grünen Fall importieren wir die Funktionen in der Reihenfolge und mit den Parametern wie im Sishny-Prototyp. Alle Knoten des Call Library Function Node durch einen Fehlerstrom in einer Kette verbunden. Im roten Fall durch den Tunnel verbinden wir Error In mit dem Ausgangsanschluss des Fehlers.

Klickbares Bild

VI MPSSE_open.vi

Eine Zeile mit der Beschreibung von FTDI ( Description ) wird an den Eingang von SubVI geliefert, am Ausgang befindet sich Handle und ein initialisierter FTDI-Chip im MPSSE-Modus.

Lassen Sie uns einen VP erstellen, der die Arbeit mit FTDI beendet und Sie können bereits die Leistung auf der Hardware überprüfen.

Im vorherigen Artikel haben wir zum Debuggen der Schnittstelle den VI-Stub SP_FT_MPSSE_FPGA.vi erstellt. Jetzt ist es an der Zeit, ihn zu füllen. Fügen Sie MPSSE_open.vi und FT_Close.vi zu seinem Blockdiagramm hinzu. Zu diesem Zeitpunkt ist es ziemlich schwierig zu beurteilen, ob die Initialisierung korrekt war. Ein Handle Wert ungleich Null am Ausgang von MPSSE_open.vi und das Fehlen eines Fehlers sagen jedoch viel aus.

Flussdiagramm SP_FT_MPSSE_FPGA.vi

Um den Wert von Handle Sie das "Probe Watch Window" verwenden. Dies ist ein praktisches Debugging-Tool, mit dem Sie den Wert von Daten auf jedem (fast jedem) Kabel während der Ausführung des Geräts anzeigen können. Um das Sample auf die Linie zu setzen, müssen Sie im Kontextmenü dieser Linie "Probe" auswählen. Das Fenster "Probe Watch Window" wird geöffnet und eine Nummer mit der Probennummer wird in der Zeile angezeigt. Im obigen Bild ist es "3".

Großartig! Wir starten die VIs der obersten Ebene und verbinden die Debug-Karte mit dem Computer. Eine Beschreibung des angeschlossenen FTDI-Chips wird in der Liste "Gerät auswählen" angezeigt. Klicken Sie auf die Schaltfläche "Programm" und ... nichts passiert. Nur im Fenster "Probe Watch" wurde der Wert Handle angezeigt. Und das ist gut.

Wir schalten die Karte aus, die Liste der Geräte wird gelöscht. Klicken Sie auf "Programm". Hier öffnet sich das Fehlerberichtfenster.

Nach dem Klicken auf die Schaltfläche "Weiter" schließt das VI seine Arbeit ab.

Es ist verboten, die Taste zu drücken, wenn keine Geräte gefunden werden. Wir ändern die Ereignisbehandlungsroutine "Timeout". Ich möchte Sie daran erinnern, dass an einen PC angeschlossene FTDI-Chips zweimal pro Sekunde gescannt werden. Wenn sie erkannt werden und zum Programmieren von FPGAs verwendet werden können, werden ihre Deskriptoren über die Eigenschaft Strings[] zur Strings[] hinzugefügt. Wir erstellen die Eigenschaft Disabled für "Programmieren". Wenn keine geeigneten Geräte gefunden werden, schalten Sie die Schaltfläche aus und verdunkeln Sie sie.

GPIO beherrschen

Nachdem MPSSE aktiviert wurde, erfolgt die Arbeit mit ihm über den sogenannten "Op-Code", und nur FT_Write , FT_Read und FT_Queue werden aus den FT_Write API-Funktionen verwendet (um den Status des Empfängerpuffers herauszufinden). Wir erstellen das entsprechende VI entlang der von uns erstellten Spur: FT_Write.vi, FT_Read.vi, FT_Queue.vi.

Aus diesen drei Bausteinen legen wir nun die VIs zum Lesen des parallelen Anschlusses und zum Schreiben darauf. Der Wert wird zweckmäßigerweise als Array von Booleschen Variablen dargestellt.

Wie bereits im ersten Artikel erwähnt , ist das passive serielle FPGA-Startprotokoll nichts anderes als ein SPI mit zusätzlicher Flag-Manipulation. Es werden insgesamt fünf Abschnitte verwendet: Die Zeilen DCLK , DATA [0] , nCONFIG müssen als Ausgänge konfiguriert werden, die Zeilen nSTATUS , CONF_DONE als Eingänge.

Wir brauchen einen VP, der den Wert auf dem ausgewählten Bein ändern kann, ohne alle anderen zu beeinflussen. Erstellen Sie zunächst Enum mit den Seriennummern der Beine im Port und speichern Sie es als "Strict Type Def" in der Datei SP_LBYTE_BITS.ctl. Wir erstellen ein neues VI und fügen die bekannten Fehlerfluss-Terminals hinzu. Wir lesen den aktuellen Wert des parallelen Ports mit MPSSE_Get_LByte.vi, ändern mit der Funktion Replace Array Subset das gewünschte Bit und schreiben den Wert zurück in den Port (MPSSE_Set_LByte.vi).

Um mit der Konfiguration zu beginnen, muss der MPSSE auf der nCONFIG- Leitung einen Übergang von niedrig nach hoch erzeugen . Sobald das FPGA bereit ist, Daten zu empfangen, bildet es auf der nSTATUS- Leitung einen hohen Pegel. Zu diesem Zeitpunkt ist alles bereit für das Experiment in Eisen. Im Blockschaltbild SP_FT_MPSSE_FPGA.v fügen wir die Steuerleitung nCONFIG hinzu - nach der Initialisierung der MPSSE geben wir einen niedrigen und dann einen hohen Pegel an. Nach jeder Operation (zum Debuggen) lesen wir den Status der Portzweige.

Im Allgemeinen ist beim Start von VI klar, dass das FPGA auf den Übergang auf der nCONFIG- Leitung reagiert - auf dem nSTATUS-Zweig wird Null und dann Eins gesetzt. Es ist jedoch nicht überflüssig, dies mit einem Oszilloskop zu überwachen. Fast jedes Zweikanal-Oszilloskop mit Trigger-Triggerung (Standby) ist geeignet. Kanal A (blaue Spur) Ich habe den Kontrollpunkt der Schaltung nCONFIG , Kanal B (rote Spur) - Kette nSTATUS eingegeben . Der Trigger wird auf die fallende Flanke von Kanal A gesetzt.

Das Bild ist anklickbar. Mit den Details!

Mit Datei arbeiten

FPGA ist bereit, die Konfigurationsdatei zu akzeptieren. Sind wir bereit, die Datei auf das FPGA zu übertragen?

LabVIEW enthält eine Reihe umfangreicher Tools zum Arbeiten mit Dateien. Ich kann nicht sagen, dass die Funktionalität für absolut die gesamte Bandbreite der Aufgaben ausreicht. Grundlegende Vorgänge wie Lesen und Schreiben werden jedoch einfach und angenehm ausgeführt. Die grundlegenden VIs für die Arbeit mit Dateien finden Sie im Bereich "Datei-E / A". Um das Problem zu lösen, müssen Sie die Konfigurationsdatei öffnen, ihre Größe bewerten (wir müssen wissen, wie viele Bytes das FPGA senden soll), sie lesen und schließen. Alles ist einfach und nacheinander. Wir verwenden die Open/Create/Replace File , Get File Size , Read from Binary File , Close File refnum , sie mit der refnum kombinieren und refnum - eine Nummer, z. B. ein Dateideskriptor, wird beim Öffnen der Datei erstellt und sollte an die Eingabe anderer VIs übertragen werden, mit denen gearbeitet wird diese Datei.

Bisher können wir die gelesenen Daten nirgends entsorgen. Wenn Sie jedoch die Funktionsfähigkeit der Kette wirklich überprüfen möchten, können Sie einen Indikator vom Typ String erstellen und ein wenig einrichten. Aktivieren Sie im Kontextmenü die Option "Hex-Anzeige", aktivieren Sie die vertikale Bildlaufleiste (Sichtbare Elemente -> Vertikale Bildlaufleiste) und beobachten Sie nach dem Start den Inhalt der binären Konfigurationsdatei.

Zwei unabhängige parallele Codezeilen, die im Blockdiagramm des VIs gebildet werden, werden daher für sie separate Fehlerketten verwendet. Um parallele Flüsse in ein Error Out Terminal zu reduzieren, wird die Funktion Merge Errors verwendet. Diese Funktion sucht nach Eingabefehlern von oben nach unten (ja, es können mehr als zwei Eingangsanschlüsse vorhanden sein, sie werden mit der Maus gedehnt) und gibt den ersten zurück, den sie findet. Wenn keine Fehler vorliegen, wird die erste Warnmeldung zurückgegeben. Wenn keine Warnungen vorhanden sind, liegt kein Fehler in der Ausgabe vor. Es ist wichtig zu beachten, dass die Verbindungsreihenfolge der Eingaben für Zusammenführungsfehler die Priorität von Fehlern bestimmt. Wenn ein Fehler sofort in zwei Ketten auftritt, wird der niedrigere Fehler ignoriert. Dies sollte sorgfältig behandelt werden.

Wenn wir versuchen, die Schaltfläche "Programm" im VI der obersten Ebene zu drücken, ohne eine Datei auszuwählen, erhält die Eingabe SP_FT_MPSSE_FPGA.vi einen leeren Pfad, der den Fehler "Fehler 1430. LabVIEW: (Hex 0x596) Der Pfad ist leer oder relativ. Sie müssen einen verwenden absoluter Weg. " Wie mein Freund aus Kindertagen sagt: "Kleinigkeiten, das ist etwas Weltliches!" Und dieser Fehler ist überhaupt kein Fehler, sondern Unaufmerksamkeit des Benutzers. Wir werden das Programm nicht stoppen und es mit einem Fenster mit einem roten Kreuz beschwören, wir entfernen einfach den Fehler mit diesem Code aus dem Stream und im Dialogfeld empfehlen wir dem Benutzer, sich für die Datei zu entscheiden. Verwenden Sie zum Filtern des Fehlers das VI "Fehler löschen" in der Palette "Dialog & Benutzeroberfläche". So zeigen Sie die Meldung an: "One Button Dialog".

Konfiguration herunterladen

Für die serielle Datenübertragung muss der MPSSE-Prozessor den Op-Code 0x18 senden. Die Befehlsargumente sind die Länge der übertragenen Sequenz (zwei Bytes, beginnend mit der niedrigsten) und die Datensequenz selbst. Die Länge wird minus eins codiert. Senden wir den Datenblock als VI MPSSE_send.

Die Größe des Eingabepuffers ( Array Size ) wird in einen Doppelbyte-Typ U16 konvertiert. Wir subtrahieren einen, tauschen die niedrigen und hohen Bytes ( Swap Bytes ) aus. Sie müssen die Länge beginnend mit dem niedrigsten senden und die Doppelbyte-Zahl in ein Einzelbyte-Array ( Type Cast ) konvertieren.

Die Type Cast Funktion verdient besondere Aufmerksamkeit. Dies ist ein solcher universeller Konverter, dessen Einfallsreichtum manchmal sehr überraschend ist. Kurz gesagt:

Optisch für den Programmierer

Dies ist jedoch nicht nur eine Umwandlung von Daten in einen anderen Typ, sondern auch eine heuristische Interpretation. Mit dieser Funktion können Sie eine Konvertierung zwischen inkompatiblen Datentypen durchführen, während die Funktion nicht zögert, die Eingabedaten auszurichten und sogar die "zusätzlichen" Teile zu entfernen. Wenn der angeforderte Datentyp mehr Speicher als die Eingabedaten benötigt, weist die Funktion die fehlende Menge zu. Für einen unerfahrenen Entwickler kann LabVIEW Type Cast ein Lebensretter werden, aber mit zunehmendem Alter ist es besser, einen solchen Konverter abzulehnen - er ist den Augen sehr verborgen und kann zu unerwarteten Fehlern führen. Es ist besser, explizitere Konvertierungsmethoden wie Coerce To Type .

Bei der Initialisierung des MPSSE-Prozessors setzen wir die maximal zulässige Größe des Puffers für die Datenübertragung auf 65536 Byte. Daher müssen wir die Konfigurationsdatei in Fragmente unterteilen, deren Größe die angegebene Größe nicht überschreitet. Wir werden die Array Subset Funktion verwenden. Diese Funktion wählt ein Subarray aus dem Array aus, beginnend mit dem Indexelement und einer langen length . Wir werden es in einer While Schleife brechen, wir werden jede Iteration des Index um 65536 erhöhen, zwischen den Iterationen werden wir den Wert durch das Schieberegister übergeben. Sobald es nicht möglich ist, 65536 Bytes aus dem Hauptarray zu entfernen, nehmen wir alles, was übrig bleibt, senden es und stoppen den Zyklus.

Gemäß dem Download-Protokoll müssen nach der Übertragung aller Daten zwei weitere Taktimpulse angelegt werden, um die FPGA-Initialisierung zu starten. Dazu senden wir nach der Schleife ein weiteres "leeres" Byte.

Um den Erfolg der Firmware zu verstehen, betrachten wir die Flags. Wenn CONF_DONE auf eins gesetzt ist, melden wir dem VI der obersten Ebene, dass alles in Ordnung ist.

Das Programm ist abgeschlossen. Es bleibt sicherzustellen, dass das FPGA erfolgreich geflasht wurde und die Karte mit LEDs glücklich blinkt.

Über VP Naming

, , LabVIEW, , SubVI. . :

• — , FTDI, API D2XX. "FT", FT_Close.vi FT_Read.vi.
• — MPSSE. "MPSSE". : MPSSE_open.vi, MPSSE_Set_LByte.vi, MPSSE_Get_LByte.vi.
• — "Passive Serial" MPSSE. "S". , SP_FT_MPSSE_FPGA.vi ( , ) SP_LBYTE_BITS.ctl.
• . . , .

( ), . subVI .

Fazit

, , .

, LabVIEW, . , , , ( ). .

1. . LabVIEW: . Per. . . .– .:
   , 2008 – 400 .: .
2. labview_mpsse . .
3. .
4. Software Application Development D2XX Programmer's Guide . API D2XX.