Prinzipiell würde ich mich auch der Meinung von PIColo anschließen.
Einen freien Debug-UART freizuhaben ist nie verkehrt, zumindest greife
ich gerne darauf zurück.
Falls du nicht die höhere Datenrate brauchst, oder am Bus kritische
Sensoren hängen hast, würde ich auf I2C zurückgreifen.
Außerdem hast du dadurch noch einen weiteren Vorteil: Du kannst alle
Teilnehmer auf deiner Platine mit einem Protokoll ansprechen.
Das ganze kannst du noch in eine Lib verpacken und kannst so mit wenigen
Funktionen den kompletten Bus bedienen.
Für RS232 müsstest du wieder eigene Funktionen einbauen, Interrupts
abfangen etc.
Falls die Controller größere Datenmengen übertragen müssen, kannst du
diese auch in einem Puffer zu einem großen Datenframe sammeln.
Der Master fragt dann beim zweiten PIC regelmäßig den Status ab und
übermittelt seinen eigenen.
Steht ein Frame an, blockierst du kurz den Bus und tauschst einmal die
Puffer gegenseitig aus.
Dadurch hast du auch gleich eine Gegenseitige Blockierung: Der Master
muss warten, bis ein Datenframe (z.B. eine Berechnung) ansteht, während
der Slave aber wiederum darauf warten muss, dass der Master den Frame
abfragt.
Über RS232 kommt der Datenframe einfach rein und der Interrupt
unterbricht z.B. deine laufende Sensorabfrage.
Du müsstest hier also auch ein Protokoll aufsetzen, was sich gegenseitig
blockieren kann.
Dann kannst du auch gleich I2C nehmen, was diese Funktionen gleich
mitbringt.
Wenn du nicht ständig aktualisierte Daten über ein Interrupt reinkriegen
willst, entstehen dadurch auch keine Nachteile.
Vor einer Berechnung, Ausgabe etc. holst du die Daten vom Bus,
berechnest und in der Zwischenzeit schnüren die Busteilnehmer schon die
nächsten Datenframes.
