Statt MCP23017 wurden MCP23S17 vom Asiaten geliefert

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Guten Tag,

    Da z.Z. die Portexpander MCP23017 hier in D nahezu unbezahlbar geworden sind, hatte ich nun bei einem Händlerportal diese Schaltkreise von einer asiatischen Quelle bestellt. Nun sind die Teile gekommen, der Aufdruck ist nahezu unlesbar.
    Nachdem diese Chips auf die Beschaltung wie für den I²C-Bus abgedacht nicht funktionierten, brachte mich jemand auf die Idee, probiere es doch einmal mit der Beschaltung des MCP23S17 für den SPI-Bus. Und siehe da an einem 3er PI funktionieren die Teile. Die dafür gefundenen Codes für Python mit RPI.GPIO funktionieren.
    Nun dachte ich mir auch kein Problem, also kann ich diese auch an ein ESP32 anschließen (was auch ursprünglich dafür vorgesehen war), der auch über einen SPI Bus verfügt. Nun habe ich schon ganze Nächte damit verbracht einen Code für µPython zu finden. Leider bisher ohne Erfolg.
    Meine Frage dazu: Kennt oder hat jemand eine Funktionsbibliothek für den MCP23S17 in µPython, den er mir zur Verfügung stellen könnte ? Ich möchte diese Expander (4 Stück zusammen) wirklich nur als OUTPUT nutzen.

    :danke_ATDE:

    Reichen die 3,3 Volt des ESP32 am Pin0 (3,3 V out) aus um 4 dieser MCP23S17 mit nachgeschalteten LED Treibern zu betreiben, oder sollte man lieber aus der Vc 5,0 Volt über die auch das ESP32 versorgt wird einen zusätzlichen 3,3 Volt Stromkreis aufbauen ?
    Als LED Treiber hatte ich an an eine MOSFET Stufe gedacht, mit der ich direkt über den MOSFET jeweils einen 12 Volt 4 Watt LED Spot nur auf ein / aus ansteuere. [ Ergänzend es werden immer nur 3 dieser LED Spot zeitgleich angeschaltet sein. ]
    Dazu meine zweite Frage: Welcher FET und was müsste ich das noch beachten ?

    :danke_ATDE:

    es grüßt euer
    Willy

  • Statt MCP23017 wurden MCP23S17 vom Asiaten geliefert? Schau mal ob du hier fündig wirst!

  • Datenblatt: MCP23017/MCP23S17

    Der einzige Unterschied scheint nur das Protokoll (I2C vs. SPI) zu sein.

    Als Vorlage könnte man diesen Code verwenden: https://github.com/jebentancour/P…/Pi_MCP23S17.py

    Der muss aber angepasst werden, da es spidev auf dem ESP32 nicht gibt. Diese blödsinnigen assert statements können auch raus.


    Ich habe mal damit angefangen, getestet ist aber noch gar nichts und mögliche Probleme könnten auch noch durch Unterschiede zwischen CPython und Micropython auftreten.

  • Guten Tag @DeaD_EyE,

    Danke für den Code, mit kleinen Anpassungen hatte er soweit auch funktioniert.
    Aber leider und hier fehlt mir das Verständnis, um diese ganzen Hex-Code-Zahlen.
    In der Konfiguration A0 = 0 , A1 = 0 und A2 = 0 gemäß Adress-Pin Jumperung ( Pegel LOW ) funktioniert dein Codebeispiel. Jedoch möchte ich über einem BUS mit einem CS vier dieser Schaltkreise ansprechen. Das heißt sobald ich die Adresse an den A=-A2 Pins durch setzen auf HIGH abändere erhalte ich einen OSERROR.

    es grüßt euer
    Willy

  • Guten Tag

    "unbezahlbar" ist ja relativ zu den eigenen Ansprüchen, aber es gibt MCP23017 (und auch MCP23S27) bei diversen deutschen (seriösen) Onlinehändlern für 2-3 Euro/St. zzgl. Porto.

    Hast du das mal ausgerechnet ?
    Ich hatte bei mehreren mir bekannten Händlern, wo ich auch ein Kundennummer besitze nachgesehen, ebenso bei der alles liefernden "(J)AmmerZone" und bin dann mit dem Porto dann bei einem Stückpreis von über 5 Euro gelandet. Vergleicht man das mit vor gut einem Jahr habe ich bei meinen "Standard-Online-Shop" für 10 Stück | 0,42€/ Part + 2,95 € Versand bezahlt. Schau man dann noch in die "Ä-Bucht" werden zt Preise von bis zu 14 € / Part aufgerufen ( Sofortkauf ).
    Betrachtet man das nun mit dem was ich bezahlt habe, wenn ich nicht das gewünschte geliefert wurde, liege ich hier bei einem Preis inkl Porto von 1,37 € / Part für den MCP23S17. Selbst das ist noch günstig um nicht zu sagen billig, wenn man das mit den meisten deutschen Elektronik-Versendern vergleicht.

    es grüßt euer
    Willy

  • Hallo,

    Hast du das mal ausgerechnet ?

    Gegenfrage: wie rechnest du denn deine Arbeitszeit? Mit Null, weil deine Lebenszeit / Arbeitszeit nichts wert ist? Dann geht deine Rechnung auf. Wenn nein kann die auf keine Fall auf, weil die schon X Minuten / Stunden damit verbraucht hast, deine Fehllieferung zum Laufen zu bringen.

    Zitat

    Schau man dann noch in die "Ä-Bucht" werden zt Preise von bis zu 14 € / Part aufgerufen ( Sofortkauf )

    Du musst auch nicht das teuerste kaufen... Bei Reichelt bekommst du den MCP23017 für 2,75 Euro/St. zzgl. Porto. Klar, wenn du nur einen brauchst ist das teuer. Aber klingt ja so, als hättest du mehr bestellt.

    Gruß, noisefloor

  • In der Konfiguration A0 = 0 , A1 = 0 und A2 = 0 gemäß Adress-Pin Jumperung ( Pegel LOW ) funktioniert dein Codebeispiel.

    Die gibt es bei SPI nicht. Adressiert wird SPI einmal über die Bus-Nummer (im Chip implementiert) und der entsprechende Teilnehmer wird mittels /CE (ChipEnable) aktiv geschaltet. D.h. für jeden SPI-Bus-Slave wird ein eigenes ChipEnable-Signal benötigt.

    Da ich den Code übernommen habe, sind noch teile von I2C irgendwo drin.

    Besonders gut ist der Code auch nicht, da viele Methoden sinnlos doppelt vorhanden sind.

    Jedoch möchte ich über einem BUS mit einem CS vier dieser Schaltkreise ansprechen. Das heißt sobald ich die Adresse an den A=-A2 Pins durch setzen auf HIGH abändere erhalte ich einen OSERROR.

    Nicht die Address-Pins des Chips mit der I2C-Version verwechseln. Jeder SPI-Chip hat nur einen /CE-Eingang.

    Der OSError kommt meistens zustande, wenn man mittels I2C oder SPI etwas schreiben/lesen will und keine Antwort bekommt. Funktionen/Methoden, bei denen in der Hardware irgendwas schiefläuft, werfen meistens einen OSError. Das unterscheidet sich stark von CPython.

    Wenn ich motiviert genug bin, schaue ich mir den Code noch mal an.

    Das, was bereits an Code vorhanden ist, kann ich sicherlich mehr als um 1/3 reduzieren.

    Es wäre auch gut zwei Varianten zu haben und eine Basisklasse, die ausschließlich die Logik des Chips implementiert, aber losgelöst von der Kommunikation ist. Auch das lässt sich ziemlich sauber programmieren. Man merkt bei existierendem Code oft, dass Anfänger und/oder Leute beteiligt sind, die eher mit anderen Sprachen entwickeln und oftmals nur das implementieren, was sie selbst benötigen (mache ich auch oft).

  • Guten Abend @DeaD_EyE,

    Eine vollkommen falsche Aussage !



    Auch auf dem SPI Bus sind, wenn diese Angaben stimmen, und so dem Datasheet auf Seite 15 zu entnehmen die PIN Pegel der Pins für A0 bis A2 relevant .
    Weiterhin habe ich in den weiterführenden Links diese Schaltskizze gefunden.



    Daraus wird ersichtlich, dass der 23S17 genauso wie der I²C via dieser A=-A2 Adressen angesprochen und über nur eine CS Signal-Leitung gesteuert werden kann.
    Oder habe ich da jetzt einen totalen Denkfehler ?

    es grüßt euer
    Willy

  • Guten Abend @DeaD_EyE,

    Zumal eine Code den ich für das PI ( das Große ) gefunden habe, und auch für Python geschrieben ist, hier jedoch "SPIDEV" verwendet wird .
    Ebenso gibt es einen Code für RPI.GPIO.

    Leider fehlt mir noch das Verstädnis diesen Code egal ob mit RPI.GPIO oder SPIDEV geschrieben in µPython zu übersetzen.

    Das bitte nur als erklärenden Nachtrag betrachten.

    es grüßt euer
    Willy

  • Moin WillyR_aus_C,

    ich gebe @DeaD_EyE vollkommen recht bezüglich seiner Aussagen zum SPI-Protokoll!! Siehe LINK .

    Er kann nichts dafür das die Entwickler des MCP23S17 eine Auswertung der Adresspins eingebaut haben.

    Auf der gleichen Seite des, von die verlinkten Datenblattes, steht aber was sehr wichtiges. Ich füge mal eine Übersetzung von deepl.com ein.

    Zitat

    Der MCP23S17 ist ein Slave-SPI-Gerät. Der Sklave Adresse enthält vier feste Bits und drei benutzerdefinierte Bits Hardware-Adressbits (falls über IOCON aktiviert. HAEN) (Pins A2, A1 und A0) mit ausgefülltem Lese-/Schreibbit das Steuerbyte. Abbildung 3-5 zeigt das Steuerbyte Format. Die Adress-Pins sollten extern verzerrt sein auch wenn deaktiviert (IOCON. HAEN = 0).

    Aus Seite 16 des Datenblattes steht: Address pins are enabled/disabled via IOCON.HAEN.

    Du musst also nur die Variante bearbeiten und dann sollte es klappen.

    Persönliche finde ich es sehr unfair wie du @DeaD_EyE in deinem Posting #8 behandelst. Letztendlich hat er dir einen Code gebaut, der, nach Änderungen, bei dir funktioniert.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Guten Tag Bernd666, @DeaD_EyE

    ich hatte mit meiner Antwort keinesfalls vor jemanden vorzuführen.

    Ich habe nur auf Grund des Links, den @DeaD_EyE bereit gestellt hat eine Feststellung gemacht ( ohne Feststellschrauben ;) ) dass der von Ihm dankender Weise weitergegebene Code nicht mit allen Beschaltungsvarianten um die PIN A0 bis A2 funktioniert.
    Ich habe mich auch nicht mit dem Ausgangscode der I²c Variante beschäftigt, auf den er sich für seine Modifikation auf SPI bezogen als Grundlage genutzt hat.
    Dazu bin ich nun auf diese Tabelle:

    gestoßen, und kann jetzt erst einmal mir keinen Reim darauf machen, wie diese HEX Zahlen sich zusammensetzen.

    Immer wider finde ich in dem Code diese Zeichenfolge & 0x07.
    Normal müsste ich das jetzt wenn ich das Richtig verstehe diese CONST ja ?

    Wäre jetzt meine Annahme richtig, dass ich zu dem IOCON_HAEN = const(0x08) diese A0-A2 Bit hinzurechnen ? Aber das Funktioniert dann so aber auch nicht. HEAN + A2 +A1 +A0 + diese Registerwerte aus der oben angeführten Adresse müsste dann doch den Code / Wert ergeben, der an den MCP23S7 via MOSI bei CS OW gesendet wird ?
    Was mir hier aufgefallen ist, ich es mir aber nicht erklären kann, warum diese Werte in

    Python
            self.spi = bus
            self.ce = ce
            self._GPIOA = 0x00
            self._GPIOB = 0x00
            self._IODIRA = 0xFF
            self._IODIRB = 0xFF
            self._GPPUA = 0x00
            self._GPPUB = 0x00

    völlig von dieser Tabelle aus dem Datenblatt abweichen.

    es grüßt euer
    Willy

  • Ja, da ist einiges Durcheinander.

    Dass die SPI-Version auch Address-Pins hat, habe ich übersehen..

    Jedenfalls hat man dann zwei Möglichkeiten, die zu adressieren.

    So wie ich das jetzt verstanden habe, sind die Address-Pins immer aktiv, sofern man sie nicht deaktiviert.

    Wenn man die SPI-Variante hat, gibt es die Address-Pins auch, aber zusätzlich muss der CE auf Low gezogen werden.

    So könnten dann 8 Chips mit ein und demselben /CE verwendet werden. Alle müssten dann unterschiedliche Adressen zugewiesen bekommen.

    Wie schon von Bernd666 angemerkt, kann man das deaktivieren.

    Auf die Richtigkeit der Konstanten würde ich mich bei dem Code nicht verlassen.

    Oftmals werden Sachen falsch umgesetzt, funktionieren aber trotzdem irgendwie, weil der Chip bestimmte Bits einfach ignoriert.

    Um das vernünftig umzusetzen, muss ich mir Kapitel 3 komplett durchlesen.

    Bei dem Chip gibt es auch noch zwei unterschiedliche Modi:

    • Byte mode: Register wird nicht inkrementiert / gut für polling
    • Sequential Mode: Register werden nach dem Lesen automatisch inkrementiert

    Bei I2C unterscheiden sich die Baudraten und für SPI gibt es noch neben der Baudrate zusätzlich die unterstützten Modi (0,0) und (1,1) (Clock Polarity, Clock Phase).

  • Moin!

    Ich wage mal zu widersprechen.

    Wie schon von Bernd666 angemerkt, kann man das deaktivieren.

    Laut Datenblatt, Seite 17,ist das Register IOCON default mit 0000 0000 belegt.

    Auf Seite 21 des Datenblattes steht:

    Zitat

    bit 3 HAEN: Hardware Address Enable bit (MCP23S17 only) (Note 1)
    1 = Enables the MCP23S17 address pins.
    0 = Disables the MCP23S17 address pins.

    Nur mal so...

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Guten Tag,

    Ich bin nun nach einigem Suchen auf die Code gestoßen, der jedoch nicht für µPython geschrieben ist.

    Dieser kann, das habe ich nun auch an einem 3b+ getestet mit den benötigten 4x MCP23S17 an einem BUS, mit einer CS Leitung umgehen.

    es grüßt euer
    Willy

  • Moin WillyR_aus_C,

    na dann, ab an's Umsetzen.

    Viel Erfolg!!

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

Jetzt mitmachen!

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