Forum: Mikrocontroller und Digitale Elektronik RS232 Zeichensalat bei hoher Datenrate


von Frank (Gast)


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.
1
  USART_Transmit:
2
  ; Wait for empty transmit buffer
3
  sbis UCSRA,UDRE
4
  rjmp USART_Transmit
5
  ; Put data (r16) into buffer, sends the data
6
  out UDR,r16
7
  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. :)

von hinz (Gast)


Lesenswert?


von Peter II (Gast)


Lesenswert?


von Tassilo H. (tassilo_h)


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).

von Jim M. (turboj)


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.

von Peter II (Gast)


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

von Michael U. (amiga)


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

von Frank (Gast)


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.

von Peter II (Gast)


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.

von hinz (Gast)


Lesenswert?

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

Nichts! Das ist was zum lesen.

von Peter II (Gast)


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!)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


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.

von Peter II (Gast)


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.

von hinz (Gast)


Lesenswert?

Peter II schrieb:
> (Vermutlich hat er keinen mechanischen Fernschreiber!)

Ah, ein notorischer Meckerer.

von Michael U. (amiga)


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

von c-hater (Gast)


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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


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.

von Wolfgang (Gast)


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.

von Christian M. (Gast)


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

von spess53 (Gast)


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

von Christian M. (Gast)


Lesenswert?

Ich habe keine AVRs, ich mache ernsthafte Projekte... :-))

Chregu

von spess53 (Gast)


Lesenswert?

Hi

>Ich habe keine AVRs, ...

Na ja, Nobody is perfect.

MfG Spess

Bitte 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
Noch kein Account? Hier anmelden.