Hi, ich habe ein kleines Problem wie man am besten Zahlen, die ich über RS232 empfange für die Übertragung zum AXI aufbereite, sodass dann wirklich ein Zahlenwert als integer dargestellt wird und nicht das empfangene als ASCII String. Nehmen wir an, ich empfange: 1TP1000, dabei brauche ich nur die 1000 am Ende. Das Problem ist, es kann auch einmal 1TP500 übertragen werden, wo ich nur die 500 benötige. Ich dachte mir ich nehme aus dem empfangenen Vector Byteweise ab dem 24. Bit die Ziffern und wandel diese in eine Hexzahl um bis das erste Byte keiner ASCII Zahl entspricht. Nun kann es auch sein, dass der Wert Negativ ist (z.b. 1TP-300), dafür wollte ich zuerst prüfen, ob es sich bei dem ersten ASCII um ein Minus oder einer Zahl handelt. Je nachdem setzte ich mir eine Flag und fange an die Zahlen zu sammeln. Wenn jetzt nach 3 Ziffern keine Zahl mehr kommt, wird die erste stelle mit 100 die zweite mit 10 und die letzte mit 1 oder gar nicht multipliziert und alle zusammen summiert. Nun meine Frage ist, ob es hierzu eine saubere Lösung gibt ? Das Problem ist, dass je nachdem wieviele digits ich am Ende habe, der Vektor am größer oder kleiner ist z.b.: signal read_pos: signed(15 downto 0); signal digit1, digit2, digit3, digit4 : signed(3 downto 0); read_pos <= digit1 * 100 + digit2 * 10 + digit 3; und read_pos <= digit1 * 10 + digit2; Ich hoffe ihr versteht mein Anliegen Danke !
fpganoob schrieb: > Nehmen wir an, ich empfange: 1TP1000 Wie wird der übertragene String terminiert? Mit einem NEWLINE 0x0A oder einem CARRIAGERETURN 0x0D? > Nun meine Frage ist, ob es hierzu eine saubere Lösung gibt ? Das ist zuallererst eine Aufgabe, die nichts mit VHDL zu tun hat, sondern mit dem Parsen des empfangenen Strings. > Zahlen, die ich über RS232 empfange für die Übertragung zum AXI aufbereite Was sitzt am anderen Ende "des AXI"? Ein Prozessor? Falls ja, dann würde ich die empfangenen Daten nur puffern und dann den Prozessor die ganze Geschichte machen lassen... > Ich dachte mir ich nehme aus dem empfangenen Vector Wenn es unbedingt in Hardware sein muss, dann würde ich da gar nicht alles empfangen, sondern bis zum 'P' alles verwerfen. Und ab dem 'P eine FSM durchlaufen, die die nachfolgenden Zeichen auswertet. Kommt ein '-', dann merke ich mir das für später. Kommt eine Ziffer, dann wird die in einen integer gespeichert, der mit jeder neu empfangenen erst mal mit 10 multipliziert wird. Kommt das Stringende, dann wird das Ergebins negiert, wenn der entsprechende Merker gesetzt ist, sonst nicht. Fertig.
Danke für deine Antwort Lothar! Terminiert wird über ein linefeed. Ich habe für den Empfang der Seriellen Daten in Vivado ein eigenes IP Core erstellt, welches bis zum LF die Daten empfängt, und dann ein NEWDATA Flag setzt und den ganzen String bereithält. Dieser IP Core ist an meiner Statemachine angeschlossen wo ich dann einfach die NEWDATA Flag triggere und dann den String abhole. Für den String sind 16Byte vorgesehen, alles nach ab dem LF wird einfach mit Nullen beschrieben. Sollte ich den teil nach 1TP direkt über den AXI an die PS mit Linux weitergeben, so benötige ich zuviele Register obwohl auch nur 16 Bit für die Darstellung der Zahlen reichen könnte. Die Lösung mit dem Merker ist eigentlich die treffenste, die werde ich mal so ausprobieren.
fpganoob schrieb: > über den AXI an die PS mit Linux Mache es so wie der Rest der Welt: gib jedes einzelne empfangene Byte an die Software weiter und mach die Auswertung dort. Dann ist dein Interface nur 8 Bit breit und du vergeudest für diese schnarchlangsame Aufgabe nicht unnötig parallele und teure Hardware. Denn parallele Hardware ist nur dort sinnvoll, wo Daten parallel anfallen und verarbeitet werden müssen. Eine serielle Schnittstelle ist in etwa das genaue Gegenteil. Und dass du die seriellen Daten hinterher mit diesem Puffer wieder parallelisierst, macht das Ganze nur unnötig unhandlich...
Lothar M. schrieb: > und du vergeudest für diese schnarchlangsame > Aufgabe nicht unnötig parallele und teure Hardware. Nicht zwingend. Mit einer State-Machine könnte man auch auf 8 Bit parsen. Das ist aber nur bedingt flexibel... Duke
Duke Scarring schrieb: > Mit einer State-Machine könnte man auch auf 8 Bit parsen. Hatte ich auch schon vorgeschlagen. Ich würde die Aufgabe hier trotzdem mit Software im Prozessor lösen.
Einen Parser schreiben, jadie verwenden auch eine Statemaschine, und ja, die kann man auch in VHDL beschreiben
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.