Hallo, wie lang dauert denn die Ausgabe eines Zeichensatzes von 10 Zeichen über UART bei einer Baudrate von 9600? Wenn ich richtig im Kopf habe werden bei 9600 Baud 9600 Bit/s übertragen. Pro Zeichen brauche ich bei ASCII pro Zeichen 8 Bit. Kann ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 Zeichen über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist?
displayender schrieb: > Pro Zeichen brauche ich bei ASCII pro Zeichen 8 Bit. Kann > ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 Zeichen > über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist? nein. Zu den 8bit kommt noch 1 Start und meist 1 Stop bit. Also 10bit je Zeichen. also etwas über 10ms.
displayender schrieb: > Pro Zeichen brauche ich bei ASCII pro Zeichen 8 Bit Es sind allerdings 10 Bit, denn pro übertragenem Byte kommt ein Start- und ein Stopbit hinzu. Wenn deine Software es schafft, sofort das nächste Zeichen auszugeben, wenn der Sender leer ist (typisch während des Stopbits), dann ist die Zeit pro Zeichen also 1,04166 ms. 10 Zeichen benötigen also rund 10,4 ms.
displayender schrieb: > wie lang dauert denn die Ausgabe eines Zeichensatzes von 10 Zeichen über > UART bei einer Baudrate von 9600? > Wenn ich richtig im Kopf habe werden bei 9600 Baud 9600 Bit/s > übertragen. Pro Zeichen brauche ich bei ASCII pro Zeichen 8 Bit. Kann > ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 Zeichen > über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist? Nein, du hast Start- und Stop- und Paritybits vergessen. Beim wohl verbreitetsten Frameformat 8N1 hast du insgesamt 10 Bits pro Datenwort. Zehn Datenwörter dauern bei 9600bit/s also im Minimum 1/96stel Sekunde, sprich rund 10,4 ms.
Hi >Wenn deine Software es schafft, sofort das nächste Zeichen auszugeben, >wenn der Sender leer ist (typisch während des Stopbits), dann ist die >Zeit pro Zeichen also 1,04166 ms. Warum typisch während des Stopbits? Bascom lässt auf AVR schließen. Und deren TX-/RX-Register sind gepuffert. MfG Spess
spess53 schrieb: > Warum typisch während des Stopbits? Bascom lässt auf AVR schließen. Und > deren TX-/RX-Register sind gepuffert. Ich hab mal nach Timing Diagrammen gesucht, aber kein richtiges gefunden. Es gibt MC, die ein 'RX Complete' oder 'TX Empty' bereits mit der steigenden Flanke des Stopbit signalisieren. Ist ja auch gar nicht dumm, denn dann hat man die Dauer des Stopbit zur Verfügung, um ein Zeichen zu lesen oder den Sendepuffer zu füllen. Vllt. findet sich was in den Appnotes bei Atmel dazu, spielt hier aber nicht sooo eine Rolle.
Die "echten" UARTs der ATMega tasten jedes Bit dreimal ab und eine Mehrheitsentscheidung sagt dann, ob es eine 0 oder eine 1 war (AVR307). Folglich kann nicht die erste Flanke verwendet werden. Die Sparversionen (USI) tasten nur einmal in der Bit-Mitte ab. Also ist auch hier die Flanke nicht massgebend.
Matthias S. schrieb: > Ich hab mal nach Timing Diagrammen gesucht, Eigentlich halten es fast alle neueren µC so, daß nicht das Tx-Register selbst geschoben wird, sondern daß das Zeichen, was im Tx-Register steht, nach Beendigung des letzten Stopbits in das Sende-Schieberegister verfrachtet wird, woraufhin das Tx-regiter frei geworden ist und per Interrupt nach dem nächsten Zeichen schreit. Man hat daher (bei dieser Architektur) ein ganzes Zeichen Zeit, um was Neues zum Senden nachzuliefern. Von UART's mit FIFO sehen wir hier mal ab. W.S.
displayender schrieb: > Kann ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 > Zeichen über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist? Was Bascom da macht, wirst du am ehesten mit einem Oszi sehen. Was dein µC kann, entnimmst du am bestem dem Datenblatt. Zu der Sendefolge eines ATmega328 findet man z.B. die Beschreibung im Kapitel "20.6 Data Transmission – The USART Transmitter" Der Sendepuffer ist frei für das nächste Zeichen, sobald der Inhalt für die serielle Ausgabe ins Shift-Register übertragen wurde. Beim Senden kann man zwei verschiedene Interrupts nutzen (UDRE Datenregister frei und TXC Aussendung beendet, Kap. 20.6.3 Transmitter Flags and Interrupts: "The USART Transmitter has two flags that indicate its state: USART Data Register Empty (UDREn) and Transmit Complete (TXCn). Both flags can be used for generating interrupts.")
Georg G. schrieb: > Die "echten" UARTs der ATMega tasten jedes Bit dreimal ab und eine > Mehrheitsentscheidung sagt dann, ob es eine 0 oder eine 1 war (AVR307). > Folglich kann nicht die erste Flanke verwendet werden. Die Sparversionen > (USI) tasten nur einmal in der Bit-Mitte ab. Also ist auch hier die > Flanke nicht massgebend. Ich begreife jetzt nicht ganz, was das Abtasten (beim Empfang!) mit dem Timing beim Senden zu tun hat.
Hi >Ich begreife jetzt nicht ganz, was das Abtasten (beim Empfang!) mit dem >Timing beim Senden zu tun hat. Na nichts. Aber auch diese Aussage > Kann ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 > Zeichen über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist? ist falsch. Ein Printbefehl muss nicht darauf warten bis ein Byte den Sendepuffer verlassen hat. Die ersten zwei Bytes können direkt hintereinander nach UDR geschoben werden. Auf jedes weitere Byte muss dann eine Zeichenlänge gewartet werden. MfG Spess
spess53 schrieb: > Aber auch diese Aussage >> Kann ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 >> Zeichen über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist? > ist falsch. Wieso das jetzt plötzlich? 8 Zeichen mit 8,n,1 brauchen zusammen 80 Bit-Zeiten, also 8,3ms. Die letzen beiden von den 10 Zeichen sind dann im Sendepuffer bzw. Shift-Register und der Print-Befehl ist abgehakt.
spess53 schrieb: > Hi > >>Ich begreife jetzt nicht ganz, was das Abtasten (beim Empfang!) mit dem >>Timing beim Senden zu tun hat. > > Na nichts. Aber auch diese Aussage > >> Kann ich also davon ausgehen, dass der Print-Befehl in Bascom bei 10 >> Zeichen über UART nach ca. 1/120s respektive 8,3 ms rum ums Eck ist? > > ist falsch. Ein Printbefehl muss nicht darauf warten bis ein Byte den > Sendepuffer verlassen hat. Die ersten zwei Bytes können direkt > hintereinander nach UDR geschoben werden. Auf jedes weitere Byte muss > dann eine Zeichenlänge gewartet werden. Wieso, könnte ja auch ein FIFO in Software durch die Bascom-Runtime implementiert sein, wo lächerliche 10 Zeichen praktisch sofort reingehen? Nähere Auskunft gibt, wie immer, die Doku. Oder manchmal auch nicht... ;-)
Georg G. schrieb: > Die "echten" UARTs der ATMega tasten jedes Bit dreimal ab Niemals beim Senden und auch nicht beim Empfangen im 2x-Modus. > Folglich kann nicht die erste Flanke verwendet werden. Folglich ist das ein Fehlschluß. Allerdings stimmt das Ergebnis trotzdem, nur ist der tatsächliche Grund ein völlig anderer, nämlich die Double-Buffer-Struktur der USART. Der Interupt erfolgt immer in dem Moment, wenn von einem Bufferregister in das andere umkopiert wird. Und dies kann natürlich immer erst dann erfolgen, wenn das Schieberegister komplett geleert ist (beim Senden) bzw. komplett gefüllt ist (beim Empfangen). Komplett meint in diesem Zusammenhang: wenn genau die Zahl Bits gesendet bzw. empfangen ist, die durch die Einstellungen zum Frameformat festgelegt ist, den dies legt den Comparewert für den Zähler fest, der die Sache letztlich steuert. > Die Sparversionen > (USI) tasten nur einmal in der Bit-Mitte ab. Das stimmt. > Also ist auch hier die Flanke nicht massgebend. Das stimmt nun wieder nicht. Beim USI hat man es selbst in der Hand, nach wie vielen Bits der Interrupt ausgelöst wird. Es ist also möglich (unter Verlust der Möglichkeit zur zuverlässigen Prüfung auf Frameerrors), den Interrupt bereits auslösen zu lassen, wenn das letzte Bit des Payloads empfangen bzw. gesendet wurde. Tatsächlich wird das in vielen Implementierungen auch so gemacht, weil das USI-Schieberegister im Gegensatz zu dem der USART nur 8 Bit umfaßt, also bei 8 Bit Datenwortbreite weder Platz für Start- noch für Stop- oder Paritybits bietet. Genau genommen geht das Verfahren beim USART ebenfalls, nur darf man dann natürlich nicht mehr das FE-Bit der Hardware zur Fehlerprüfung benutzen. Und natürlich: In beiden Fällen ist man dann beim Senden selbst dafür verantwortlich, die Mindestdauer des Stopbits per Software sicherzustellen.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.