... den Pin also dauernd abfragen um das Startbit zu erkennen ... Mitte des Startbits finden ... darf nie durch eine andere Interruptroutine verzögert ...
Klar, fast unnötig Dir beizupflichten. Aber es geht natürlich auch anders.

Mein UART läuft (eigentlich bei allen Lösungen) auf Interrupt und schreibt in einen FIFO-Ringspeicher. Dann schaue ich im Vorbeigehen nach
Code:
if ( ! ukbhit0 () ) continue;
und WENN etwas im FIFO steht wird es abgeholt
Code:
zeichen_aus_fifo = ugetchar0();
und auf einen signifikanten Telegramm-Anfang abgefragt, der aus einem, einzigen ASCII-Zeichen besteht, das aber so in den Telegrammen natürlich nicht vorkommen darf (Buchstabe/n, oft natürlich #, * oder so)
Code:
      if (zeichen_aus_fifo == KOMMANDO_APPS)   // Fahre Anwendungsprogramme
        telegrammlaenge = KOMMANDO_APPS_LEN;   //   mit und ohne Parameter

       if (zeichen_aus_fifo == KOMMANDO_DATS)   // Servo Daten von allen
         telegrammlaenge = KOMMANDO_DATS_LEN;   //   Servos anzeigen

       if (zeichen_aus_fifo == KOMMANDO_NORM)   // Servo Normposition
         telegrammlaenge = KOMMANDO_NORM_LEN;   //   anfahren
Dieses "Schlüsselzeichen" wiederum ergibt die Telegrammlänge. Die kann, z.B. im Beispiel "KOMMANDO_NORM" 1 sein und das ist das Kommandobyte alleine. Das Telegramm wird, wieder im Vorbeigehen, ausgelesen (in voller, aber eben nur für DIESES Telegramm festgelegten Länge) und ausgewertet. Dazwischen laufen mehrere andere Interrupts, die so wenig stören, dass ich im Standardfall Controller<->PC mit lesen und schreiben über UART-USB-Wandler locker 115k2 Bd schaffe, bei Controller-Controller-Kommunikation sogar die vollen Kanne mit 1,2 MBd (da beide Controller mit 20 MHz laufen, haben die den gleichen "Rechen-/Zeitfehler" beim UBRR. Zusätzlicher Vorteil natürlich zwei Kommunikationsrichtungen. Nachteil: Es ist KEIN Busverfahren.