Hallo,
grundsätzlich gibt es 2 Methoden um Zustände abzufragen. Polling ( CPU fragt dauernd ein Port ab und reagiert bei Ereignis) was immer blockierend wirkt .. oder Interrupt (CPU reagiert durch Interruptcontroller der das Ereignis feststellt). Man kann alle Interruptquellen auch pollen... was in der Originalfassung der RP6Lib beim serial send z.B. gemacht wird, man kann aber auch Interrupt Serviceroutinen ISR schreiben, die einfach nur den Statuswechsel erkennen .. wie z.B. die Counter-ISR für die Lichtschranken oder man kann komplexe Funktionen da rein bauen... letztlich hängt es von der verwendeten Software/Lib und der Philosophie und Knowhow des Programmieres dahinter ab, wie da mit umgegangen wird. Pollen funktioniert immer dann gut, wenn es nur eine relevante Ereignisquelle gibt - das ist beim RP6 als rollender, sich orientierende Bot aber meist nicht gegeben. Allerdings dient der RP6 oft auch nur als Experimentierplattfrom und da reicht das durchaus. Der Autor der Libs hat aber auch schon immer gesagt, das die Libs nur ein Grundgerüst darstellen, welches ausgebaut werden kann und soll.

Es gibt ja noch andere große AVR Projekte... C'T-Bot, Arduino, usw... wo man das ggf. anders regelt. Ein blick über den Tellerrand ist immer hilfreich, allerdings exist1iert im Gegensatz zu solchen Projekten für den RP6 keine wirkliche Community, welche gemeinsam die Libs weiter entwickelt. Deswegen wird es von mir dazu auch keine ZIP-Files geben. Denn ich möchte nicht, das meine Ergebnisse einfach so unreflektiert in anderen Projekten Eingang finden ohne das sich die Leute Gedanken machen oder Feedback geben.

Zu Buffer und IO noch ein Wort, gebufferte IO ist eine feine Sache aber sie birgt ein riesen Nachteil. Nutzt man mehrere Funktionen hintereinander, welche jeweils für sich buffern, frist das Speicher und ist sehr arbeitsintensiv weil ständig Bufferdaten von einem Buffer zu einem anderen umkopiert werden müssen. Die CPU hat ja keine DMA. Insbesondere dann wenn noch Daten per Value und nicht per Reference übergeben werden, kann man seine CPU massiv ausbremsen. Das allein ist schon Grund genug, die verwendeten IO Funktionen genau zu untersuchen und zu verbessern. Aber wie auch schon beim Interrupt - für ein einfaches LED aus/an oder ein paar Buchstaben auf der serial Console reicht das vorhandene und daher macht sich kaum jemand die Mühe.

Es gibt allerdings auch andere Ansätze dem System Beine zu machen z.B. in dem man sich ein RTOS Framework .. also preemtives Multitasking auf den Prozessor anpasst. Dann wartet ein Task halt bis er sein Job gemacht hat und gut is... hab ich auch mal ansatzweise hier beschrieben, es funktioniert einwandfrei. Allerdings ist der Denkaufwand auch höher weil man sich mit (für viele Leute) ganz neuen Konzepten rumschlagen muss.

Aus diesen und weiteren Überlegungen heraus schreibe ich derzeit sowas wie eine gebufferte, stringorientierte stdio, welche in der Lage ist, über eine Art Software Router ähnlich dem rpc auf Unix Befehlsketten an ein anderes Board via I2C und IRDA zu übergeben. Leider ist das langwierig und fehleranfällig da ich kein Profi progger bin.
Ich möchte aber wieder weg vom RTOS und die RP6Libs sind mir zu aufgebläht.
Ja mal sehen was bei raus kommt.
Dein Projekt klingt diesbezüglich auch interessant, ich hatte mal mit einem ARM7 Board am RP6 rumexperimentiert, ich glaube der User Radbruch hier hat auch ein ARM am RP6 laufen.
Gruß