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. :)
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).
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.
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
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
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.
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.
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!)
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.
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.
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.
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.
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.
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 sicherimmer 8N1 empfangen wird...
Gruss Chregu
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
