Also bei älteren seriellen Verbindungen dieser Bauart benutzt man üblicherweise Hardwarehandshake oder wenn man das wie Du nicht hat, Softwarehandshake. Das Letztere nennt sich xon/xoff und ist googlebar... leider aber auch etwas aufwändiger und nur wirklich sinnvoll wenn man ein schlauen UART Baustein hat/nutzt, der das Protokol dafür selbst unterstützt.
Ich würde aber wohl auch eher versuchen, den PI per I2C an den RP6 an zu flanschen und erst mal mit langsamen Baudraten zu arbeiten, die zuverlässig syncronisiert werden können. Siehe dazu auch die Baudratenberechnung vom RP6 in Bezug auf die 8MHz Taktung.
Ein weiteres Problem steckt in den RP6 Libs bzw. in der Art wie die Software auf dem RP6 läuft.
Die originale RP6 Lib macht einige Funktionen über polling und hardwaits statt per reinem Interrupt und das kann bedeuten, das die CPU irgendwo in einer Wateschleife hängt wärend der UART voll läuft. Mit anderen Worten, die RP6 Lib ist nicht wirklich echtzeitfähig.
Für den normalen Gebrauch und ab und zu mal ein Zeichen fällt das kaum auf... aber wenn man einen IO Port wirklich mit Daten bombardiert, merkt man doch, das die Dinge nicht wirklich rund laufen.
Ich bastel für mich schon seid langem an einer Lösung mit freeRTOS für diese fehlende Echtzeitfähigkeit aber das ist bisher nichts was man vorführen oder veröffentlichen könnte.
Als Tip, der UART der Atmel CPU hat Fehlerflags, die man abfragen kann... bau dir in deine Lese und Schreibfunktionen mal eine Abfrage der Flags rein, dann kannst du auch sehen, das dort overruns passieren. Allerdings geb die Meldung dann nicht auf dem UART aus...
Gruß