Rechenzeitbedarf beim Zahlenausgabe

[Peter(TOO)]

Naja, "erschreckend" ist vielleicht übertrieben, denn was den eigentlichen Sendevorgang angeht, ist "57000 baud" und "158 µs/byte" ja gleichbedeutend (bei 8 Datenbits/ 1 Stoppbit) - und in dem Sinne zu erwarten.

Die Rechnung stimmt so gar nicht.
Du hast ein Startbit, die Daten und das Stoppbit.
Bei 8-Bit Daten sind das dann mindestens 10 Bitzellen, ergibt dann etwa 175µs.
Dann könnte man noch das Parity-Bit zuschalten und das Stoppbit, kann1, 1.5 oder 2 Bit-Zellen lang sein.
Im Extremfall kommt man dann auf 1+8+1+2 = 12 Bitzellen.
Die längeren Stoppbits waren eigentlich dafür gedacht, dem Empfänger etwas mehr Zeit zum Abholen und Auswerten des gerade Empfangenen Bytes zu geben. Sonst haben sie technisch keine Bedeutung.
Die Verwendung von 5 Datenbits stammt noch vom Telex. So vor 35 Jahren wurden Telexe als TTY oft als Terminal für Computer verwendet.
7 Datenbits war die Norm für den alten ASCII-Code, welcher nur 7 Bits benutzte, dass es auch noch Umlaute und andere Sonderzeichen gibt, wussten die AMIs lange Zeit nicht

MfG Peter(TOO)

[malthy]

@Peter(TOO): Ja hast Recht, hab das Startbit nicht mitgerechnet. Die anderen Bits verwenden die meisten Leute meines Wissens nicht, aber full ack, das Datenpaket ist u. U. noch länger. Mir ging's ja auch nur darum zu Überlegen, wo die Zeit bleibt.

@Klebwax: ja, stimme Dir natürlich zu. Im Verhältnis zu Datenraten, die man auf einem mC erzeugen kann, ist der UART recht lahm. Wobei man mit UART2USB-Bridge natürlich schon relativ hohe Baudraten hinbekommt. Da ist dann eher das Problem, dass USB so ein billig-Bus ist und das Timing schlecht ist. Aber wie gesagt, wollte nur darauf raus, dass man nicht geduldig auf den Sendevorgang warten muss .

Gruß
Malte