Zitat Zitat von SlyD
OK gut - wie ich schon geschrieben hatte hattest du glaube ich deinen Beitrag da oben auch nochmal editiert das hatte ich nicht gesehen - oder meine Augen lassen nach
*grins ... sollich dir meine Lesebrille leihen

Zitat Zitat von SlyD
Dennoch: Der Ringbuffer ist notwendig wenn Du tatsächlich wie in dem Testcode von Dirk nahezu komplett ohne Pause Daten in Richtung Slave ballerst

Sonst kann da natürlich mal was überschrieben werden bevor der Slave überhaupt mitbekommt das sich da was geändert hatte (läuft ja asynchron zum Hauptprogramm).
Genau das ist das hüpfende Komma.... und das wäre zu prüfen. Wenn es so ist... ok. Wenn es doch echte verlorene Zeichen sind, gehts weiter mit der Fehlersuche... Aber der Hinweis ist wichtig, man muss dem Slave natürlich Zeit lassen um Daten zu verarbeiten... man kann den nicht mit Daten bombardieren und erwarten das er immer sofort reagiert.

(@Fabian, da ist auch dein Delay mit 50 ms aus dem Beispiel zwischen schreiben der LEDs und lesen von Zustand zu kurz gesetzt - das TWI ist einfach zu schnell dafür. Du stresst hier die Base und nicht das TWI. Für die Base würde sich ein Busy Flag im Statusregister anbieten was anzeigt ob die Base schon aktiv war.. das der Master dann abfragt und erst liest wenn das Bit getoggelt ist. Macht mit mehreren Mastern z.B. bei eienr M128 aber auch Probleme, ist als wenn, dann nur ein Notpflaster. Ihr müsst euch glaub ich erst an das schnellere TWI gewöhnen Übrigends kann man das was ich der M32 beibringe auch mit der M128 machen... "kann das nicht" gibts nicht! Ich hab ne M128 hier liegen.. also irgendwann.... )

Das kann so wirklich nur eine Pipe mit Ringbuffer. Ich halte es für realistisch, sich auf 3 bis 5 Updates/sec eines kompletten Registersatzes zu beschränken, aber die umgebaute Lib zeigt mit Dirks Programm zumindest was nun auf dem TWI möglich wäre. Da ist 1% Fehlerquote ohne Terminalausgabe schon ganz gut. Vielleicht kann man da tatsächlich einen Ringbuffer einbauen aber zuerst muss alles andere laufen. Ein Ringbuffer für Registeraccess ist mässig sinnvoll (man müsste ein Ringbuffer in der Breite der Register bauen, also 16 byte x z.B. 8 Byte Tiefe, was min. 128 Byte fürs Schreibregister an kostbarem RAM verballert - und auch 8 byte Buffer kriegt man bei 100Kbit/sec schnell platt geschrieben.) und direkte Kommunikation via Pipe zwischen Prozessoren eher ne Aufgabe für linux oder so . Aber vielleicht findet sich mal jemand der sowas umsetzt wenn die Grundlagen funktionieren.
Die generic Adresse 00 würde sich für so Spielchen anbieten. Eine Pipe wäre dann sozusagen ein Broadcast und das Protokoll muss sicherstellen das der richtige Prozessor sich angesprochen fühlt. Von mir aus dann auch mit crc und so Schnickschnack Dann noch 8 M32er auf die Base und man hat den kleinsten Clusterbot der Welt

Zitat Zitat von SlyD
So nun aber genug geschrieben für heute
Dir ein schönen Feierabend Mein RP6 ist aufgeladen, kann weiter gehen mit testen
LG Rolf