hm ok... der Einwand hat Hand und Fuß. Die Datenrichtung habe ich übersehen. Asche über mein Haupt. Aber beim senden von Daten vom RP6 auf den PC hatte ich auch schon solche Phänomene und ein PC mit BufferUART wie der 16550 steht bei 38,4 kbaud nicht im Verdacht Daten zu verlieren.

Das Argument mit Anfänger und blockierend... hm... Ok ich sehe ein das es für Anfänger zunächst "durchsichtiger" ist. Tatsächlich schränkt es aber auch massiv ein, vor allem wenn man viele Daten vom RP6 auf den PC sendet.

Code:
void writeChar(char ch)
{
    while (!(UCSRA & (1<<UDRE)));
    UDR = (uint8_t)ch;
}
Das Argument mit der Baudzahl ist übrigends interssant. Bedeutet es doch, daß je langsamer man die Baudzahl stellt, man sich um so mehr Probleme im Timing des Systems verschafft weil weniger Baud auch automatisch länger pollen von UDRE in UCSRA bedeutet. Wir reden bei 9600 baud gegen 38400 baud schon um den Faktor 4. Gibt man seitenweise Text wie im Beispiel aus, kommen da schon einige Sekündchen zusammen in denen die CPU nur UCSRA pollt und bestenfalls irqs bearbeitet.
Der bestechende Vorteil der Methode... man braucht sich kein Kopf über volle Buffer zu machen, die bei viel Text sogar mit irq-senden ein Warten auf Platz im Buffer erzwingen würde.
Spätestens da hatte ich damals beschlossen freeRTOS zu nutzen, da kann man die Warterei wenigstens anderen Tasks als Rechenzeit zuteilen.
Allerdings verkompliziert das widerum _etwas_ das Interrupthandling
Gruß