Wie kritisch sind UART-Frequenzen?

Ich werde einen 8-MHz-Quarz verwenden, um meinen Mikrocontroller mit 16 MIPS (PLL 4x, 2-Zyklus-Anweisungen) zu betreiben. 8 MHz teilen sich jedoch nicht in irgendwelche UART-Frequenzen AFAIK ... also wie kritisch sind diese Frequenzen? Ich plane, 115.200 Baud zu verwenden.

Kann UART innerhalb von ±1 % ausgeführt werden? Wenn dies nicht funktioniert, welche Frequenz sollte ich verwenden? (Ich möchte für maximale Verarbeitungsgeschwindigkeit so nah wie möglich an 16 MIPS herankommen.) Wenn es darauf ankommt, verwende ich einen PIC24FJ64GA004.

Antworten (4)

Wenn Sie innerhalb von 1 % liegen, sollten Sie in Ordnung sein.

Angenommen, Ihr UART verwendet beispielsweise einen 16-fachen Oversampling-Takt, Sie können ihn auf 1.843.200 Hz auf 16-faches Oversampling von 115.200 bps einstellen. (Oversampling wie dieses ist ziemlich üblich) Dadurch kann der UART 8 Übertaktungen von der fallenden Flanke des Startbits abzählen, sodass er die Mitte der Bitzellen innerhalb von +/- einer Periode der Übertaktung danach lokalisieren kann die es 16 Perioden der Übertaktung abzählt, um zu bestimmen, wann Daten abgetastet werden sollen.

Wenn Sie davon ausgehen, dass es die Mitte des Startbits treffen kann, muss die Taktfrequenz zwischen (8-0,5) / 8 und (8 + 0,5) bleiben, um serielle Daten in den richtigen Bitzellen über 8 Datenbits abzutasten )/8 oder +/-6,25 % der beabsichtigten Bitrate. Eine höhere Übertaktung nähert sich der idealen Bedingung, die Mitte des Startbits zu treffen, aber 8x oder 16x ist normalerweise nah genug, dass Sie davon ausgehen können, dass eine Abweichung von 5 % funktioniert.

Sie können sich jedoch nicht darauf verlassen, dass die andere Seite perfekt auf Frequenz eingestellt ist. Wenn Sie ein 4 % schnelles Gerät mit einem 4 % langsamen Gerät verbinden, treten Probleme auf. Ich bin auf mindestens einen Fall gestoßen, in dem ein PC etwas langsam und ein Gerät etwas schnell lief und die beiden nur geringfügig kommunizieren konnten, obwohl dasselbe Gerät mit anderen PCs in Ordnung war und der PC mit anderen in Ordnung war Geräte. (O-scoped diese bei etwa 112kbps und 119kbps) Aus diesem Grund ist es gut zu versuchen, die Nennfrequenz so genau wie möglich zu erreichen. Ich habe noch nie gesehen, dass etwas innerhalb von 2% des Nennwerts ein Problem hat.

Üblicherweise wird eine Haupttaktrate verwendet, die ein ganzzahliges Vielfaches der beabsichtigten UART-Oversampling-Rate multipliziert mit der Baudrate bietet. Wenn Sie beispielsweise eine CPU mit etwa 8 MHz haben möchten, können Sie einen 7,3728-MHz-Oszillator verwenden, der durch 4 geteilt werden kann, um 1,8432 MHz zu erhalten, was genau 16 mal 115200 ist.

8 MHz könnten durch 69 geteilt werden, um 115.942 zu erhalten, was deutlich innerhalb von ±1 % liegt. Ich frage mich, ob der PIC diese Art der Teilung für seinen Baudratengenerator unterstützt. Ich hoffe es, aber ich glaube nicht, dass es das wird.
Der PIC hat einen Baudratengenerator. Es würde gut funktionieren, aber nur für niedrigere Baud wie 9600, es würde nicht für hohe Baud wie 115.200 funktionieren, es wird zu ungenau.
Glaubst du, ich könnte einen 7,3728-MHz-Quarz verwenden? (Ich werde den internen 7,37-MHz-Oszillator nicht verwenden, weil ich Präzision möchte.) Er erlaubt mir, durch 64 zu teilen, um eine UART-Frequenz von 115.200 zu erhalten. Es ist das schnellste, was ich mit einer hohen Toleranz erreichen kann.
Wenn Ihr UART dies unterstützt, ist es vorzuziehen, ihn zu übertakten (z. B. 16x), damit das Startbit überabgetastet und die Mitte der Bitzelle gefunden werden kann. Es kann jedoch eine Herausforderung sein, ein 16x für 115K auf 1% zu erreichen, es sei denn Sie verwenden einen Baud-Multiple-Kristall.

Die 1 % @JustJeff-Erwähnung ist nicht erforderlich. Die meisten UARTs erlauben einen halben Bitfehler beim letzten Bit. Meistens besteht ein Frame aus 1 Startbit, 8 Datenbits und 1 Stoppbit, also insgesamt 10 Bits. Ein halbes Bit auf 10 Bits sind 5 % (JustJeffs 6,25 % berücksichtigen nicht das Start- und Stoppbit).

