Hi RolfD,

prinzipiell finde ich deinen Vorschlag gut, allerdings habe ich Verständnis-Fragen dazu:

1. Der Hauptzweck mobiler Roboter besteht ja sicher eher nicht darin, Messwerte und Daten in großer Menge ANZUZEIGEN, sondern ihr Verhalten daran auszurichten. Das heißt nicht, dass das Anzeigen von Daten nicht wichtig wäre: Im Gegenteil kann man das gut zur Kontrolle der eigenen Programmierung nutzen. Frage: Braucht man also optimierte Ausgabefunktionen unter der genannten Einschränkung?

2. Durch die Aufteilung der Prozessoren im RP6-System (Base, M32, M128, M256 WiFi) auf jeweils eigene autonome Systeme müßte man ja im Prinzip die printf/scanf Funktionen für jede dieser Plattformen zur Verfügung stellen (das ist ja bei den jetzigen Funktionen auch so). Macht das Sinn?

3. Die printf/scanf Funktionen haben ja ihre Hauptvorteile neben den standardisierten Formatierungen in der einfachen Wählbarkeit des Ein-/Ausgabekanals. Das finde ich natürlich auch reizvoll. Aber: Nicht alle "Kanäle" (I2C, UART, SPI, Filezugriff auf SD, int./ext. EEPROM ...) sind auf allen Plattformen verfügbar. D.h. man würde nicht den Zugriff auf alle Kanäle auf jeder Plattform brauchen. Einverstanden?

4. Reizvoll wäre auch, wenn die verschiedenen Kanäle über das komplette RP6-System von allen Plattformen hinweg angesprochen werden könnten. Das scheitert allerdings daran, dass als alleinige Verbindung zwischen den Plattformen der I2C-Bus vorgesehen ist. Dazu kommen dann nur noch je nach Hardwareausstattung wenige Ein-Ausgabekanäle auf der jeweiligen Plattform. Und: Zur kabelgebundenen Verbindung zum PC wird ausschließlich der UART verwendet, eine Kommunikation ist aber davon abhängig, ob das Interface gerade an die jeweilige Plattform angeschlossen ist. Welche Vorteile könnten printf/scanf Funktionen bei dieser vorliegenden Hardware bringen?

5. Was meinst du mit "Entschlackt man aber die Programme und wirft die RP6 Funktionen raus, spart man auch wieder Platz."? Die meisten Funktionen in den RP6 Libs sind ja nicht Ein-/Ausgabefunktionen. Was sollte man da rauswerfen (ok, die bisherigen Ein-/Ausgabefunktionen ja auf jeden Fall,- die würden ja durch neue Funktionen ersetzt...), ohne dass Funktionalität fehlt?

6. Was schätzt du, wie hoch der Aufwand ist, die Ein-/Ausgabefunktionen und ggf. die Demos neu zu schreiben? Würdest du das unter best. Bedingungen angehen?

7. Würdest du mal eine "Musterfunktion" oder Demo zum Testen hier zeigen?