Hallo, Ich habe ein projekt, bei dem ich je nach anwendungsfall 1 bis 8 mcp23027 port expander an mein mikrocontroller über i2c angeschlossen hab. diese werden vor Inbetriebnahme per steckverbindung angeschlossen. nun möchte ich ein weiteres modul mit pca9505 anschließen. Das modul hat dann leider den gleichen Adressraum. Gibt es eine Möglichkeit auszulesen, welcher ic typ da auf der Adresse horcht? Links zur info würden mir reichen. beste Grüße Jörg
>Ein I2C Portmultiplexer würde ja schon reichen.
Oder Software I2C oder ein uC mit mehr als einmal I2C.
Sorry, blöde handytastatur... meinte MCP23017. 16bit Port expander für i2c. der pca9605 ist ein 40bit port expander. Diese muss ich dann software technisch von einander unterscheiden können.
>Diese muss ich dann software >technisch von einander unterscheiden können. Das geht aber nur schwer. Ich könnte mir vorstellen da in Register zu schreiben die der eine nicht hat und die dann zurückzulesen. Wenn Müll zurückkommt wars der andere. Aber das ist schon echt weit hergeholt.
Bei einem einen PIN offen lassen, beim anderen auf High legen. Danach abfragen. So kann man mehrere "Hardwarecodieren"
Hallo, Hmm wenn du die io Ports damit meinst, dann geht das leider nicht, da alle verwendet werden. Mein Problem bei der Sache ist ja, ich weiss nicht welcher ic nun auf der adresse 0x20 auf dem bus hängt. Bis auf die adresse unterscheiden sich beide ic ja in der kommunikation. Daher muss ich 2 klassen schreiben und je nach ic für die entsprechende adresse diese instanzieren. Nur beim start der anwendung scanne ich den adressbereich 0x20 bis 0x27. Wenn eine antwort kommt, dann ist die adresse belegt. Nun hatte ich gehofft, es gibt eine eindeutige hersteller und ic-typ id, die man mit einem standard kommando abfragrn kann. Scheint aber nicht der fall zu sein. Ich muss dann wohl testen, was passiert wenn ich ein nicht vorhandenes register des mcp23017 abfrage und ob das ergebnis dann von einem vorhanden register im pca9605 unterscheidbar ist. Nicht schön, aber vielleicht der einzig gangbare weg. Blöde das die port-expander ics alle mit 0x20 starten. Jedenfalls bei denen, die ich gefunden habe... beste grüße Jörg
du hast aber sicher an den Expandern unteschiedlichen Sächelchen angeschlossen. Da sind wahrscheinlich bei jedem angeschlossenen Gerät auch ein paar Pins dabei, welche einen bestimmten, definierten Status haben, z.B. weil sie einen Pullup oder Pulldown haben, oder weil die daran angeschlossene Schaltung bestimmte Eigenschaften hat. Da muss es doch möglich sein, durch Einlesen der Eingänge eine Entscheidung treffen zu können, was angeschlossen ist, oder? Ansonsten musst du halt an deine angeschlossenen Geräte ein paar Leitungen definiert hinziehen. Weil nur weil man sie Hardwarecodiert, heißt das nicht, dass sie nicht als Port nutzbar sind
Man könnte mit einem PCF8574A den Adreßraum erweitern. Dessen Ausgänge gehen auf A0 der 8 MCP23017 und einer wird selektiert. Die anderen 7 sind dann auf einer nicht genutzten Adresse. Man hat von den 8 möglichen Adressen also nur 2 verbraucht.
Jörg schrieb: > Nun hatte ich gehofft, es gibt eine eindeutige hersteller und ic-typ id, > die man mit einem standard kommando abfragrn kann. Warum sollte es die geben? Philips hat bei der Entwicklung des 12C-Bus wahrscheinlich nie damit gerechnet, dass mehr als 8 gleiche Geräte am Bus hängen werden, deshalb nur die 3 Adressleitungen zur Unterscheidung. Das da mehrere Hersteller die gleiche interne Adresse verwenden, ist natürlich blöde, aber mit 4 Bits sind ja auch nur 16 verschiedene Adressen möglich. Abhilfe gibt es nur durch I2C-Multiplexer oder eine zweite I2C-Schnittstelle, aber das wurde ja schon gesagt.
Ach immer die ganzen ics... PCA9505 und MCP23017 Wie gesagt, mein Hauptmodul besteht aus einem Microkontroller, einer Versorgungsspannungseinheit, Funkmodul und ein wenig messelektronik. Dieses hauptmodul kann dann durch externe module erweitert werden, bei denen im Moment 16 vollkommen gleich aufgebaute Kanäle integriert sind (im Grunde Ein-/AusSchalter). Nun las ich vom PCA9505 und dachte mir, damit kann ich schnell die Ausgangszahl erweitern. Da ich aber gerne abwärtskompatibel ausgelegt bin und die externen Module je nach Anwendungsfall (ändert sich bei jeder nutzung) an unterschiedlichen hauptmodulen verwende, kann ich leider nicht über den weg des auslesens der beschaltung der ics gehen. D.h. beim start des hauptmoduls suche ich die angeschlossenen module und - im Moment - weiss ich dann die anzahl der ports, die ich über funk an den Master sende. ... Ja ich kann kir vorstellen, dass bei der entwicklung nicht daran gedacht wurde, dass am i2c mehr als 127 Geräte hängen. Auxh ist man sicherlich davon ausgegangen, im embedded fall immer die hardware vorher zu kennen. Aber ware es nicht schön, wenn ich per stecker i2c module anschliesse und dann die id des moduls, sagen wir mal id5675 = temp sensor, auslese und dynamisch entsprechenden code nutze. Okay, ich glaube das ist im embedded bereich noch nicht der fall. Woanders aber meines Erachtens eigentlich Standard (USB...)
Wie wäre es mit dem 1-wire DS2408 8 Port GPIO Expander, der hat eine Seriennummer an Board, die man auslesen kann. Man kann mehrere an einem Bus verwenden. Und mit 1-wire hast Du dann wieder einen Port frei :-)
bau zusätzlich zum PCA9505 einen LM75 auf jedes Modul (mit gleicher Adress-Kodierung wie der PCA) such beim init zuerst per I2C nach dem LM75 und falls es gefunden wird, handelt es sich um die 40 Kanal-Version Gruss Uwe
:
Bearbeitet durch User
Nur so eine Idee ... Wenn du lesend auf ein Register außerhalb der MCP23017 Register ( 00-1A ) zugreifst müstest du einen Fehler bekommen. Ergo hast du einen PCA9505 angeschlossen.
Jörg schrieb: > Woanders aber meines Erachtens > eigentlich Standard (USB...) I2C ist aber deutlich älter als USB. Das ist einer der wenigen Dinge, die mir an USB gefallen (neben dem Speed natürlich). Das sich Geräte beim Host identifizieren, wer sie sind. Abgesehen davon (und dem Speed natürlich) ist mir eine normale RS232 trotzdem 100 mal lieber. Solange USB gut funktioniert, ist alles paletti. Aber wehe die Automatik versagt oder der Treiber hat eine Macke. Dann steht man im Regen. So wie bei allen Automatiken, wenn man keine Möglichkeit hat händisch einzugreifen oder der reine Vorgang des Eingreifens schon Expertenwissen benötigt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.