zitiere mich nicht falsch; Bezüglich "1%" war meine Aussage, dass dies schwierig zu erreichen sein könnte. Die "6,25 %" gingen davon aus, dass Sie zufällig die Mitte des Startbits getroffen haben, und wären unter solchen Bedingungen die maximal zulässige Differenz zwischen Empfänger- und Sender-Taktraten.

Ein noch nicht erwähnter Punkt ist, dass einige Geräte erwarten, dass sie für jedes empfangene Datenbyte ein Datenbyte übertragen. Wenn ein solches Gerät kontinuierlich mit Daten versorgt wird, seine Baudrate sogar 0,1% langsamer ist als die des sendenden Geräts und es keine Möglichkeit hat, leicht geschrumpfte Stoppbits zu senden, wird sein Ausgang für alle 1000 aufeinanderfolgenden Bytes zurückfallen Byte, die hereinkommen. Wenn das Gerät auf 16 Byte Pufferung beschränkt ist, wird es ein Datenbyte löschen, nachdem es ungefähr 16.000 passiert hat, und danach ungefähr ein Byte pro Tausend. Es ist erwähnenswert, dass sogenannte "1200-Baud" -Modems aus genau diesem Grund tatsächlich mit einer Rate von etwas mehr als 1200 Bit / Sekunde (ich denke, es sind ungefähr 1202) arbeiten (selbst wenn der Sender 0,15% schneller ist als er sollte sein, das Modem leitet trotzdem alle Daten durch).

JustJeff hat das Startbit vergessen, aber Stevenh hat das Stoppbit hinzugefügt. Unter der Annahme des gemeinsamen Protokolls von 8 Datenbits, 1 Startbit und keinem Paritätsbit (Anzahl der Stoppbits spielt keine Rolle), gibt es 8 1/2 Bitzeiten von der führenden Flanke des Startbits bis zur Mitte des letztes Datenbit. Im Allgemeinen möchten Sie, dass der Empfänger dieses letzte Bit innerhalb von 1/4 Bitzeit abtastet. Beachten Sie, dass 1/2 Bit der garantierte Fehlerschwellenwert ist. Alles in der Nähe wird unzuverlässig, da es immer elektrisches Rauschen und Jitter gibt.

1/4 dividiert durch 8 1/2 = 2,94 %.

Wie JustJeff erwähnte, tasten die meisten UART-Implementierungen die eingehenden Daten tatsächlich mit einem asynchronen 16x-Takt ab. Das fügt eine weitere 1/16-Bitzeitunsicherheit hinzu, da dies der Fehler ist, mit dem die Vorderflanke des Startbits gemessen werden kann. 1/16 Bitzeit von 8 1/2 Bits sind weitere 0,74 %. Das ergibt sich aus dem zuvor berechneten Fehlerbudget. Am Ende haben Sie eine zulässige Taktabweichung von 2,2%, damit der Empfänger das letzte Bit innerhalb von 1/4 Bitzeit von seiner Mitte abtasten kann.

Wie andere gesagt haben, ist die Verwendung eines 7,3728-MHz-Quarzes eine gängige Praxis, wenn eine genaue Baudrate erforderlich ist. Normalerweise können Sie dafür sorgen, dass die CPU nahe ihrer maximalen Rate läuft, während Sie die UART-Baudrate innerhalb des Kristallfehlers erreichen.

Ich bin nicht damit einverstanden, dass Stoppbits keine Rolle spielen. Bei dieser Frage ist die Kommunikation fehlgeschlagen, weil das Stoppbit fälschlicherweise auf Low-Pegel gesetzt wurde.
Das Stoppbit muss vorhanden sein, damit die gesamte Kommunikation funktioniert, aber es geht bei den meisten UARTs nicht in die Berechnung des Fehlerbudgets ein. UARTs benötigen nach dem letzten Datenbit vor der nächsten Vorderflanke des nächsten Startbits eine gewisse Mindestzeit. Dafür ist die Stoppbitzeit da. Wenn diese Zeit nicht eingehalten wird, erhalten Sie einen "Framing Error". Vielleicht ist das wie ein Datenbit gesampelt, aber ich kenne Fälle, in denen es anders gehandhabt wurde. Die alten Fernschreiber benötigten 2 Stoppbits, um dem mechanischen Mechanismus Zeit zu geben, bereit zu sein, das nächste Zeichen zu greifen.
Ich habe dreimal auf das Startbit verwiesen, nicht wahr?
@OlinLathrop: Das Stoppbit wird benötigt, um sicherzustellen, dass beim Senden eines Bytes, dessen MSB Null ist , eine fallende Flanke für das nächste Startbit erfolgt. Verschiedene Geräte verhalten sich unterschiedlich in Fällen, in denen die Datenleitung auf Low geht, bevor sie es sollte, aber wenn es kein Stoppbit gäbe, würde eine übertragene Folge von Null-Bytes keine nützlichen Zeitinformationen enthalten. Eine solche Anforderung könnte auf andere Weise mit einem festen Framing-Overhead von weniger als 25% erfüllt werden, aber mir ist niemand bekannt, der dies tut.
Wie kritisch sind UART-Frequenzen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v