mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232 Zeichensalat bei hoher Datenrate


Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hardware: ATMEGA8, MAX232, PL2303 USB/RS232 Adapter
Senden + Empfangen funktioniert
Terminal: Windows PC (Win 7) + Termite

Da die RS232-Kommunikation sauber läuft, sah ich davon ab, den ganzen 
Code zu posten. Kann das jedoch gerne nachholen.

Mir stellt sich ein unterhaltsames Problem. Ich verwende folgenden Code 
aus dem Datenblatt des ATMEGA8 und stoße auf ein seltsames Verhalten.
  USART_Transmit:
  ; Wait for empty transmit buffer
  sbis UCSRA,UDRE
  rjmp USART_Transmit
  ; Put data (r16) into buffer, sends the data
  out UDR,r16
  ret

- Wenn ich (über einen Timer) die Routine anspringe, so, dass das 
vorherige Byte auf jeden Fall schon übertragen wurde, dann sehe ich im 
Terminal die Daten so, wie sie sein wollen.

- Wenn ich die Routine sofort, nach dem das Byte in das UDR Register 
geschoben wurde und die Routine verlassen wird, wieder anspringe, so 
erhalte ich auf dem Terminal nur Zeichensalat. Ich frage mich nun warum.

Eigentlich ist es ja egal, wie schnell ich die Routine wieder anspringe, 
da ich dann solange in einer "loop" kreise, bis der Test sagt "Register 
leer, springe und schreibe Daten nach UDR".

Mir scheint, als wäre das nicht der Fall. Ich habe mich über den Timer 
mal langsam dem kritischen Moment genähert (Timer Stück für Stück 
schneller laufen gelassen). Ab dem Punkt, an dem das Zeitfenster zu 
klein ist und das Byte nicht mehr komplett gesendet wurde, kommt es zum 
Zeichensalat.

Benötige ich nun eine Zusätzliche Ruhepause? Ich laß, dass man nach 
jedem Byte etwas Zeit lassen soll, damit der Empfänger den Anfang des 
neuen Bytes sauber findet. Aber eigentlich würde ich gerne Gas geben und 
Daten nonstop über die Schnittstelle schicken.

Danke. :)

