Hallo an alle, Bin neu hier im Forum und hoffe daher, dieser Beitrag ist im richtigen Thema gelandet. Kenn mich noch nicht so aus. Nun zu meiner Frage: Ich würde gerne mit einem Raspberry Pi per I2C diverse Transistormodule ansteuern. Die IO-Module würde ich dabei selbst entwickeln mit einem MCP23017 oder ähnlich. Das Problem ist nun aber die Adressierung der Controller. Der Standard I2C-Bus wird laut Wikipedia spezifiziert mit 7 Adressbits mit denen insgesamt 112 Slaves adressiert werden können (restlichen 16 Adressen für Sonderzwecke reserviert). Der MCP23017 und auch alle anderen I2C Controller die ich gefunden habe haben aber nur 3 Pins für die Adressierung. Die 7 Slaves welche damit angesteuert werden können, sind für mein Projekt aber leider zu wenig. Gibt es eine Möglichkeit, die restlichen Adressbits zu verwenden? Oder gibt es andere Controller mit 7 Adresspins? Bin um jede Hilfe dankbar... Viele Grüsse, Patrick
Patrick G. schrieb: > Gibt es eine Möglichkeit, die restlichen Adressbits zu verwenden? Die restliche Adressbits musst du sogar verwenden, wenn du mit dem MCP23017 sprechen möchtest. Im Datenblatt FIGURE 3-4 bzw. 3-6 siehst du, dass die anderen vier Bits der Adresse fest auf 0b0100 liegen.
p.s. Warum verwendest du nicht den MCP23S17. Damit hättest du mehr Freiheit, weil du die über \CS auseinanderfädeln kannst.
Manche LED-Treiber mit I2C verstehen über 100 Adressen. Allerdings wird mit so vielen ICs die kapazitive Belastung u.U. zu hoch. Die haben aber auch 16 oder mehr Ausgänge pro Baustein, z.B. PCA9685, 6 Adress-Pins, 16 Push-Pull Ausgänge PCA9955B, 3 Adress-Pins aber 125 Adressen, 16 Ausgänge IS31FL3265A, 2 Adress-Pins aber 16 Adressen, 18 Ausgänge Die letzten beiden haben eigentlich nur Ausgänge, aber sie können messen, ob ein Ausgang offen oder kurzgeschlossen ist. Die Fehlererkennung kann man als Eingang missbrauchen. Es gibt auch extreme I/O-Expander, der CY8C9560A hat 6 bis 7 Adress-Pins, mehr Push-Pull I/O als ich zählen mag (ca. 60) und noch ein paar Gimmicks. Und Digikey und Mouser haben den auf Lager. Etwas kleiner sind die CY8C9540A und CY8C9520A. Oder noch ein ganz normaler: PCA9506 mit nur 3 Adress-Pins, aber 40 I/O. Edit: PCA9554 und PCA9554A haben auch nur 3 Adress-Pins, 8 Adressen und 8 I/O, aber der feste Teil der Adresse ist unterschiedlich. Also kann man 16 Bausteine anschließen.
:
Bearbeitet durch User
Besten Dank für die schnellen Antworten. Das mit dem Multiplexer ist ein guter Tipp, werde ich sicher mal anschauen. @Wolfgang: Der MCP23S17 verwendet den SPI-Bus, da ich aber den I2C nehmen möchte, habe ich diesen Controller nicht weiter angeschaut. @Bauform: Gute Idee mit dem LED-Treiber PCA9685. Der CY8C9520A ist aber im Moment glaub der beste Kandidat für meine Zwecke. Nochmal Danke für die schnelle Hilfe und noch einen schönen Abend.
Hallo, ich nehme gerne einen ATtiny als I2c Slave. Da kann ich die Adressen frei wählen. Gruß Carsten
Hast du erwägt, einfache Schieberegister zu verwenden? Das könnte unter Umständen erheblich billiger werden. Ist dann allerdings eher SPI als I2C.
Patrick G. schrieb: > @Wolfgang: Der MCP23S17 verwendet den SPI-Bus, da ich aber den I2C > nehmen möchte, habe ich diesen Controller nicht weiter angeschaut Wenn es dein fester Wunsch ist, quäle dich mit der beschränkten Adressauswahl der I2C Variante - jeder wie er möchte ;-) Mit SPI hättest du eine Sorge weniger.
Bei solchen Überlegungen klingeln bei mir immer gleich alle Alarmglocken: Wie lange sollen denn die I2C Leitungen werden? Was soll geschaltet werden? Alles im Hinblick auf eventuell auftretende Störungen, die sich bei I2C kaum in den Griff kriegen lassen. Und bei ... Stefan F. schrieb: > Hast du erwägt, einfache Schieberegister zu verwenden? Das könnte unter > Umständen erheblich billiger werden. ... Schieberegister desaströs enden können. Bitte setzt ihm keinen Floh ins Ohr ;)
Beitrag #7267515 wurde vom Autor gelöscht.
Wo I²C geht, geht meistens auch SPI. Beide sind für kurze Leitungen gedacht. Wenn die Leitungen länger als 20cm sind muss man sich sowieso Gedanken um die Leitungsanpassung und Filterung von Störungen machen.
Steve van de Grens schrieb: > Wo I²C geht, geht meistens auch SPI. Nö. SPI benutzt viel höhere Frequenzen und ist daher deutlich störempfindlicher. Wir hatten damit großen Ärger, auch nur über eine Backplane auf eine andere Platine zu gehen. Da mußte erstmal mit RC-Gliedern und Schmitt-Trigger umständlich entstört werden. Z.B. der 74HC595 von NXP kann bis 108MHz. Dagegen ist der PCF8574/A mit max 100kHz quasi um den Faktor 1000 störfester.
Peter D. schrieb: > Steve van de Grens schrieb: >> Wo I²C geht, geht meistens auch SPI. > > Nö. > SPI benutzt viel höhere Frequenzen und ist daher deutlich > störempfindlicher. Nicht nur das. Die I2C-Spec schreibt auch interne Filter an SCL und SDA vor. Beim PCA9506 steht z.B. im Datenblatt
1 | Input filters on the SDA and SCL inputs |
2 | suppress noise spikes less than 50 ns. |
Die neueren Chips können noch mehr:
1 | Adapts its SDAH and SCLH input filters according to |
2 | the spike suppression requirement in Hs-mode. |
Da ich flexibel bleiben möchte und es zwei unterschiedliche Platinen als IO-Module geben wird, sehe ich beim I2C einfach mehr Vorteile als beim SPI. Die Geschwindigkeit der Kommunikation ist nicht relevant, da nur Relais geschaltet und irgendwelche Endschalter eingelesen werden. Trotzdem behalte ich mir den Tipp mit dem SPI mit Schieberegistern für den CS-Pin im Hinterkopf ;) Andi schrieb: > Bei solchen Überlegungen klingeln bei mir immer gleich alle > Alarmglocken: > Wie lange sollen denn die I2C Leitungen werden? > Was soll geschaltet werden? Die Leitungen sind max 1m lang, jedoch liegen die im gleichen Kabelkanal wie die 230V Leitungen. Müsste man da geschirmte Kabel nehmen? Oder die Taktfrequenz vom I2C drosseln? Geschaltet werden sollen einfache Relais, z.B. um kleine Wasserpumpen anzusteuern. Also nicht zeitkritisch.
Andi schrieb: > Wie lange sollen denn die I2C Leitungen werden? > Bitte setzt ihm keinen Floh ins Ohr ;) Na dann... also doch einen uC als I/O-Erweiterung. Und UART statt I2C und den ultimativen RS-422 Treiber LTC2863-2 :) Aber im Ernst: heutzutage, mit ±1% internem Takt und internem Flash, ist das eine echte Alternative. Und viel flexibler.
:
Bearbeitet durch User
Peter D. schrieb: > SPI benutzt viel höhere Frequenzen Ich dachte, das der Programmierer die Frequenz beliebig langsam festlegt. Bauform B. schrieb: > Die I2C-Spec schreibt auch interne Filter an SCL und SDA vor. Macht Sinn, deswegen schreib ich auch Steve van de Grens schrieb: > Wenn die Leitungen länger als 20cm sind muss man sich sowieso > Gedanken um die Leitungsanpassung und Filterung von Störungen machen. Patrick G. schrieb: > Die Leitungen sind max 1m lang, jedoch liegen die im gleichen Kabelkanal > wie die 230V Leitungen. Müsste man da geschirmte Kabel nehmen? Muss nicht zwingend sein, hilft aber bestimmt wenn es nicht klappt. Noch sicherer ist eine differentielle Übertragung wie bei RS422. Aber bei 1m muss man sich schon sehr anstrengen, das Signal nennenswert zu stören. Bei dir reicht wahrscheinlich ein 51Ω Serienwiderstand am der Signalquelle (zum Unterdrücken von Reflexionen im Kabel), sowie ein R/C Tiefpass (100Ω,1nF) am anderen Ende des Kabels zum Unterdrücken von Hochfrequenten Störungen. > Oder die Taktfrequenz vom I2C drosseln? Das würde nur in Kombination mit Filtern helfen. Allerdings willst du wohl kaum Frequenzen oberhalb von 50Hz weg filtern und mit der Übertragungsrate so extrem runter gehen.
:
Bearbeitet durch User
Man muss die bei SPI möglichen höheren Taktraten ja nicht ausnutzen, beide Busse, I2C und SPI kann man prinzipiell beliebig langsam betreiben. Falls ein Controller nur I2C unterstützt, kann man SPI auch in Software nachbauen. Das Protokoll ist auch nicht wesentlich komplexer. Bernd
Bernd schrieb: > Man muss die bei SPI möglichen höheren Taktraten ja nicht ausnutzen Das hilft nur, wenn man auch Filter einbaut. Die SPI-Chips reagieren ja immer gleich schnell auf Störungen, egal, wie niedrig die Taktfrequenz ist.
Bauform B. schrieb: > Das hilft nur, wenn man auch Filter einbaut. Die SPI-Chips reagieren ja > immer gleich schnell auf Störungen, egal, wie niedrig die Taktfrequenz > ist. Filter darf man gerne einbauen, z.B. TP mit Schmitt-Trigger. Als Vorteil gegenüber I2C hat man es bei SPI mit symmetrisch getriebene, solide Pegel (Push-Pull an Stelle von Pull-Up) zu tun und muss sich nicht mit bidirektionalen Treibern rumschlagen. Patrick G. schrieb: > Die Leitungen sind max 1m lang, jedoch liegen die im gleichen Kabelkanal > wie die 230V Leitungen. Na hoffentlich werden dabei die Vorschriften bzgl. der Isolation verschiedener Spannungsbereich nach IEC 60449 und VDE 0100-520 eingehalten.
Steve van de Grens schrieb: > Bei dir reicht wahrscheinlich ein 51Ω Serienwiderstand am der > Signalquelle (zum Unterdrücken von Reflexionen im Kabel), sowie ein R/C > Tiefpass (100Ω,1nF) am anderen Ende des Kabels zum Unterdrücken von > Hochfrequenten Störungen. Ich habe vergessen zu erwähnen, dass dieser Absatz für SPI gilt, nicht für I²C. Bei I²C sind bereits Filter in die Chips integriert (schrieb schon jemand anderes).
Peter D. schrieb: > SPI benutzt viel höhere Frequenzen und ist daher deutlich > störempfindlicher. Das ist doch Quatsch. SPI KANN zwar deutlich höhere Frequenzen verwenden, muss es aber NICHT Und wann man das dann auch nicht tut, sondern im Bereich "normaler" I2C-Komunikation bis maximal 400kHz bleibt, sieht das mit den Signalen sogar deutlich besser aus, weil beide Flanken aktiv getrieben werden. Das bissel Klingeln an den Flanken bekommt man leicht weg. Insbesondere deshalb, weil sie AC-mäßig halt in etwa gleich sind, im Unterschied zu I2C. Blöd ist halt nur die höhere Zahl von Signalen. Das ist der einzige Nachteil. Und natürlich kann man mit entsprechenden Peers auch noch diesen Nachteil veringern oder gar komplett loswerden, durch Daisy-Chaining. Handelt sich damit allerdings das Risiko des Totalausfalls beim Bruch einer einzelnen Strippe ein. So what: auch bei I2C kann ein einzelner toter Peer den gesamten Bus totlegen oder auch ein Masse-Schluss auf einer der beiden Signale.
Patrick G. schrieb: > Der MCP23017 und auch alle anderen I2C Controller die ich gefunden habe > haben aber nur 3 Pins für die Adressierung. Die 7 Slaves welche damit > angesteuert werden können, sind für mein Projekt aber leider zu wenig. > Gibt es eine Möglichkeit, die restlichen Adressbits zu verwenden? Oder > gibt es andere Controller mit 7 Adresspins? 7 IO-Expander mit 16 Bit sind zu wenig? Du brauchst mehr als 112 IOs um Taster einzulesen, Pumpen zu schalten usw.? Mich dünkt man sollte das Konzept vielleicht noch mal überdenken. Das klingt nämlich nach einer großen Anlage. Steve van de Grens schrieb: > Peter D. schrieb: >> SPI benutzt viel höhere Frequenzen > > Ich dachte, das der Programmierer die Frequenz beliebig langsam > festlegt. Macht er auch aber so spontan kenne ich kein SPI-Projekt in meinem Umfeld, dass weniger als 1 MHz Taktrate verwendet, ich kenne aber jede Menge I²C-Projekte, die lediglich mit 100 kHz laufen. Und ich denke, darauf wollte Peter hinaus. Klar kann man auch SPI mit 100 kHz laufen lassen aber auch meiner Erfahrung nach ist das dann doch recht ungewöhnlich für SPI.
c-hater schrieb: > Das ist doch Quatsch. SPI KANN zwar deutlich höhere Frequenzen > verwenden, muss es aber NICHT Das ist Quatsch, die Störempfindlichkeit hängt ausschließlich vom Empfänger ab und nicht von der Datenrate. Wenn der Empfänger noch auf 100MHz reagiert, kannst Du selbst mit 1Hz senden und wirst fehlerhafte Flanken feststellen. Deshalb wird bei der UART ein Trick angewandt. Der Eingang wird dreifach abgetastet, abhängig von der eingestellten Baudrate. Nur dadurch läßt sich die Störempfindlichkeit herabsetzen. Bei I2C werden feste Filter in den Empfänger integriert, die aber weniger wirksam sind, wenn der IC auch >100kHz kann.
Patrick G. schrieb: > Die Leitungen sind max 1m lang, jedoch liegen die im gleichen Kabelkanal > wie die 230V Leitungen. Müsste man da geschirmte Kabel nehmen? Am einfachsten wäre dieses spezielle EIB-Kabel, damit spart man einen zweigeteilten Kabelkanal mit Trennwand. Ein Schirm schadet nur, wenn man damit eine Erdschleife baut. > Oder die Taktfrequenz vom I2C drosseln? Das hilft nicht und ist bei 1m Kabel auch nicht nötig. Bei langen Kabeln versucht man, die Pull-Up niederohmiger zu machen und erst wenn das nicht reicht, muss die Taktfrequenz gedrosselt werden.
Bauform B. schrieb: > Ein Schirm schadet nur, wenn man damit eine Erdschleife baut. Das soll man ja auch nicht. Der Schirm soll die Gehäuse fortsetzen und nicht für irgendwelche Signale dienen. Notfalls hilft, ihn nur einseitig aufzulegen, kommt halt drauf an, wie das Gesamtkonzept aussieht.
Ich würde da ein differenzielles Signal vorschlagen. RS485 zwischen zwei Controllern. B steuert dann in der Nähe gelegene Treiber ICs an.
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.