16x MCP23017 per I2C

  • Hallo miteinander,

    ich habe bereits 8x MCP23017 an Pin 3/5 | GPIO 2/3 | SDA/SCL angeschlossen. Erkannt als Bus 20-27.

    Nun benötige ich weitere (bis zu) 8x MCP23017. Hierzu hatte ich mir notiert: Pin 27/28 | GPIO 0/1 | ID_SD/ID_SC.

    Wenn ich aber per i2cdetect -y 1 schaue, werden diese nicht angezeigt. (Alles korrekt verkabelt, wie die ersten 8x).

    Ich bin mir sehr sicher, dass dies so schon funktioniert hat. Ich habe Notizen, dass die MCP23017 als Bus 30-37 erkannt wurden.

    Installiert ist OpenHabian (up2date), auf einem Raspberry Pi 4.

    Was fehlt? Was muss ich noch tun?

    Ist die Belegung falsch?

    Vielen Dank!

  • Was passiert, wenn Du "i2cdetect -y 0" abfragst ?

    Sonst kannst Du mit dtoverlay= einen weiteren i2c Bus konfigurieren, wie es in /boot/overlays/README beschrieben ist.

    [ Name: i2c* und i2c-gpio]

    Mit "pinout" wird Dir auch die Belegung der Pin Leiste mit den zugehörigen GPIOs angezeigt.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Guten Tag,

    du @Crys hattest mich zum MCP23017 schon in einem anderen Thread angesprochen.
    Sorry wenn ich das so sagen muss, mit der I2C Variante hast du auf das falsche Pferd gesetzt.

    Du kannst mit einem I2C Bus nur 8 dieser MCP23017 betreiben, dann musst du entweder auf einen weiteren via /boot/config.txt hinzugefügten I2C Busse ausweichen, aber bekommst dann ein weiteres Problem, und das ergibt sich offensichtlich aus der anderen Nachfrage. Wie willst du dann für bis zu 16 dieser MCP23017 = 32 mögliche GPIOs bereitstellen, wenn du schon 4 GPIOs nur für die I2C Anschlüsse SDA + SCL benötigst ? Oder du weichst auf einen Multiplxer aus / um. Aber alle diese Lösungen kosten Zeit.

    Um z.B. 2 x 8 MCP23S17 (SPI) Portexpander zu steuern, benötigst du nur einmal den MOSI, den MISO und den SCLK, aber zweimal den CS. So nun kommt aber wieder das Problem zu tragen, wie willst du resultierend daraus, die möglichen 2 x 2 x 8 INT_A und INT_B Rückmelder abfragen ? Dir läuft irgendwann die Zeit davon, zumal der SoftI2C für die nächste 8er Gruppierung an MCP23017 ohnehin viel zu langsam ist, um hier noch auf irgendwelche Taster-Events an den als Eingänge genutzten Port-Pins zu reagieren. Wenn das Eingangssignal "Taster gedrückt" nicht länger als 20 ms Bestand hat setzt der MCP23x17 diesen INT Ausgang wie auch das abzufragende Portregister automatisch wieder auf den Ausgangszustand, bei einem Input = Pegel HIGH = kein Taster gedrückt.

    Bei der SPI Variane 2 x 8 MCP23S17 mit zwei direkt über die GPIO-Leiste geschalteten CS Pins, aber mit 2 x MCP23017 am Master I2C des PI ( Pin 3+ 5) und wieder nur 2 GPIOs zur INT Detektierung als Weiter- oder Durchleitung durch die MCP23017 hättest du noch zeitliche eine reelle Chance auf diese INTs der SPI MCP23S17 zu reagieren. Natürlich wird das ein recht aufwendiges Programmkonstrukt. Aber du musst wissen, die SPI Varianten sind schneller in der Datenübertragung als die langsameren I2C Varianten.

    es grüßt euer
    Willy

  • WillyR_aus_C vielen Dank für deine ausführlichen Erklärungen!

    ..., mit der I2C Variante hast du auf das falsche Pferd gesetzt.

    So läuft es. Es ist ein Hausautomatisierung-Projekt, dass wir vor 3-4 Jahren gestartet haben. Das Ziel war klar, wie man dort hinkommt, nicht ?

    • Im jetzigen Ausbauschritt benötigen wir 52 Ausgänge. Hierfür benötigen wir ja keine "Kontrolle" per INT!?
      Also sollten diese 4x MCP23017 I2C Boards funktionieren.
    • Des Weiteren werden aber im jetzigen Ausbauschritt auch 48 Eingänge benötigt. Also 3x MCP23017 die zusätzlich 6x GPIO Pins für die INT auf dem Raspberry benötigen.
      Ist das soweit korrekt?
    • Dies sollte also mit einer I2C Daisy Chain möglich sein?
      (Zwei, wenn man "der Ordnung halber" I/O trennt.)

    Das nur mal so weit. Für den weiteren Ausbau müssen wir uns mit der SPI Variante auseinandersetzten.

  • Falls Du noch freie USB Ports hast, könntest Du deinen RPi z.B. um weitere I2C Busse per USB to I2C Adapter erweitern. Als preiswerte Low-Cost Version, könnte man z.B. USB Adapter mit einem CH341T, einen DigiSpark oder evtl. auch weitere Adapter in Betracht ziehen. Eventuell kann man als IO Extender Ports auch andere I2C IC's mit einem anderem Adressbereich verwenden.

  • Ein Mikrocontroller wäre da flexibler. Eine weitere Möglichkeit wäre die Verwendung von CircuitPython (bare metal) auf dem RPi Zero (W2). Laut Doku wird bitbangio unterstützt und damit lässt sich I2C auch via Software ansteuern.

    Ich persönlich mag CircuitPython nicht so, aber gerade für Anfänger scheint das eher geeignet zu sein, als Micropython.

    Die meiste Arbeit haben die in die Vereinheitlichung der APIs gesteckt. Das hat man bei Micropython noch nicht.

    Ich weiß aber nicht, ob auch WLAN unterstützt wird.

  • Guten Tag

    Im jetzigen Ausbauschritt benötigen wir 52 Ausgänge. Hierfür benötigen wir ja keine "Kontrolle" per INT!?
    Also sollten diese 4x MCP23017 I2C Boards funktionieren.

    Als reine Output Einheiten , absolut kein Thema.

    Des Weiteren werden aber im jetzigen Ausbauschritt auch 48 Eingänge benötigt. Also 3x MCP23017 die zusätzlich 6x GPIO Pins für die INT auf dem Raspberry benötigen.
    Ist das soweit korrekt?

    Theoretisch soweit richtig.
    Ja, man kann es mit 6 GPIOs lösen, aber man muss sich in dem Falle auch klar sein, was das für mögliche Konsequenzen mit sich bringen kann. Hier spielt die Programmiersprache eine entscheidende Rolle. Wenn du das relativ langsame Python verwendest, sind 6 IRQ Events schon eine gewaltige Herausforderung. Da bist du selbst über den Zwischenschritt eines reinen als INPUT arbeitenden Expanders wie dem gleichschnellen MCP23x08 ( nur 8 Ports ) unter dem Strich nur auf ein Event / INT GPIO zu reagieren, -> diesen Zwischen-Expander als INT Auswerter auszulesen, und dann gezielt den Port des betreffenden großen Expanders sogar schneller, und du hast eine minimal größere Latenz, als wenn du nur einen Expander direkt über die GPIOs abfragst. Hier entstehen minimale Zeitbereichsüberschneidungen die man sich zu Nutze machen kann. Aber wieder das Problem bei I2C, wenn du den Adressraum der MCP230yy am Standard I2C Bus ( verbunden mit den PIns 3 + 5/ GPIO 02/03 ) ausgereizt hast, und auf einen zweiten I2C Bus ausweichen musst, bringt dieser nicht die volle Geschwindigkeit in der Datenübertragungsrate. Je nach PI Modell ist dieser bis zu 70 % langsamer !
    Und damit rückt diese 20ms Zeitfenster in eine fast nicht zu erreichende Entfernung. Hier spielt auch die Programmiersprache nur eine untergeordnete Rolle.

    Da deine Anfrage in der Überschrift gezielt die Aussage "16 x MCP23017 am I2C" enthielt, muss man sich auch im klaren sein, der Hardware unterstütze I2C Bus an den GPIOs 02/03 läuft standardmäßig nicht mit der maximal möglichen Übertragungsrate mit der ein MCP23017 betreiben werden könnte. Diese müsste man dann in der /boot/config.txt entsprechend Anpassen, oder Erhöhen.
    Jedoch dann ist der Bus auf diese Geschwindigkeit festgenagelt und es kann Probleme mit weiteren I2C Komponenten wie Display, ADCs usw. geben, die nicht für diese Geschwindigkeit ausgelegt sind.

    Dies sollte also mit einer I2C Daisy Chain möglich sein?
    (Zwei, wenn man "der Ordnung halber" I/O trennt.)

    Wie schon gesagt, an einen I2C Bus - egal ob über die GPIOs 02/03 und dann weitere GPIO Paare kannst du nur 8mal den MCP23017 hängen, denn mehr Adressen sind über A0-A2 nicht direkt ansprechbar ! Selbstverständlich kann man auch einen Multiplexer dazwischen schalten, um pro Multiplexer- Ausgang weitere 8er Paarungen dieser MCP23017 anzuhängen. Es ist eine Möglichkeit den grundsätzlich schnelleren I2C Bus zu erweitern, du verlierst aber trotzdem Zeit. Zudem, diese Multiplexer sind mit max. 400 kHz Clock-Rate auch keine Rennwagen ;) Der MCP23017 schafft bis 1,7 MHz, was über den Multiplexer betrieben nur ein Bruchteil der möglichen Datenübertragungsrate darstellt.
    Du könntest die reinen OUTPUT MCP23017s auf den zweiten langsameren I2C Bus hängen, was keine Auswirkungen auf die INPUT MCP23017s hätte. Aber irgendwie komme ich mit deinen Zahlen 16 x 16 I/O GPIOs ( 256 GPIO Ports in der Summe ) und den genannten "52 Ausgänge" und "48 Eingänge benötigt" nicht ins Geschicke -> Das sind bei mir nur sieben (7) MCP23017s !?
    Alternativ kannst auch den Weg gehen, was aber einen Totalumbau erfordern würde, wenn du unbedingt bei diesen Portexpandern bleiben möchtest.
    Du nimmst einen PCF8574, den du mit 400 kHz betreiben kannst, NXP Modelle (nicht die alten noch mit Philips-Logo, oder die von Texas Instruments -> die schaffen nur 100 kHz) und schaltest damit via I2C die CS Signale für den SPI-Bus. Pro CS Kreis kannst du 8 dieser MCP23S17 anschließen -> also kommst du auf maximal 8 x 8 x 16 GPIOs = 1024 I/O Ports. Und kannst diese wiederum vermindert auf die Anzahl der mit Eingängen belegten einzelnen MCP23S17 zur INT Auswertung auf die MCP23017 legen, wo du pro MCP23017 immerhin 8 dieser MCP23S17 auf einen INT Event -> Weiterleitung zu den GPIOs des RasPi abfragen könntest. Der PCF8574 verursacht keinen Adressenkonflikt mit den anderen I2C Portexpandern, und zum Schalten und halten des CS Signals ist dieser ausreichend schnell.

    es grüßt euer
    Willy

  • Guten Tag,

    Eine weitere Möglichkeit wäre die Verwendung von CircuitPython (bare metal) auf dem RPi Zero (W2).

    eine sehr langsame API.
    Im Vergleich mit Python und SMBus sind diese Adafruit Treiber im Verhältnis zur direkten Nutzung von SMBus, SPIDEV bis zu 8 mal langsamer.

    Ein Mikrocontroller wäre da flexibler.

    Gebe ich dir dahingehend recht, nur ist der

    RPi Zero (W2)

    kein Mikrocontroller !
    Auf einem Raspi Pico mit einem RP2040, der über zwei I2C Hardware Hosts verfügt, oder in der Erweiterung SPI, auch hier wieder mit zwei Hosts daher kommt, kann man das natürlich viel schneller abwickeln als mit einem PI. Das Pi mit einem Linux-Kernel, als Unterbau, schafft im SPI Mode auch nur knappe 3,5 MHz Clock-Rate. Der nicht übertaktete RP2040 spielt hier noch bis 8 MHz mit, was aber immer noch nicht dem entspricht, mit was ein MCP23S17 betreiben werden könnte ! -> Clock-Rate-Limit 10 MHz !

    Da hier aber vom TO Crys die Auswertbarkeit der INT_A und INT_B Event-Rückmelder angesprochen wurde, brauchst du mit dem langsameren Code von CircuitPython gar nicht anfangen, wenn du mehrere dieser Portexpander auf solche Events triggern willst. Das habe ich schon ausprobiert. Der dazugehörige Adafruit Code ist einfach zu langsam, da können einem einzelne INPUT Events, besonders wenn diese von elektronischen, nicht prellenden Schaltquellen stammen, durch die Lappen gehen, sowie eine Mehrfach-Eingabe (das zeitgleiche betätigen mehrerer Taster an verschiedenen Stellen über mehrere MCP23017 verteilt) bekommt man gar nicht ausgewertet.

    Oder man ist so Krank, entschuldige bitte das Wort, dass man auf dem BUS herumpollt. Nur dann bleibt nur sehr wenig CPU-Zeit über, um andere Dinge auszuführen, z.B. eine grafische Display-Ausgabe zu gestalten. -> Die Betonung liegt bei dieser, deiner Aussage in der Verwendung von CircuitPython auf einem RasPi mit einem Linux Kernel Unterbau, und der Nutzung der dazugehörigen ADAFRUIT Treiber. Unter / mit C/C++ ist das ein ganz andere Sache.

    es grüßt euer
    Willy

  • eine sehr langsame API.
    Im Vergleich mit Python und SMBus sind diese Adafruit Treiber im Verhältnis zur direkten Nutzung von SMBus, SPIDEV bis zu 8 mal langsamer.

    Also hast du schon mal CircuitPython Bare-Metal auf dem RPi0 laufen lassen? Oder wie kommst du zu dem Schluss, dass das 8 Mal langsamer ist? Das scheint einigen noch nicht so ganz bewusst zu sein, dass es zwei unterschiedliche Versionen gibt. Einmal die Python-Module von Adafruit und dann der Fork von Micropython, der Bare-Metal läuft, sprich kein OS ist dazwischen.

  • 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 :gk1: 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.

    es grüßt euer
    Willy

  • Eigentlich hätte ein klares: "Ja, ich habe selbst schon einmal Circuit-Python Bare Metal eingesetzt und kann deswegen eine fundierte Aussage treffen" oder "Nein, ich habe Circuit-Python noch nie Bare Metal eingesetzt und kann deswegen keine Aussage darüber treffen." hätte ausgereicht.

    Ich wollte nichts über die Theorie erfahren, sondern über gesammelte Erfahrung mit CircuitPython.

    Wie I2C funktioniert, weiß. Was ich nicht wusste, dass bitbangio gar nicht Bare Metal auf dem RPi Zero W zu funktionieren scheint. Es geht einfach nicht.

    Zitat

    TimeoutError: Clock stretch too long


    Wenn ich eins gelernt habe, ist: Wenn jemand einfach behauptet, dass etwas nicht geht, kommt jemand anderes und setzt das einfach um.

    Das ist schon oft genug passiert.

  • Moin

    Eigentlich hätte ein klares: "Ja, ich habe selbst schon einmal Circuit-Python Bare Metal eingesetzt und kann deswegen eine fundierte Aussage treffen" oder "Nein, ich habe Circuit-Python noch nie Bare Metal eingesetzt und kann deswegen keine Aussage darüber treffen." hätte ausgereicht.

    Was hat das jetzt mit dem Thread zu tun ?
    Sorry, der TO Crys hat eien Aussage gemacht das er OpenHAb auf einem RasPi 4, sowie der Tatsache, das er an den GPIO-Pins Nr. 27/28 das zweite MCP23017 Array angeschlossen hat, welches nicht erkannt wird.
    Dazu muss man in erster Linie einen Eintrag in der /boot/conig.txt ergänzend einfügen, damit diese als zweiter I²C Bus fungieren können.
    Was hat das nun mit deinem Circuit-Python zu tun ?
    Ebenso ist die gemachte Aussage korrekt, das dieser zweite zusätzliche I²C Bus nicht die gleiche Leistungsfähigkeit besitzt wie der Hardware Supported I²C Bus der über die GPIOs 02 und 03 bereit gestellt wird.
    Weiterhin wenn man sich mit OpenHAT beschäftigt ist erst einmal nichts mit einem Python Direktsupport zu lesen. Aber auch die Schnittstellen zu Node-RED als mögliche Vermittlerschicht unterstützt nativ keine Auswertung der INT-Rückmelder des MCP23017.
    Hier pollt dann ein Thread wie bekloppt auf dem BUS herum, um ständig irgendwelche INPUT Abfragen zu machen. Das kann man mit einem Oszilloskop an SCL Pin sehr gut nachvollziehen.

    Da hier aber vom TO weder die Aussage gemacht wurde, wie er innerhalb von OpenHAT diese MCP23017 Arrays eingebunden hat und abfragt, noch wie sein bisheriges, und in der Erweiterung geplantes Gesamtschaltbild aussieht, ist diese ganze Diskussion um eine eigene Version von Python -> Circuit-Python vollkommen gegenstandslos.

    Denn in der Summe 16 dieser MCP23017 über die VC3,3V des PI zu betreiben - GPIO-Pin 1/17 oder bereitgestellt aus den VC5,0V der PINs 2/4 ist schon ein harter Tobak. Mit einer maximalen IOUT pro MCP23017 Expander von 150 mA und selbst wenn von diesen vielen OUTPUT GPIOs nur ein Optokoppler angesteuert wird, ist man da ganz schnell an der Grenze das machbaren.
    Hier fehlt auch noch die Aussage des TO, wie diese vielen MCP23017 mit Spannung versorgt werden.
    Bei einem Ptot von 700mW und das mal 16 benötigt er eine Spannungsversorgung für 16 dieser MCP23017 die einen Dauerstrom von über 2,5 A Liefern kann. Das kann man nicht einfach und direkt vom RasPi Board, egal ob über 3,3 V oder 5,0 V, abzweigen !

    Hier gehört für mein Verständnis als Erstes der Schalt- oder Verdrahtungsplan auf den Tisch, und dann kann man sich im zweiten Schritt darüber Gedanken machen, wie man einen zweiten I²C Host zum Leben erweckt, um dann klären zu können, wie man ohne Polling auf dem Bus(sen) mit Hilfe der INT-A und INT-B Rückmelder dieses in das System einbinden könnte. Wobei jede zusätzliche Zwischenschicht, wie auch Node-RED einen Latenzverlust mit sich bringt.

    Von deinem Gedankenansatz ->

    Ein Mikrocontroller wäre da flexibler.

    als abfragendes und schaltender Controller einzubringen und über eine eigenen Kommunikationskanal mit diesem OpenHAT zu kommunizieren, hierfür erhältst du meine volle Zustimmung. Was aber und insbesondere eine gesonderte Vc Versorgung der MCP23017 ( Platinen ) unabdingbar machen würde.
    Was dort dann auf diesem µC läuft, ob µPythonb, Circuit-Python, oder ganz klassisch in C/C++ geschrieben das steht dann auf einem ganz anderen Blatt. Hier kann dein Vorschlag als einfachere, verständlichere Programmiersprache, wie dieser Python Fork durchaus Geschwindigkeitsvorteile gegenüber µPython bringen. Da will ich an dieser Stelle noch nicht einmal in Abrede stellen.

    Franky

  • Was hat das nun mit deinem Circuit-Python zu tun ?

    Das war ein alternativer Vorschlag, die Hardware zu nutzen, bzw zusätzlich einen Mikrocontroller zu verwenden.

    Witzigerweise gibt es das auch für den RPi4. Bringt aber nichts, da er OpenHabian nutzen möchte, geht das nicht.

    Beachtlich ist die Boot-Zeit. Die beträgt ca. 8 Sekunden auf einem alten Rpi0W.

    Ich bin kein Fan von CircuitPython, aufgrund der Vorgeschichte mit CPython. Die kritischen Module sind direkt in C umgesetzt: https://github.com/adafruit/circu…ngs/busio/I2C.c

    Das ist bei Micropython auch so und CircuitPython ist ein inkompatibler Fork von Micropython.

    Einzige gute Nachricht: Die Micropython-Entwickler arbeiten an einer Kompatibilitätsschicht für Adafruit-Treiber.

    Wenn der Rpi mehr als einen Hardware I2C hat, könnte man den ja nutzen. Nur das mit dem Stromverbrauch der ADC stellt ein Problem dar. Wenn der zusätzliche I2C-Port nicht nutzbar wäre, kann man immer noch einen I2C-Portexpander nehmen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!