Hallo Leute, ich bin ganz neu im bereich FPGA bzw VHDL unterwegs. Ich habe schon ein paar "Sachen" geschrieben u.A. das senden und empfangen über einen UART (Byte-weise).Jetzt würde ich aber gerne über den FPGA eine Protokoll parsen das ich über den UART empfange. Sprich Adresse, Datenlänge, Datenpacken, CRC,... aus einem unendlichen Stream identifizieren. Kann mir für solch ein Aufgabe jemand ein Beispiel zeigen an dem ich mich langhangeln kann? Vielen Dank
Für das Protokoll oder dessen einzelne Schichten muss man sich entsprechende Zustandsdiagramme malen und kann diese dann recht direkt in Hardware gießen. In den funktionalen Spezifikationen vieler Protokolle finden man auch schon solche Zustandsdiagramme. Wichtig ist dabei vor allem die Fehlerbehandlung, die unerlässlich ist, um sich bei beschädigten Datenpaketen wieder aufsynchronisieren zu können.
Andreas hat schon den richtigen Tip gegeben: Zustandsautomaten im engl. Final-State-Maschine (FSM) sind die Lösung. Wenn das Protokoll nicht allzu kompliziert ist, bekommst Du das recht einfach hin. Wie Andreas schon sagte, vergiss nicht die FSM so zu schreiben dass sie auch bei verlorenen Paket nicht hängenbleibt. Bei sowas langsamen wie UART und bei komplexeren Protokollen kann das auch per Software in einem Picoblaze oder Microblaze machen. Das ist aber Geschmackssache. Ich komme aus der Hardware und hätte es bis vor kurzem komplett dort drin gemacht. Stelle aber gerade ein Projekt auf Zynq um und muss sehen dass man auch mit Software und guten IP Cores machen kann und die Wiederverwendbarkeit sowie die Debugmöglichkeiten schon sehr gut sind. Wenn ich so dran denke, ich hatte mal ein SPI und I2C Protokoll in VHDL implementiert wo jeder unterschiedliche Chip so seine Macken hatte und wie lange ich gebraucht habe dieses in EIN VHDL Modul zu stricken... Heute ist man schlauer. Freddy
Zu dem Thema hängenbleiben der FSM: Wenn der Sender kontinuierlich sendet kannst Du die FSM auch mit einem Watchdog resetten. D.h. wenn die FSM in einem State hängenbleibt wird sie irgendwann automatisch zurückgesetzt. Ist eigentlich recht einfach. Wenn der Sender nicht kontinuierlich sendet wird es schon komplizierter. Zumindest wenn Du keine Daten verlieren darfst.
Hallo, also mein Problem war immer, dass man irgendwie den Anfang und das Ende eines Paketes erkennen möchte. Dazu will man irgendeine eindeutige Bitfolge verwenden die nicht in den Nutzdaten vorkommen kann. Und genau das ist eben schwierig. Gelöst habe ich das so, dass jedes Byte ein feste reserviertes Bit hat das aussagt ob es ein Paketanfang ist oder nicht. Bei mir ist das niederwertigste Bit jedes Bytes 0 ausser es ist ein Paketanfang, da ist es 1. Ja damit verliere ich Nutzdatenrate aber das ist eben ein Kompromiss. Dafür ist es eben so sehrviel einfacher in Hardware zu beschreiben wie wenn da jetzt Escaping und alles drinnen wäre.
Ich würde das durch eine fests Byte am Start und am Ende umgehen, so aller 0xaa am Start und 0x55 am Ende ;-)
Hallo, das hatte schon jemand als Problem gehabt und hat die escape sequenzen erfunden. z.B. Start = 0xaa, Stop = 0x55 Escape 0xD3 Nutzdaten 0xaa 0xD3 0x55 gesendet 0xaa 0xD3 0xaa 0xD3 0xD3 0xD3 0x55 0x55 MfG ich
>Sprich Adresse, Datenlänge, Datenpacken, CRC,... aus einem unendlichen >Stream identifizieren. >Kann mir für solch ein Aufgabe jemand ein Beispiel zeigen an dem ich >mich langhangeln kann? Ich hätte da ein Beispiel. Im Huffman decoder werden die Bildanfänge und Enden und die Quantsierungstabellen aus dem Datenstrom herausgefiltert. http://opencores.org/project,huffmandecoder
Freddy schrieb: > Final-State-Maschine (FSM) Es gibt einen wahrnehmbaren Unterschied zwischen einem "Endgültigen Zustandsautomaten" und einen "endlichen Zustandsautomaten". Deshalb ist die Verlängerung von FSM eben auch "Finite State Machine"...
Lothar M. schrieb: > Freddy schrieb: > Final-State-Maschine (FSM) > > Es gibt einen wahrnehmbaren Unterschied zwischen einem "Endgültigen > Zustandsautomaten" und einen "endlichen Zustandsautomaten". Deshalb ist > die Verlängerung von FSM eben auch "Finite State Machine"... Wobei es oft vorkommt, dass man eine final state machine baut...jedenfalls bei mir :/
Naja, in der theoretischen Informatik ist es ja auch nur wichtig, dass der Automat in einem Endzustand landet. Wie der dahin gekommen ist, interessiert keinen... Ganz im Gegensatz zu den HW-Leuten...
Also ich dachte mir das so, von meinem UART bekomme ich bereits die Daten als 8 Bit std_logic_vector geliefert. Diese Bytes würde ich gerne in eine Art Parser schicken um die Nutzdaten heraus zu filtern Mein "Protokoll" sollte in etwa so aussehen: 1. Byte: 0x0a = Start 2. Byte: 0x0x Datenbyte: 1 Nibbel (also ein halbes Byte) 0x01 bis 0x08 für 1 bis 8 Datenbyte 3. Byte bis max. 11 Byte: Nutzdaten (je nachdem was das Datennibbel sagt wie lang ;-) letztes Byte: 0x50 = Ende Ich tue mich momentan noch extrem schwer mit VHDL und dem parallelem denken... ich habe mehrere Tage gebraucht, bis mein UART mir Daten lieferte und die empfangenen Daten auf 8 LEDs ausgab... Ich wäre für jede Hilfe dankbar!
Georg A. schrieb: > Naja, in der theoretischen Informatik ist es ja auch nur wichtig, dass > der Automat in einem Endzustand landet. Wie der dahin gekommen ist, > interessiert keinen... Ganz im Gegensatz zu den HW-Leuten... Das ist komplett falsch: In der T.I. ist der Endzustand extrem interessant, z.B. beim Erkennen von regulären Ausdrücken etc.. Und wie der Automat dahin gekommen ist, erst recht. Aber zum Problem: Das obige Problem lässt sich mit einer FSM nur zum Teil lösen. Wenn bei obigen Protokoll die FSM aus dem Tritt kommt, dann muss man auch die Quelle und das Ziel (d.h. die FSM) entsprechend anpassen, z.B. durch ein/mehrphasiges Handshake-Protokoll. Aber totale Sicherheit gibt's bei Protokollen iA nicht.
FPGA <= NULL schrieb im Beitrag #4434330: > Ich tue mich momentan noch extrem schwer mit VHDL und dem parallelem > denken... Du musst nicht parallel, sonder seriell denken. Du startest in z.B. Zustand S1, der auf das erste Byte wartet. Dann im nächsten Schritt das nächste Byte verarbeiten etc. Üb das einfach mal mit Zustandautomaten, indem Du zu deinem Protokoll einen Automaten formuliest und per konkreten Daten einen Durchlauf machst.
Sigi schrieb: > Üb das einfach mal mit Zustandautomaten, > indem Du zu deinem Protokoll einen Automaten formuliest > und per konkreten Daten einen Durchlauf machst. Das ist mein Problem, soetwas habe ich noch nie gemacht :-/ Hat jemand ein gutes Skript dazu?
Fang doch einfach mal bei Wikipedia an https://de.wikipedia.org/wiki/Endlicher_Automat und hangel Dich dann weiter.
ich schrieb: > Hallo, > das hatte schon jemand als Problem gehabt und hat die escape sequenzen > erfunden. > z.B. Start = 0xaa, Stop = 0x55 Escape 0xD3 > Nutzdaten 0xaa 0xD3 0x55 > gesendet > 0xaa 0xD3 0xaa 0xD3 0xD3 0xD3 0x55 0x55 > > MfG > ich Also man schreibt dann immer das Ecape-byte vor das Byte das Nutzdaten sind, aber wie ein Befehl aussieht. Dadurch hat man dann aber unterschiedlich lange Pakete. Ok, das mag ok sein, ich wollte das nicht. Aber Danke, werde ich mir merken!
> In der T.I. ist der Endzustand extrem interessant, z.B. beim > Erkennen von regulären Ausdrücken etc.. Und wie der Automat > dahin gekommen ist, erst recht. Naja, der Weg interessiert nicht wirklich, kann ja durch die epsilon-Übergänge auch potentiell verschiedene Wege geben. So ein simpler Automat ist erstmal nur dafür da, um zu überprüfen, ob ein Wort zu einer durch eine Grammatik (Regex, etc.) definierten Sprache gehört. Und das tut es, wenn am Ende des Wortes der Automat in einem Endzustand steht. Allerdings muss der natürlich auch nicht "final" im Sinne einer Sackgasse sein... Natürlich kann sowas in der HW auch interessant sein ("Codeschloss", CRC, etc.), aber der IMO überwiegende Teil der realen HW-Automaten hat keinen explizit interessierenden Endzustand und der zeitliche Ablauf der Zustände und deren Ausgaben (sowas hat der gemeine Automat der TI ja auch nicht) sind das eigentlich entscheidende.
Georg A. schrieb: > Naja, der Weg interessiert nicht wirklich, kann ja durch die > epsilon-Übergänge auch potentiell verschiedene Wege geben. So ein > simpler Automat ist erstmal nur dafür da, um zu überprüfen, ob ein Wort > zu einer durch eine Grammatik (Regex, etc.) definierten Sprache gehört. > Und das tut es, wenn am Ende des Wortes der Automat in einem Endzustand > steht. Allerdings muss der natürlich auch nicht "final" im Sinne einer > Sackgasse sein... OT: vergiss mal epsilon-Übergänge (lassen sich eliminieren) bzw. nichtdeterm. Automaten (lassen sich in determ. Automaten wandeln => eindeutiger Ablauf). Endliche Automaten und Reguläre Ausdrucke sind nur äquivalent, Endliche Automaten darf man aber nicht darauf reduzieren, sie sind zur Beschreibung endloser Abäufe ohne Erinnerung (!) bestens geeignet, von daher: finale Zustände sind Sonderfälle.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.