mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zeitlich konstanter RS232-Datenstrom möglich?


Autor: Enrico. J. (ejoerns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :)

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei RS232 wird jedes Startbit zur Resynchronisierung des Empfängers 
benutzt. Darüber mußt du dir im Klaren sein.

Autor: Enrico. J. (ejoerns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindestens vom PC aus ist kein definiertes Timing hinzubekommen. Da 
werden immer mal wieder ein paar Zeichen abgeschickt, wenn der Therad 
gerade dran ist.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Enrico. J. (ejoerns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Enrico. J. (ejoerns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-...

oder nach SDLC/HDLC suchen. Hauptproblem: du hast die Hardware dafür 
nicht.

Gruss Reinhard

Autor: Enrico. J. (ejoerns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!? ;)

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry! Zu spät.
Das kommt davon, wenn es mal an der Tür klingelt.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Enrico. J. (ejoerns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, übrigens ist beim PSoC der Empfänger mit einer Macke versehen, 
wodurch er bei berauschten RS232-Signal nicht korrekt am Startbit 
synchronisiert.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

 _   _   _   _   _   _   _   _   _   _   _   _        
/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_
 S 0 1 2 3 4 5 6 7 S S 0 1 2 3 4 5 6 7 S S
 t                 t t                 t t
 a                 o a                 o a 
 r                 p r                 p r
 t                   t                   t

(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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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]

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.