Guten Morgen
Bare-Metal auf dem RPi0
Ich verstehe die Aussage als technischer Hintergrundinformation, aber mehr auch nicht.
Entschuldige, ich kann in den Beiträger den TO nicht erlesen das er einen PI-Type hat, welche für diese Auskopplung von CircuitPython verwendet werden kann. Wenn du meine Ausführungen bis zum Ende durchgelesen, und vor allem verstanden hättest hatte ich hier zu ein ganz klare Aussage gemacht.
Wer auf Adafruit Treiber, wie für diese I/O Platinen auch angeboten werden, und im eigentlichen Sinne noch Python nutzt, nur diese Adafruit CircuitPython Treiber, wird wenn er nicht selber die Treiberbibliothek für den MCP23X17 programmieren will, immer der langsamere sein. Wenn dann solche Python Module wie BOARDIO dazukommen, wieder wie schon geschrieben mit Python als Interpreter, wird immer im Timing den kürzeren ziehen. Und dann ist es noch eine Auswertungssache, bzw auch ein Kompatibilitätssache, die hier eine Rolle spielt. Zudem welchen Aufwand der TO betreiben möchte. Schneller als ein reines C-Programm kann er nicht werden. Außer er proggt das PI in Assembler. Und trotzdem wirst du auf einen zusätzlichen I2C Bus der via /boot/config.txt bereitgestellt werden kann niemals die maximal mögliche Übertragungsrate hinbekommen, wie sie über den Standard I2C Bus an GPIO02/03 möglich ist, schon gar nicht mit einer tatsächlichen Clock-Rate über 400 kHz. Hier hilft ein Oszilloskop bei der Überprüfung der realen Werte.
Ich gebe dir dahingehend recht, wenn du einen Mikrocontroller ins Spiel bringst, und sagst du steuerst diese vielen MCP's alle mit einem PICO oder ESP, und leitetes die Daten für eine Ausgabe / Anzeige über einen weiteren Kanal zu einem PI oder weiteren Mikrocontroller weiter welcher nur die Visualisierung / Interaktionsfähigkeit via Touchdisplay ermöglicht. Denn auch in den Mikrocontrollern ist bei dieser Menge an externen I/O GPIOs nur noch sehr wenig Platz ( RAM ) um hier aufwendige Inaktionsmodelle abzulegen, aber rein von der Abfrage der Portregister haben diese Mikrocontroller noch sehr viel Luft nach oben. Bei einem RasPi Pico kann man hier volle Kanne auch über 2 Bus-Hosts die Clack-Rate sogar bis weit über 1,2 MHz hochtreiben, ohne das dieser in Schleudern kommt. Das macht dann natürlich einen Unterschieden in der Abfrage, und der benötigten Durchlaufzeit wenn ich aus dem Rückmeldung(en) auswertenden MCP23017(s) diese mit 1,2 MHz auslesen kann, und somit ein einem Dritte der Zeit an die Info komme, welchen MCP23S17 auf welches Portregister ich dann mit über 3 MHz Clock Rate abfragen kann. Und da spielt auch der langsamere PCF8574 wenn diese Ausbaustufe erreicht werden sollte kein Rolle, oder dann doch der GPIO.Falling Event - denn für diese IRQ Event Detektierung benötige ich nur ca. 50ns auf einem 133 MHz getakteten PICO. Damit hat man das sehr viel Luft, oder Zeit das entsprechende Portregister auszulesen. Selbst wenn man auf einen MCP23017 als Rückmeldungssammler angewiesen ist. Denn der MCP23x17 reagiert innerhalb von 52 ns auf diesen Input Event, mit einer Signalausgabe über die INT Ausgänge.
Es nützt auch keinem etwas, wenn man von der Grundkonfiguration des normalen RasPi mit RaspbianOS ausgeht, hier superschnelle Bibliotheken zu nutzen, die selber ohne Anpassung der Bus-Geschwindigkeit nicht wirklich zum tragen kommen. Du kannst es gerne probieren, nimm ein 4er PI, einen MCP23017 und einen MCP23S17 und versuche diese in der Grundeinstellung des OS mit der maximalen Clock-Rate zu betreiben. Selbst mit C++ Programmen wirst du ohne einen tieferen Eingriff in das System diese Chips niemals bis zu ihrer Geschwindigkeitsgrenze ausreizen können.
Damit ist die Diskussion für mich ohnehin obsolet, wenn der TO nicht gewillt ist, oder in der Lage ist sich anhand der Datenblätter egal für welches Programmiersystem er sich entscheidet, hier mit irgendwelchen CircuitPython Ablegern zu kommen, wenn ihm die Programmierkenntnisse fehlen. Da die meisten User ohnehin auf Fertigbibliotheken oder -treiber zurückgreifen, die ihnen eine maximale Flexibilität bieten, und somit auch recht einfach zu handhaben sind, steht hier der Grundsatz einer Anwendungs- und Geschwindigkeitsoptimierten Single Lösung wohl auch gar nicht zur Debatte.
Jedoch auf Grund seiner Fragen und Nachfragen, sowie der Eingangsfrage gehe ich davon aus, das der TO nicht über solche umfassenden Programmierkenntnisse verfügt, wenn er schon mit den Dingen Probleme hat, wie erweitert man ein solches Array aus 8 x MCP23017 um noch einmal die gleiche Anzahl MCP23017. Wobei dann hier auch die Frage ist und bleibt, wie bekommt man ohne extremen RasPi GPIO Belegungsaufwand eine solche Interrupt Rückmeldung gehändelt. Denn egal was man macht oder treibt, man hat nur die (langen) 20ms Zeit auf den gemeldeten Event über INT_A oder INT_B, oder eine Vielzahl dieser zu reagieren, sonst ist auch abhängig / ggf einer kürzeren To-Low Schaltphase der Portregistereintrag wieder in dem Status den der Eingang nun real hat. Ja, 20 ms sind verdammt viel Zeit. Aber hier muss der Prozessor oder Mikrocontroller auch reagieren können. Und bei der Vielzahl an möglichen Rückmeldern 2 x 2 x 8 = 32 GPIOs wird es beim PI verdammt eng
Ebenso schafft man es mit Polling nicht, über einen nur mit 100 kHz laufenden I2C Bus inkl. der Umschaltzeiten 32 einzelne Portregisterabfragen durchzuführen und auszuwerten, wenn man auf die Interpretersprache Python setzt, um innerhalb dieser 20 ms pro Portregister zu bleiben -> hier jetzt nur die reine fortlaufende Abfrage aller möglichen 32 Portregister ohne die Nutzung der Rückmelder INT_A und INT_B.
Da wir aber alle kein haben, und nicht vorhersagen können wir der TO diese seine Steuerung programmiert hat, und welche Programmiersprache er verwendet, können wir uns hier noch Stunden in spekulativen Diskussionen üben, es wird den TO nicht wirklich weiter helfen.