Hallo, ich hoffe ihr könnt mir weiter helfen. Ich kenne mich leider mit den RS232-Spezifikationen nicht so gut aus und sitze gerade vor dem Problem,dass ich am liebsten Daten von UART empfangen würde ohne auf das Startbit zu achten. Im Detail: - 1. Startbit wird zu Detektion des Übertragungsbeginns benutzt - Dann wird ein Timer gestartet, der in an die Baudrate angepasster Frequenz die Bytes liest und bitweise versendet. - Ein Empfänger soll sie entsprechend empfangen Vorraussetzung dafür wäre, dass es mit RS232 möglich ist einen konstanten Datenstrom zu erzeugen, der sich genau timen lässt. Da das Konzept dies meiner Ansicht nach nicht erfordert wollte ich nun wissen, ob es evtl. doch geht. Die Verbindung ist übrigens PC -> µC Schonmal vielen Dank! :)
Bei RS232 wird jedes Startbit zur Resynchronisierung des Empfängers benutzt. Darüber mußt du dir im Klaren sein.
Ja, das ist mir klar. Meine Frage ist halt, ob es in gewissem Maße trotzdem geht, oder ob nach dem Stopbit immer eine undefinierte Pause ist.
Zumindestens vom PC aus ist kein definiertes Timing hinzubekommen. Da werden immer mal wieder ein paar Zeichen abgeschickt, wenn der Therad gerade dran ist.
Hi >Ja, das ist mir klar. Meine Frage ist halt, ob es in gewissem Maße >trotzdem geht, oder ob nach dem Stopbit immer eine undefinierte Pause >ist. Auf der PC-Seite hast du so gut wie keinen Einfluss. Die Daten werden gepuffert und der PC entscheidet, wann und wieviel gesendet wird. MfG Spess
Hm, iwie hab ich das schon befürchtet... Hatte nur gehofft, dass es noch iwelche Hardwarenahen Puffer oder iwas gibt für sowas.. Danke auf jeden Fall erstmal!
Was willst du damit denn überhaupt anfangen? Mir erschließt sich der Sinn nicht. Ahnungen habe ich natürlich. Wenn du auf dem PC direkt auf den UART zugreifst, dann sollte ein kontinuierlicher Datenstrom möglich sein. Der UART hat einen FIFO. Windoof darf halt nicht dazwischen funken.
Das ganze soll zu Demonstrationszwecken von Kanalstörungen dienen. Normales RS232 hängt sich ja auf, sobald ich kurz den Stecker ziehe o.ä. Und der SRAM von meinem AVR reicht leider nicht, um für hohe Datenraten genügend zu Puffern, sodass ich versuche ohne Pufferung auszukommen. Ich programmiere derzeit unter Linux mit dem hardwarenahen :D java Später soll das ganze aber wahrscheinlich auch unter windoof laufen.
Hallo, was du meinst, ist im Wesentlichen synchrone Datenübertragung, da wird synchronisiert (aber nicht nur mit einem Bit, sondern mehreren Bytes, damit eine PLL einrastet) und dann ein Block Bits nahtlos übertragen. Aber dazu brauchst du kein UART, sondern ein USART, und im Detail ist die Sache einiges komplizierter, weil z.B. lange Folgen von 0 oder 1 verhindert werden müssen. Du kannst mal hier anfangen: http://www.yourdictionary.com/telecom/synchronous-transmission oder nach SDLC/HDLC suchen. Hauptproblem: du hast die Hardware dafür nicht. Gruss Reinhard
Achso, sollte vllt. noch anmerken, dass es eigentlich nichtmal über RS232 läuft, sondern über USB mit nem FTDI-Chip auf dem µC-Board, was meine Probleme wahrscheinlich nicht gerade kleiner macht!? ;)
Hallo! Erstens: Es ist es möglich, mit RS232 einen kontinuierlichen Datenstrom zu versenden. Es ist ja nur eine physikalische Spezifikation, keine logische. Zweitens: Es gibt Periferiebausteine, die erlauben eine synchrone serielle Übertragung. Dazu verwendet man Takt- und Datenleitungen. Du kennst das ähnlich von SPI. Drittens: Es gibt Betriebssysteme und Software die eine kontinuierliche Bereitstellung bzw. Abholung der Daten ermöglichen. Sorry, auf eine unkonkrete Frage gibts nur unkonkrete Antworten.
Sorry! Zu spät. Das kommt davon, wenn es mal an der Tür klingelt.
Enrico J. schrieb: > Das ganze soll zu Demonstrationszwecken von Kanalstörungen dienen. > > Normales RS232 hängt sich ja auf, sobald ich kurz den Stecker ziehe o.ä. > Nein. Es werden an den 'Grenzen' maximal zwei Zeichen verloren (die eventuell Frame-Error erzeugen, die aber vielleicht nicht durchgereicht werden) und alle dazwischenliegenden Zeichen. Je nach UART werden auch fehlende Stopbits erkannt - meistens aber nicht. Was du unter Kanalstörung verstehst, wird meist als Frame-Error-Rate betrachtet. Frames werden auch irgendwie synchronisiert!! Es gibt Standards! Es gibt Bit-Sync und auch Byte-Sync und Syncs auf jeder Ebene des Kommunikationsmodells... > Und der SRAM von meinem AVR reicht leider nicht, um für hohe Datenraten > genügend zu Puffern, sodass ich versuche ohne Pufferung auszukommen. > Dieses Detail kannst nur du verstehen. Warum nicht die Rate runtersetzen? > Ich programmiere derzeit unter Linux mit dem hardwarenahen :D java > > Später soll das ganze aber wahrscheinlich auch unter windoof laufen. Die zwei Punkte werden dich bestimmt beschäftigen ;-)
Enrico J. schrieb: > Das ganze soll zu Demonstrationszwecken von Kanalstörungen dienen. > > Normales RS232 hängt sich ja auf, sobald ich kurz den Stecker ziehe o.ä. Das ist dann aber ein Software-Fehler. Ein korrekte Implementierunf eines fehlertoleranten Protokolls hängt sich nicht auf. Einzige Möglichkeit warum sich der Empfänger nicht mehr richtig auf den Bitstrom einklinken kann ist, wenn der Sender tatsächlich nicht mal die klitzekleinste Pause macht, so dass der Empfänger das Startbit nicht mehr findet. Selbst die kleinste Pause führt über kurz oder lang durch die Stoppbits dazu, dass der Empfänger das Startbit wiederfindet. Ist es das was du demonstrieren möchtest?
Ok, ich gebe zu "Aufhängen" war eine etwas fehlleitende Bezeichnung. Meine, dass der Datenstrom damit kaputt geht, der gebraucht wird. Es gibt keine Chance zu erkennen welche Bytes der Empfänger nicht mitbekommen hat (jedenfalls in meinem Fall). Das ganze sollte im Idealfall so funktionieren, dass wenn ich nach dem Start der Übertragung alles weitere übertragene blockiere, der Empfänger trotzdem Daten ausliest. Und wenn ich für die letzten 3 gesendeten Bytes nicht mehr blockiere sollen dies auch als die letzten 3 Bytes der Übertragung empfangen werden. Und ich will nicht explizit RS232-Fehlerbehandlung demonstrieren! ;) Gegen Datenrate runter ist übrigens mein Projektleiter leider ;) Danke!
Enrico J. schrieb:
> Gegen Datenrate runter ist mein Projektleiter leider ;)
Das kann ich verstehen.
Aber die Lösung lautet nicht, da jetzt irgendwelche 'Spezial' Software
zu schreiben, die das BS soweit austrickst, dass alles kontinuierlich
läuft.
Die Lösung lautet: sich ein Protokoll zu überlegen, mit dem der
Empfänger die Gültigkeit der Daten feststellen kann und sich
zweifelsfrei auf den Beginn eines Datensatzes einlocken kann.
Alles andere ist ... Murks
Karl heinz Buchegger schrieb: > Einzige Möglichkeit warum sich der Empfänger nicht mehr richtig auf den > Bitstrom einklinken kann ist, wenn der Sender tatsächlich nicht mal die > klitzekleinste Pause macht, so dass der Empfänger das Startbit nicht > mehr findet. Für den Fall kann man ab und zu Bytes einfügen die keine 2.Startflanke enthalten (0x00, 0x80, 0xC0, ...). Danach ist der Empfänger wieder synchron. Peter
grusel In der Praxis kommt heutzutage eh nur noch die Einstellung Stopbit gleich eine Datenbitbreite vor. Bei asynchronem UART muß definitiv keine Lücke zur Resynchronisierung vorhanden sein. Das ist ja haarsträubend wie wenig Wissen hier vorhanden ist! Nach der Hälfte des Stopbits lauert der Empfänger wieder auf eine fallende Flanke im Falle von TTL-Pegel. RS232 ist leitungsmäßig immer genau invers und die Pegel sind weiter auseinander. Der Empfänger kann bei vorhandenem FIFO völlig bitsynchron ein Byte nach dem anderen rausschieben. Einfachste UARTs haben anstatt des FIFO nur ein einziges Byte in einem vorgelagerten Register, was dann beim Start des nächsten Bytes in PISO-Register geladen wird (Das entspricht einem 1-Byte FIFO). "buffered" - ermöglicht Interrupt-Betrieb. Z.B. des Manual des SCC8530 sollte man komplett durcharbeiten. Dauert halt einen Abend. Oder 8051 Manual. Dort ist beschrieben wie der 8051 pro Bit dreimal sampelt... Auch sollte man wissen, wo die Geschichte der UARTs herstammt, nämlich von den technischen Unzulänglichkeiten eines mechanischens Fernschreibers. Durch weitere Überlegungen kann man dann Konstrukte finden, bei denen Sende- und Empfangs-UART unterschiedliche Einstellungen haben und trotzdem sinnvolle Daten übertragen. Oder wenn der einer der Partner sehr frequenzinkonstant ist, in den Bits eines Bytes weitere Taktinformation unterbringen. siehe Propeller-Manual.
Ach ja, übrigens ist beim PSoC der Empfänger mit einer Macke versehen, wodurch er bei berauschten RS232-Signal nicht korrekt am Startbit synchronisiert.
Abdul K. schrieb: > Bei asynchronem UART muß definitiv keine Lücke zur Resynchronisierung > vorhanden sein. Das bezweifle ich. Leg mal ein Rechtecksignal mit 50% Tastverhältnis und z.b. 9600 Hz Frequenz an den RX-Pin einer mit 19200 Baud und 8n1 arbeitenden UART an.
1 | _ _ _ _ _ _ _ _ _ _ _ _ |
2 | / \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_ |
3 | S 0 1 2 3 4 5 6 7 S S 0 1 2 3 4 5 6 7 S S |
4 | t t t t t |
5 | a o a o a |
6 | r p r p r |
7 | t t t |
8 | |
9 | (RS232-Pegel, für TTL entsprechend invertieren) |
Das unterscheidet sich irgendwie nicht von der Übertragung lauter Bytes mit dem Wert 0xAA. So, und nun stell Dir mal eine Übertragung vor, bei der sehr lange Zeit der Wert 0xAA übertragen wird - und dann plötzlich ein anderer. Und nun wird kurrzeitig die Verbindung gekappt und wiederhergestellt, während noch lauter 0xAA übertragen werden. Und?
@ Rufus t. Firefly (rufus) (Moderator) Benutzerseite >> Bei asynchronem UART muß definitiv keine Lücke zur Resynchronisierung >> vorhanden sein. >Das bezweifle ich. Ich nicht. Wobei man die Aussage etwas präzisieren muss. 1.) Der Empfänger hat am Anfang genug Zeit zum Synchronisieren, spricht, es müssen mind. 10 Bitzeiten Ruhe sein. 2.) Der USART kommt zwischendurch nicht durch ein gestörtes Signal/unterbrochene Leitung aus dem Tritt, wenn dadurch Stop oder Startbit invertiert werden. Wenn das gilt, kannst du ewig und drei Tage mit dem UART LÜCKENLOS empfangen. >So, und nun stell Dir mal eine Übertragung vor, bei der sehr lange Zeit >der Wert 0xAA übertragen wird - und dann plötzlich ein anderer. Ist vollkommen egal, der UART ist dennoch synchron. >Und nun wird kurrzeitig die Verbindung gekappt und wiederhergestellt, >während noch lauter 0xAA übertragen werden. Das ist was anderes und nicht Bestandteil der ursprünglichen Aussage. Deshalb meine Präzisierung. MFG Falk
Falk Brunner schrieb: > 2.) Der USART kommt zwischendurch nicht durch ein gestörtes > Signal/unterbrochene Leitung aus dem Tritt, wenn dadurch Stop oder > Startbit invertiert werden. > > Wenn das gilt, kannst du ewig und drei Tage mit dem UART LÜCKENLOS > empfangen. Lies nochmal die vorhergehenden Postings. Genau diese Voraussetzung liegt nicht vor. Er will definitiv das Kabel abziehen und wieder anstecken können. Beitrag "Re: Zeitlich konstanter RS232-Datenstrom möglich?" [quote] > Das ganze soll zu Demonstrationszwecken von Kanalstörungen dienen. > Normales RS232 hängt sich ja auf, sobald ich kurz den Stecker ziehe o.ä. [/quote]
Karl heinz Buchegger schrieb: > Falk Brunner schrieb: > >> 2.) Der USART kommt zwischendurch nicht durch ein gestörtes >> Signal/unterbrochene Leitung aus dem Tritt, wenn dadurch Stop oder >> Startbit invertiert werden. >> >> Wenn das gilt, kannst du ewig und drei Tage mit dem UART LÜCKENLOS >> empfangen. > > Lies nochmal die vorhergehenden Postings. > Genau diese Voraussetzung liegt nicht vor. > Er will definitiv das Kabel abziehen und wieder anstecken können. > Ja. Der TO hat offensichtlich keine präzise Vorstellung wie die Dinge laufen. > Beitrag "Re: Zeitlich konstanter RS232-Datenstrom möglich?" > [quote] >> Das ganze soll zu Demonstrationszwecken von Kanalstörungen dienen. >> Normales RS232 hängt sich ja auf, sobald ich kurz den Stecker ziehe o.ä. > [/quote] Dafür war RS232 nie gedacht! Sondern für eine stationäre Verbindung sehr hoher Zuverlässigkeit. Genausowenig funzt TCP/IP oder ISDN gut über Funkstrecken. Z.B. sollte ursprünglich GSM das ältere ISDN auf eine Funkverbindung aufmotzen. Das schlug fehl. Falk hat die technische Sachlage genau und richtig beschrieben.
Hallo, kurz gesagt: wenn man den Stecker zieht, funktioniert die Datenübertragung nicht. Das ist nicht sonderlich überraschend, eher schon die Tatsache, das man darüber so ausgiebig diskutieren kann. Dass man bei Übetragungen eine Fehlererkennung und Bereinigung braucht, insbesondere wenn Stecker im Spiel sind, ist auch nicht so neu. Es ist dabei auch ziemlich egal, ob synchron oder asynchron, bloss bei synchron ist die Fehlerprüfung für die bekannten Protokolle schon in der Hardware realisiert, bei asynchron muss man sie selber entwerfen und programmieren. Gruss Reinhard
Na, dann die Datenrate herauf setzen und Zeit zwischen den Paketen lassen ... Aber die herangehensweise "Ich ziehe den Stecker heraus und wundere mich über Verluste" ohne weitere Massnahmen ergriffen zu haben ist naiv! Gruß Jobst
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.