Hallo Leute!
Ich versuche mich gerade an einer Kommunikation zwischen einem
ATmega328P und einem PC über einen FTDI FT232R Chip. Das Ganze läuft
zunächst mit 9600 Baud im 8-N-1-Modus. Ich schicke nun zu Testzwecken
fortlaufend 0x55-Bytes an den PC und halte mich dabei an das
Codebeispiel aus dem Datenblatt:
1
while(1){
2
while(!(UCSR0A&(1<<UDRE0)))continue;
3
UDR0=0x55;
4
}
0x55 sende ich, damit ich am Oszilloskop die Baudrate bequem messen
kann. Die Messung ergibt eine Bitdauer von 102 µs und ein Frame besteht
aus einem Startbit, den Datenbits und einem Stopbit. Meine Konfiguration
für den AVR ist also richtig.
Am PC sehe ich auch, dass die richtigen Bytes ankommen (ich benutze
dafür HTerm). Mache ich jedoch im Terminal einen Disconnect und verbinde
mich daraufhin wieder mit dem COM Port, bekomme ich erstmal sechs
0x00-Bytes zu sehen, bevors dann wieder mit der eigentlichen
0x55-Übertragung weitergeht. Woher kommt dieses Verhalten? Hat das was
mit den Buffern des FT232 zu tun?
Eine weitere Frage: Sollte ich für die Kommunikation zwischen AVR und
FT232 Hardwarehandshaking verwenden? Im Moment läuft alles ohne
Flusskontrolle, aber bei einer niedrigen Baudrate, ab.
Ich bin leider absoluter Neuling in der Verwendung eines FT232 ;)
Vielen Dank schon mal im Voraus!
Hallo Andi,
Du schreibst nicht mit wieviel Takt und welchem Takt der Atmega versorgt
wird.
Du weißt, daß der interne Taktgeber des Atmega zu ungenau ist, um damit
höhere Baudraten zu erreichen?
Daß Du auch nicht mit jeder Frequenz jede Baudrate erreichen kannst,
sondern daß man u.U ziemlich ungerade Taktfrequenzen (3,128 MHz etc)
nehmen muß?
Hört sich ein bißchen so an....
Auch wenn ich selber kaum mit dem FTDI arbeite, beim MCP2200 ist das
einsfixdrei passiert, wenn Takt und Fehlerrate stimmen.
Da arbeite ich mit 19200 Baud und ohne Hardware-Handshake.
Im https://www.mikrocontroller.net/articles/AVR-Tutorial:_UART steht
viel dazu, im Datenbuch des ATmega noch, wie hoch die Fehlerquote bei
wieviel MHz ist.
Wenn Du $55 = %0101 0101 1(Stopbit) sendest, das Terminal irgendwo dann
in diesem Zahlenwust wieder startest - nehmen wir an es empfängt dann
%011010101 - woher soll das Terminal wissen, was das Byte ist, wo es
anfängt oder wo das Stopbit ist?
Das ist schon prima, wenn HTerm nach 5 Bytes wieder synchron
ist.Intelligentes Programm :-)
Viele Grüße
olav.
Hallo olav,
vielen Dank für deine Antwort. Der Takt scheidet als Fehlerquelle aus,
ich verwende einen externen 16 MHz Quarzoszillator und habe mich an die
Angaben aus dem Datenblatt gehalten, um auf eine Baudrate von 9600 Baud
zu kommen. Nachgemessen habe ich die Frequenzen auch.
Olav K. schrieb:> Wenn Du $55 = %0101 0101 1(Stopbit) sendest, das Terminal irgendwo dann> in diesem Zahlenwust wieder startest - nehmen wir an es empfängt dann> %011010101 - woher soll das Terminal wissen, was das Byte ist, wo es> anfängt oder wo das Stopbit ist?>> Das ist schon prima, wenn HTerm nach 5 Bytes wieder synchron> ist.Intelligentes Programm :-)
D.h. das Verhalten müsste so eigentlich normal sein? Wird das durch
Hardware-Handshaking besser, also bspw. mit DTS/CTS?
Olav K. schrieb:> Du weißt, daß der interne Taktgeber des Atmega zu ungenau ist, um damit> höhere Baudraten zu erreichen?
Was hat die Ungenauigkeit des Taktgebers mit der Höhe der Baudrate zu
tun? Kannst du bitte mal erklären, warum eine niedrige Baudrate weniger
von einem Taktratenfehler betroffen sein soll, als eine höhere?
Hallo, guten Morgen Andi,
bitte entschuldige den Fauxpas mit Taktgeber und Baudrate, natürlich
kann der Übertragungsfehler bei niedrigen Frequenzen höher sein als bei
hoher Taktfrequenz.
...... aber das hilft Dir bei Deinem Problem jetzt nicht so weiter.
Dein Problem lautet:
16 MHz, 9600 Baud => 0,2 % Fehlerquote funktioniert.
16 MHz, X Baud funktioniert nicht - Fehlerquote ?
16 MHz ext. Takt 19200 Baud sollten bei Dir also funktionieren.
Die nächste Frage wäre für mich, ob Dein FTDI weiß, daß Du ihn nicht
mehr mit 9600 sondern mit X Baud ansprichst?
Bei CTS/RTS-Kiste (ich habe einen FTDI, der das benutzt, aber da geht es
um zuverlässig schnelle Verarbeitung größerer Datenmengen) kann ich mir
nicht vorstellen, daß man, um $55 als Probestring zu versenden, ein
Handshake braucht.
schönen Tag
Olav.
Andi K. schrieb:> D.h. das Verhalten müsste so eigentlich normal sein? Wird das durch> Hardware-Handshaking besser, also bspw. mit DTS/CTS?
Ja, aber es geht auch einfacher: mach mal Pause. Du sendest Zeichen an
Zeichen, wenn du aber reale Daten sendest und z.B. nach jedem Datensatz
eine kurze Pause einlegst, ist das die Gelegenheit für den FTDI (und
jedes andere UART), sich wieder korrekt zu synchronisieren. Am Anfang
der Übertragung können bzw. werden natürlich ein paar falsche Zeichen
empfangen, wenn du gerade mitten im Datensatz einschaltest, dafür muss
eine Fehlerbehandlung da sein, die ist aber bei Datenübertragung sowieso
unverzichtbar.
Handshake brauchst du, wenn sich der Empfänger an zu vielen Daten
verschluckt. Als Nebenwirkung sorgt das Handshake auch für einen
geregelten Start der Übertragung.
Georg
Thread beobachten
Seitenaufteilung abschalten