Autor: hinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Peter II (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Tassilo H. (tassilo_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutlich daß die Anzahl der Stoppbits oder die Erwartung eines 
Paritybits auf Sender- und Empfängerseite nicht übereinstimmt (Falls 
Sender 1 Stoppbit sendet und Empfänger 2 erwartet gibt es ohne 
Sendepause Datenmüll, sonst ggf. nur ein gesetztes Fehlerflag/Framing 
error).

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> - Wenn ich die Routine sofort, nach dem das Byte in das UDR Register
> geschoben wurde und die Routine verlassen wird, wieder anspringe, so
> erhalte ich auf dem Terminal nur Zeichensalat. Ich frage mich nun warum.

Wenn da nur ein Stop Bit drin ist, kann der PC auch auf ein falsches 
Start Bit trigger, und dieses nicht über die Zeit korrgieren. Dann in 
den Daten sind auch Low und High Bits die als Start bzw. Stopp Bit 
wirken.

Bei der Timer Version ist der Zwischenraum zwischen 2 Bytes groß genug 
dass er sich auf das korrekte Start Bit synchronisieren kann.

Abhilfe: Ab und zu 0x00 oder 0xFF senden. In beiden Fällen wird das 
nachfolgende Start Bit korrekt erkannt.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Wenn da nur ein Stop Bit drin ist, kann der PC auch auf ein falsches
> Start Bit trigger, und dieses nicht über die Zeit korrgieren. Dann in
> den Daten sind auch Low und High Bits die als Start bzw. Stopp Bit
> wirken.

1 Stop Bit ist bei aktueller Technik ausreichend, da muss nicht noch 
extra gewartet werden.

> Die Variante 1,5 Stoppbits ist historisch bedingt, sie kommt aus der
> Zeit der mechanischen Fernschreiber

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

von welcher Baudrate und welchem CPU-Takt ist eigentlich die Rede?
Ich kenne solch ein bisher Problem nicht.

2 Stoppbits werden üblicherweise im Empfänger nicht ausgewertet, man 
kann ohne Probleme 8N2 senden und mit 8N1 empfangen, man schafft dem 
Empfänger dann einen eine Bitzeit zusätzliche Reaktionszeit.
Ist bei heute üblichen UARTS im PC aber noch nie nötig gewesen.

Gruß aus Berlin
Michael

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

4,915200 Mhz
9600 Baud
UBRRx Vorteiler: 32

In der Tat bin ich am Überlegen den Sender ganz frech auf 8N2 zu setzen.
Ob es das tut, muss ich noch herausfinden.

LG,
Frank.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> In der Tat bin ich am Überlegen den Sender ganz frech auf 8N2 zu setzen.
> Ob es das tut, muss ich noch herausfinden.

lieber nicht, das Problem muss ja irgendwo sein.

teste den code doch einfach mal im Simulator, dann sieht du ob er loopt, 
wenn das bit nicht gesetzt ist.

Autor: hinz (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Peter II schrieb:
> hinz schrieb:
>> https://de.wikipedia.org/wiki/Stoppbit
>
> und was soll uns das sagen?

Nichts! Das ist was zum lesen.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hinz schrieb:
> Peter II schrieb:
>> hinz schrieb:
>>> https://de.wikipedia.org/wiki/Stoppbit
>>
>> und was soll uns das sagen?
>
> Nichts! Das ist was zum lesen.

und was kann man dort lesen, und ihm bei seinem Problem helfen? 
(Vermutlich hat er keinen mechanischen Fernschreiber!)

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> 1 Stop Bit ist bei aktueller Technik ausreichend, da muss nicht noch
> extra gewartet werden.
Die Zeit reicht bei heutiger Hardware locker zur Auswertung.  Aber bei 
einem kontinuierlichen Datenstrom kann es sein, dass der Empfänger z.B. 
durch eine Störung ausser Tritt kommt und ab dann Probleme hat, das 
Startbit zu erkennen. Dann startet er bei irgendeinem Bit und erzeugt 
u.U. Sogar Framefehler, die der PC aber nicht auswertet.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Die Zeit reicht bei heutiger Hardware locker zur Auswertung.  Aber bei
> einem kontinuierlichen Datenstrom kann es sein, dass der Empfänger z.B.
> durch eine Störung ausser Tritt kommt und ab dann Probleme hat, das
> Startbit zu erkennen. Dann startet er bei irgendeinem Bit und erzeugt
> u.U. Sogar Framefehler, die der PC aber nicht auswertet.

dann müsste das aber bei jeden Datenrate auftreten und nicht nur bei 
hohen.

Autor: hinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> (Vermutlich hat er keinen mechanischen Fernschreiber!)

Ah, ein notorischer Meckerer.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Frank schrieb:
> 4,915200 Mhz
> 9600 Baud
> UBRRx Vorteiler: 32

UBRR = (fosc/(16*BAUD))-1

Hast Du die -1 vergessen?
16*9600 = 153600
4915200/153600 = 32
32-1 = 31 UBRRx

Gruß aus Berlin
Michael

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:

> - Wenn ich (über einen Timer) die Routine anspringe, so, dass das
> vorherige Byte auf jeden Fall schon übertragen wurde, dann sehe ich im
> Terminal die Daten so, wie sie sein wollen.
>
> - Wenn ich die Routine sofort, nach dem das Byte in das UDR Register
> geschoben wurde und die Routine verlassen wird, wieder anspringe, so
> erhalte ich auf dem Terminal nur Zeichensalat. Ich frage mich nun warum.

Klassischer Fall von grenzwertiger "Übereinstimmung" der Baudrate von 
Sender und Empfänger. Die Abweichung ist noch nicht so gross, dass 
garnix mehr geht, aber gross genug, dass bei "Datenwort an Datenwort" 
die Startbits die Stopbits des jeweils vorigen Datenworts für den 
Empfänger schon ungültig machen->Framing error.

Kauf' dir einfach 'n Baudraten-Quarz! Die kann sich heutzutage wirklich 
jeder leisten. Wenn du die 19 Cent oder so nicht über hast, die sowas 
als Einzelstück bei den einschlägigen Apotheken kostet, kannst du ja 
einen Spendenaufruf veröffentlichen...

Oder du lernst, wie man den RC-Oszillator des Senders kalibiriert und 
bei laufender Kommunikation ständig nachkalibriert. Das ist allerdings 
nur dann eine akzeptable Lösung, wenn die Kommunikation bidirektional 
ist oder eine andere Referenzquelle hinreichender Genauigkeit ständig 
für die Kalibrierung verfügbar ist.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Kauf' dir einfach 'n Baudraten-Quarz!

4,9152 Mhz ist ein Baudratenquarz. Bei 9600 Baud und UBRR = 31 ist die 
Abweichung 0% - trifft also genauestens.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Benötige ich nun eine Zusätzliche Ruhepause?

Vielleicht brauchst du einfach ein geeignetes Werkzeug, um die erzeugten 
Signal zu prüfen.

Für den Datenstrom wäre ein kleiner Logikanalysator, inzwischen für 
unter 8€, eine Möglichkeit. Sicherheitshalber könntest du auch ein 
Oszilloskop nehmen, um zu gucken, ob die Flanken auf der Leitung sauber 
sind.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. schrieb:
> man
> kann ohne Probleme 8N2 senden und mit 8N1 empfangen

Mach ich immer so, aber Bestätigt hat mir noch niemand, dass sicher 
immer 8N1 empfangen wird...

Gruss Chregu

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Mach ich immer so, aber Bestätigt hat mir noch niemand, dass sicher
>immer 8N1 empfangen wird...

Bei AVRs steht das im Datenblatt:

Bit 3 – USBS: Stop Bit Select
This bit selects the number of stop bits to be inserted by the 
Transmitter. The Receiver ignores this setting.

MfG Spess

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe keine AVRs, ich mache ernsthafte Projekte... :-))

Chregu

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich habe keine AVRs, ...

Na ja, Nobody is perfect.

MfG Spess

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.