I2C Adressproblem

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • I2C Adressproblem

      Hallo,
      ich bin zur Zeit noch in der Theorie. Ich habe zwei Spektroskopmodule von Sparkfun (Spectral Sensor Breakout NIR & normal). Ich möchte sie beide
      an einem ATMEGA644 betreiben. Dummerweise haben beide die gleich I2C-Adresse.
      In der Praxis brauche ich die Module nicht zeitgleich, sondern nacheinander oder im Wechsel. Am Hardware-I2C-Port hängt schon eine Batterie an I2C-Geräten an (Expander, Display, Uhr, FRAM...).
      Die schnellste Lösungsvariante wäre, wenn möglich, einen zweiten Software I2C-Port aufzumachen, kostet allerdings 2 Pins am Controller, die eh schon sehr knapp sind.

      Zweite Überlegungsvariante wäre, 2 kleine ATTiny´s zu nehmen, jeweils ein Modul als Slave an einen der Tiny´s hängen und aus den Tiny´s wieder Slaves vom ATMega zu machen. Dadurch könnte
      ich vielleicht den Adresskonflikt umgehen.

      Oder dritte Variante, die Module wechselseitig als I2C ein- und aushängen. Müsste dann aber wahrscheinlich jedesmal wieder ein I2Cinit ausführen. Wäre wahrscheinllich etwas unschön, da jedesmal
      die gesamte Initialisierungsroutinen der anderen I2C-Geräte durchlaufen werden müsste.

      So, Frage, welche Variante könnte am Ehesten zielführend sein?

      Gruß!
      Benedikt
    • Ein Blick ins Datenblatt des TWI/I2C Bausteins sollte helfen. Meistens ist nur die obere Hälfte einer Byteadresse fest (linken 4 Bit), in der unteren Hälfte ist Bit 0 belegt mit R/W, also ob gelesen oder geschrieben werden soll. Die restlichen Bits sind Adressbits, könnten also darüber jeweils speziell adressiert werden.

      Nehmen wir als Beispiel ein EEprom der Bausteinreihe 24C04 oder 24C08 usw. Die obere Adresshälfte ist definiert mit A, sind die unteren 3 Adresspins auf L Pegel, hat dieser Baustein die Adresse A0 für write und A1 für read. Ein zweites EEprom gleichen Typs lässt sich über die Adresse A2 und A3 ansprechen, usw.
      So ähnlich wird es in anderen TWI bzw I2C Bausteinfamilien sein.

      Dieser Baustein hat zwei unterschiedliche Adressiermöglichkeiten. Eine über I2C mit 2 Adresspins, die andere über RS232 bzw Uart.
      Du könntest also jeweils einen der Bausteine auf andere Betriebsart ansprechen. So jedenfalls interpretiere ich den Blick ins Datenblatt mit seinen 45 Seiten. Betrieb von zweien solcher Bausteine sollte möglich sein.
    • Hallo Wolfgang,
      danke, dass Du in das Datenblatt geschaut hast. Also habe ich es richtig gesehen, dass auf der I2C-Seite nur eine Adresse bereitsteht.
      Leider sind in meinem Fall RS232 und UART durch einen GPS-Empfänger und UART-USB Converter blockiert.

      Das größere Spektrum an Adressmöglichkeiten kenne ich, wie Du es beschrieben hast, u. a. von Portexpandern.
    • laarb schrieb:

      Die schnellste Lösungsvariante wäre, wenn möglich, einen zweiten Software I2C-Port aufzumachen, kostet allerdings 2 Pins am Controller, die eh schon sehr knapp sind.
      Ich habe es noch nicht probiert, aber reicht für eine 2. I2C-Schnittstelle nicht ein neuer scl-pin bei einem gemeinsamen sda? Solange der scl auf high bleibt, gibt es keine Start-Kondition, die slaves achten nicht auf die zappelnden Daten.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Oh, oh,
      Du kommst jetzt schon mit der ganz hohen I2C-Schule :-). Nein, Spaß beiseite, ich habe es bislang so verteilt, dass mir noch ein Pin für BOD übrigbleibt (ich hoffe ich hatte die BOD Beiträge hier richtig verstanden).
      Aber im Prinzip stimmst Du der Variante 1 Hardware I2C u. 1 Software I2C zu?


      Gruß!
      Benedikt
    • Wenn du keine Adressvariante bei deinem doppelt vorhandenen slave einstellen kannst, dann sind 2 i2c-ports doch am elegantesten. Bei meiner Idee mit einem gemeinsamen pin, bin ich mir schon nicht mehr so sicher. Gemeinsamer scl wäre das bessere, wenn es überhaupt geht.
      Äh, was ist 'BOD'? Brownout detection?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Gut, dann versuche ich den Weg mit 2 I2C Ports. Ja mit BOD meinte ich Brown-Out-Detection. Wie ich genau ´drankomme weiss ich noch nicht, ich weiss im Augenblick nur, dass ich gut beraten bin, wenn
      eine fette Energiereserve vorhalte. Ich hatte hier im Forum einen Thread gefunden, der auf eine Schaltungsvariante verwies, die ziemlich hilfreich sein wird. Ziel ist ein Handgerät und es werden mehr oder weniger regelmäßig
      Daten auf eine SD-Card geschrieben. Da SD-Cards es nicht mögen, wenn man ihnen während des Schreibvorgangs den Stecker zieht, muss ich entsprechende Reserven vorhalten.

      Weißt Du zufällig, wieviele Pins ich dafür vorhalten muss? Kommt man mit einem Pin aus? Ich wollte diese Schaltung (1.) mikrocontroller.net/articles/S…chreibzugriffe_minimieren nehmen.

      Gruß!
      Benedikt
    • ich habe schon 3 PCA9555 im Einsatz. Ich weiss auch nicht, ob man an einem Multiplexer/Expander einen Software I2C hinbekommt.

      Das größte Ärgernis ist eigentlich, dass der Sensorhersteller für seine Sensoren nur eine I2C-Adresse vorhält und nicht davon ausgeht, dass
      2 unterschiedliche Sensoren seines Hauses parallel laufen sollen. In meinem Fall brauche ich den Normallichtsensor für eine Gültigkeitsprüfung, ob
      überhaupt ein Fall für den NIR-Sensor vorliegt.

      Gruß!
      Benedikt
    • Wenn du ein Handgerät hast, dann langt es evtl. direkt vor dem Schreiben auf die card, die Batteriespannung zu prüfen. Dazu langt ein Adc-pin, oder mit einem Komparator ein beliebiger IO-pin. Interessant wäre noch der Ein/Ausschalter, dass der nicht während dem Schreiben bedient wird, da muss dann noch Versorgungskapazität vorhanden sein, oder der Schalter mit einem Transistor kurzzeitig überbrückt werden.
      Bei dem einen thread hier war die Situation etwas anders, da ging es um's Retten von Daten bei überraschendem Stromausfall. Du brauchst durchgehend Energie beim Schreiben der card.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Eigentlich wollte ich das Schalten des Gerätes mit einem LTC2955 (Push-Button-Controller) machen. Nachdem ich jedoch den anderen Thread gelesen hatte, war ich eigentlich frohen Mutes, doch alternativ wieder
      einen Schiebeschalter einsetzen zu können. Ich wollte noch die Spannungsversorgung am Controller separat mit einem LM809 abfedern, der den Reset-Eingang vom Controller auf Low hält, bis die Spannung am Controller stabil ist, da ich leider einen Step-Up Converter einsetzen muss. Wenn während des Betriebes jemand das Gerät ausschaltet, dachte ich, dass es sich auch um eine "Art" überraschenden Stromausfall handelt und ich die
      besagte Pufferschaltung im EEPROM Kapitel anwenden kann. Ich dachte, wenn ich Controller u. SD-Card an dem Reservepuffer hängen habe, würde es reichen, um im Störfall noch wenigstens den Schreibvorgang auf die SD sofort
      zu beenden. Ich bin zunächst von einem Puffer von 4 - 5 Farad ausgegangen.

      Gruß!
      Benedikt
    • Dann hab' ich was falsch verstanden. Das Ausschalten ist für das Programm immer überraschend, es kommt halt drauf an, was dadurch passiert. Wenn du temporäre Daten hast, die du beim Neustart brauchst, musst du die sichern, wie im thread beschrieben. Wenn du einen Programmteil hast, der nicht überraschend unterbrochen werden darf, musst du die Versorgung für diese Zeit sicherstellen. Davon bin ich jetzt ausgegangen.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • laarb schrieb:

      ich habe schon 3 PCA9555 im Einsatz. Ich weiss auch nicht, ob man an einem Multiplexer/Expander einen Software I2C hinbekommt.
      Verwechsel nicht I/O-Multiplexer mit Busmultiplexer.PCA9555 sind I/O-Multiplexer.
      Ich hatte Bus-Multiplexer vorgeschlagen.Die sind genau dafür da I2C-Adresskonflikte zu beheben, da sie den I2c-Bus multiplexen, damit man mehrere Devices mit gleicher I2c-Adresse am µC-I2C-Bus betreiben kann. Einfach mal in das Datenblatt schauen. Sehr schön geeignet um I2C-Adressbänke zu realisieren.
    • Wenn du dem Lm809 verwendest, darf der meiner Meinung nach nicht mit reset vom Kontroller verbunden werden, sondern mit einem intx-Eingang, damit man brownout erkennt. Im Programm wartet man bei Programmstart, bis dieser pin ein 'power good' signalisiert, läd seine beim letzten Ausschalten gesicherten Daten aus eeprom/card und richtet dann mit diesem pin einen interrupt ein, der bei 'power bad' die Daten speichern würde.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Aus dem Datenblatt des LM809 farnell.com/datasheets/1777530.pdf habe ich entnommen, dass der LM809 direkt an den Reset-Pin vom µC kommt.
      Vielleicht habe ich ein Verständnisproblem.
      Also ich habe beim Einschalten das Problem, dass erst der Step-Up-Regler anlaufen muss. Solange er noch nicht volle Suppe liefert, soll der µC erst gar nicht hochfahren. Kann es sein, dass ich für die
      Brown-Out Situation einen zweiten LM809 brauche, der dann tatsächlich, wie Du es beschrieben hast an einem Interrupt-Pin hängt, um die Stromausfallsituation abzufangen?
    • oscar schrieb:

      laarb schrieb:

      ich habe schon 3 PCA9555 im Einsatz. Ich weiss auch nicht, ob man an einem Multiplexer/Expander einen Software I2C hinbekommt.
      Verwechsel nicht I/O-Multiplexer mit Busmultiplexer.PCA9555 sind I/O-Multiplexer.Ich hatte Bus-Multiplexer vorgeschlagen.Die sind genau dafür da I2C-Adresskonflikte zu beheben, da sie den I2c-Bus multiplexen, damit man mehrere Devices mit gleicher I2c-Adresse am µC-I2C-Bus betreiben kann. Einfach mal in das Datenblatt schauen. Sehr schön geeignet um I2C-Adressbänke zu realisieren.

      Danke für den Hinweis. Habe gerade das Datenblatt vom PCA9546 überflogen. Cool!!

      Gruß!
      Benedikt
    • oscar schrieb:

      laarb schrieb:

      Also ich habe beim Einschalten das Problem, dass erst der Step-Up-Regler anlaufen muss. Solange er noch nicht volle Suppe liefert, soll der µC erst gar nicht hochfahren.
      Das kann auch der Atmega-interne Brown-out-Detektor.
      Das hatte ich befürchtet :-)..., nein,ich hatte beim ATMega644 gelesen, dass er so etwas mitbringt. Ich habe jedoch keinen Dunst, wie ich es in BASCOM umsetzen soll.