Wie lange braucht die Ausgabe auf UART?

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.

Danke, das Start- und Stoppbit hatte ich vergessen.

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

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

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.