Hallo alle, ich habe vor mithilfe von RxTx Daten zu meinem Spartan 3E zu senden. Nur hin, nicht zurück. Die Daten sollen einfach Bits bzw Bytes sein, die ich über eine GUI erzeugen lassen möchte (klickt man auf Button A, soll 001 übertragen werden). Habe noch Verständnisschwierigkeiten mit RxTx. Es wird ja meistens 1 Startbit, 8 Datenbits, 1 Stoppbit (ohne parity) übertragen. Heißt, ich kann jedesmal 1 Byte übertragen. Es werden also nacheinander die einzelnen Bits übermittelt. Man benutzt die .write() Methode. Heißt wenn ich jetzt schreibe outptStream.write(data) und data ist einfach "101011", dann reicht ein Durchgang (die 8 Datenbits reichen) und die Daten sind auf meinem FPGA. Wenn jetzt aber data "10000000011100000" wäre, dann würden die ersten 8Bits übersendet, dann das Stopbit - Startbit und die nächsten 8 Bits usw. Mein FPGA würde das aber trotzdem als zusammenhängende Zahl erkennen? Erst ab einer bestimmten Pausenlänge zwischen Stop- und Startbit, würde mein FPGA das als neuen Input erkennen und anders damit umgehen? Also es wird solange gewartet, bis eine Pause auftritt, dann macht das FPGA hofentlich was ich möchte und beim nächsten Signal macht es das gleiche mit den neuen Daten? Danke
> würde mein FPGA das als neuen Input erkennen und anders damit umgehen? Nur du weißt was du in dein FPGA reingemacht hast. > Wenn jetzt aber data "10000000011100000" wäre, Das sind 17 Bytes. ich denke du solltest erst mal Grundlagen lernen. Erkläre mir z.B. mal was ASCII Zeichen sind und warum Binär 01010101 das gleiche ist wie hex 55 und warum hex 55 das gleiche ist wie ASCII U.
0101 = 5hex = 5dez, das bekomm ich grad noch so hin :P 10101 sind doch 5 Bits?! Warum 5 Bytes? 1Byte = 8Bit ?! Deswgen bin ich davon ausgegangen, dass die Wertfolge "10000000011100000" 17 Bit und nicht 17 Byte sind. ASCII ist halt nochmal ne andere Codierung. >> würde mein FPGA das als neuen Input erkennen und anders damit umgehen? >Nur du weißt was du in dein FPGA reingemacht hast. Naja gehen wir mal davon aus, dass ich "data" als Input in meinem VHDL Code habe, dann würde also ab der bestimmten Pause ein neues "data" benutzt werden und vorher wird solange gewartet, bis die Pause auftritt und alles was vor der Pause reingekommen ist, wird als zusammenhängende Zahl interpretiert?
Und woher weiß
> outptStream.write(data)
,daß "data" als einzelne Bits zu interpretieren sind und nicht als ASCII
String ? Also ich als Compiler würde jetzt annehmen du meinst "01010101"
als String, es könnte aber auch ein 32Bit Integer sein oder nen 8 Bit
char.
> Naja gehen wir mal davon aus, dass ich "data" als Input in meinem VHDL > Code habe, dann würde also ab der bestimmten Pause ein neues "data" > benutzt werden und vorher wird solange gewartet, bis die Pause auftritt > und alles was vor der Pause reingekommen ist, wird als zusammenhängende > Zahl interpretiert? Du mußt einen UART in VHDL implementieren, der mit der richtigen Baudrate und den Richtigen länge des Datenwortes und dem Start und Stopbit arbeitet. Der hat dann auch nen Rxd und nen Txd Anschluß. Dann kann man damit jeweils ein Byte nach dem anderen bitseriell empfangen und senden. Das ding macht man mit nem Counter und ner Statemachine. Wenn das Funktioniert machst du noch ne Statemachine und denkst dir nen Protokoll aus, welches du in dieser Statemachine implementierst. Dann schreibst du auf der PC Seite auch ne Statemachine die mit dem gleichen Protokoll arbeitet. Und fertisch ...
Ja, wenn ich das Senden der Daten mit VHDL machen würde, dann würde ich das so wie du sagst machen. Aber ich will das ja mit Java machen. Die write() Methode weiß, dass sie Bytes übergeben bekommt, ging mir nur ums Verständnis, wie der Transport funktioniert
> Die write() Methode weiß, dass sie Bytes übergeben bekommt
Also sendet sie für jede 1 ein ASCII zeichen, in diesem Fall 0x31 oder
auch 0b00110001 und für jede 0 ein 0b00110000.
Felix O. schrieb: > Wenn jetzt aber data "10000000011100000" wäre, dann würden die ersten > 8Bits übersendet, dann das Stopbit - Startbit und die nächsten 8 Bits > usw. Mein FPGA würde das aber trotzdem als zusammenhängende Zahl > erkennen? Du selber bist für das Protokoll und das Framing verantwortlich, denn du selber hast ja den Sender und den Empfänger entwickelt... Felix O. schrieb: > ging mir nur ums Verständnis, wie der Transport funktioniert Welcher Teil des Transports? Du hast hier immer noch grundlegende Verständnisschwierigkeiten wie im Beitrag "Re: Allgemeine Verständnisfragen PFGA/VHDL/RS232". Hast du deine Gedanken mal sortiert und das Konzept aufgezeichnet (ja, so richtig auf Papier)? Und dann beantwortest du (dir selber) mal die folgenden 8 Fragen: Was willst du warum und wie von wo nach wo in welcher Menge und in welcher Zeit übertragen? BTW: wenn es hier nur um das "Programmieren eines Programms zur Übertragung von Daten über eine serielle Schnittstelle in Java" geht, dann bist du im falschen Forum...
Lothar Miller schrieb: > Du selber bist für das Protokoll und das Framing verantwortlich, denn du > selber hast ja den Sender und den Empfänger entwickelt... okay > Welcher Teil des Transports? > Du hast hier immer noch grundlegende Verständnisschwierigkeiten wie im > Beitrag "Re: Allgemeine Verständnisfragen PFGA/VHDL/RS232". Hast du deine > Gedanken mal sortiert und das Konzept aufgezeichnet (ja, so richtig > auf Papier)? allerdings, die habe ich, deswegen suche ich ja hier nach Hilfe :) Habe jetzt deinen Tip befolgt und mir mal eine mind-map gemacht > Und dann beantwortest du (dir selber) mal die folgenden 8 Fragen: > Was willst du warum und wie von wo nach wo in welcher Menge und in > welcher Zeit übertragen? Okay also ich bin jetzt gedanklich soweit, dass ich vorhabe mit VHDL einen Uart zu implementieren, der aber nur fürs receiven verantwortlich ist (also ein UAR eigentlich). Beim Senden mithilfe von Java kann man angeben, wie die Baudrate etc ist, also sollte das so hoffentlich funktionieren.. > BTW: wenn es hier nur um das "Programmieren eines Programms zur > Übertragung von Daten über eine serielle Schnittstelle in Java" geht, > dann bist du im falschen Forum... Jap, darum solls hier deswegen auch nicht gehen Danke euch
So habe jetzt meinen UAR (nur receiver) fertiggeschrieben. Zur Hilfe habe ich das Video-Tutorial von "BöserKommunist" genutzt. Ein Ausschnitt..
1 | if (index < 9) then |
2 | index <= index + 1; |
3 | else
|
4 | if data_sn(0) = '0' and data_sn(9) = '1') then --Start- u Stopbit erkannt |
5 | data <= data_sn(8 downto 1); --in data unsere 8 Datenbits |
6 | else
|
7 | data <= (others => '0'); -- bei Fehler data auf 0 setzen |
8 | end if; |
9 | rx_status<='0'; --es wird nichts mehr übertragen |
10 | busy<='0'; --wir sind nicht mehr busy |
11 | end if; |
Das ist mein Schlussabschnitt um den es mir gerade geht. Es werden also die 8 Datenbits in mein "data" geschrieben und der Prozess wartet wieder darauf, dass es losgeht (das also ein Startbit = 0 erkannt wird). Also werden in den Wartezeiten zwischen dem Senden zweier Daten immer die 1 des Stopbits weitergesendet? Wenn ich jetzt ein Datum reinbekomme, das größer als 8 Bit ist, wie handhabe ich das? Muss ich mir mein data dann vor der nächsten Übertragung abspeichern und dann nach meinetwegen 4 Durchgängen (32 Bits) per Hand und dem &-Operator die Bits zusammenfügen? Oder gibt es da andere Möglichkeiten? Danke!
Felix O. schrieb: > Also werden in den Wartezeiten zwischen dem Senden zweier Daten immer > die 1 des Stopbits weitergesendet? Wenn du so sagen willst, ja. Aber eigentlich ist das Stopbit nur die Bedingung, dass ausreichend lange Zeit zum Erkennen des nächsten Startbits zur verfügung steht. Und die '1' vom Stopbit ist einfach nur der "Ruhepegel", wenn nichts gesendet wird... Felix O. schrieb: > Wenn ich jetzt ein Datum reinbekomme, das größer als 8 Bit ist, wie > handhabe ich das? Muss ich mir mein data dann vor der nächsten > Übertragung abspeichern und dann nach meinetwegen 4 Durchgängen (32 > Bits) per Hand und dem &-Operator die Bits zusammenfügen? Ja, aber... > Oder gibt es da andere Möglichkeiten? ... du musst dir etwas ausdenken, das dir die Möglichkeit gibt, das "erste" Byte zu erkennen. Denn was, wenn du dein FPGA so einschaltest, dass es mitten drin das dritte Byte zuerst empfängt? Bist du dann weiterhin um 2 Bytes versetzt? Das was die serielle Schnittstelle auf Bitebene macht (Start- und Stopbit), das musst du auf Byteebene machen: du musst eine Anfangskennung mitgeben. Bei der in der Musik verwendeten Midischnittstelle ist es z.B. so, dass das gesetzte höchstwertige Bit 7 in einem übertragenen Wort ein neues Statusbyte anzeigt und damit einen neuen "Frame" einläutet. (Ich hatte genau dieses Wort "Framing" übrigens schon mal ins Spiel gebracht, das war nicht nur "so dahergelabert"...) In deinem Fall könnte es z.B. so sein, dass du 24 Bits mit der Information 0x81, 0xc3 und 0xe7 übertragen willst:
1 | 0x81 0xc3 0xe7 |
2 | 10000001 |
3 | 11000011 |
4 | 11100111 |
Und du sagst: in den obersten 2 Bits übertrage ich mit der seriellen Schnitstelle eine Position, die angibt, wohin die nachfolgenden 6 Bits im Empfangswort kommen. Dann wirst du also 4 Byes mit dem Inhalt 0x20, 0x5c, 0x8f, 0xa3 übertragen:
1 | Pos Daten |
2 | 00 100000 --> 00100000 --> 0x20 |
3 | 01 01 1100 --> 01011100 --> 0x5c |
4 | 10 0011 11 --> 10001111 --> 0x8f |
5 | 10 100111 --> 10100111 --> 0xa3 |
6 | | 0x81 | 0xc3 | 0xe7 |
Und dann musst du die 32 Bits nach der Übertragung einfach wieder richtig auseinandernehmen und anhand der mitübertragenen Position die gewünschten 24 Bits wieder zusammensetzen.
Ahja, macht Sinn dass man das dann auch mit einer Anfangserkennung macht. Danke!
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.