Slaves erkennen über i2p bzw twi und deren Anzahl

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Slaves erkennen über i2p bzw twi und deren Anzahl

      Hallo und erstenmal danke für die Aufnahme. Ich bin gerade dabei bascom zu lernen bezüglich Elektronik-Basteln und Modellbau.

      Habe bisher sehr viel gelesen und alles zum programmieren habe ich mir auch soweit beschaffen. Nur noch nichts zusammengesteckt, programmiert, aufgebrannt und ausprobiert bisher.

      Ich weiß , ich sollte erstmal alles soweit erlernen. Trotzdem lässt mich die Frage nicht in ruhe. Für ein Projekt dass ich aktuell plane, frage ich mich ob es mit i2p bzw twi Bus möglich ist, dass der Master (grob beschrieben: Zentrales Modul mit einigen Tasten zum Bedienen) erkennt wenn ein Slave (Modul mit LEDs) am Bus über einen speziellen Stecker verbunden wird und der Master dabei erkennt wieviele Slaves gerade an ihm dran sind?

      Des weiteren stellt sich mir fie Frage:
      kann der Master erkennen in welcher Reihenfolge die Slaves angesteckt sind? Master soll nur einen Anschluss haben. An diesem käme das erste Modul, dann an dem ersten Modul das zweite usw...

      Zum Beispiel ob die Module mit den Adressen 1, 2, 3 in dieser Reihenfolge am Master sind oder in dieser Reihenfolge 2, 1, 3?
      Es geht darum, dass die LEDs zb am ersten Modul (Slave) mit 10% Helligkeit gedimmt sind und am letzten Modul 100% Helligkeit haben. Und die Module da zwischen jeweils den Übergang von 10-100% darstellen. Stecke ich jetzt da zwischen weitere Module oder hinten dran, sollen die Module automatisch so vom Master gedimmt werden, dass es eine lineare Helligkeits-Einstellung der Module vom vorderen bis zum hintersten Modul ermöglicht.

      Ich hoffe ich konnte die Frage ausführlich genug stellen.

      Leider habe hierzu keine Infos im Forum gefunden, die zu meinem Thema passen. Bis jetzt fand ich nur Themen wie der Master senden und empfangen soll oder der Slave etwas tun soll. Aber erkennen in welcher Reihenfolge die Slaves sind und welche Anzahl an Slaves sich gerade am Master befinden habe ich nirgends was gefunden.

      Ich danke im Voraus und hoffe, dass es irgendwie möglich ist.

      Schöne Grüße,
      Jan
    • Hallo Jan,
      mit einem kleinen BASCOM-Programm, das als I2C-Scanner bezeichnet wird, kannst Du den Master herausfinden lassen, welche - und damit auch wieviele - I2C-Adressen mit einem I2C-Slave am Bus vorhanden sind. Eine Reihenfolge kann weder zeitlich noch ortsbezogen ermittelt werden; das musst Du selbst machen. Du kannst dir zu einem Zeitpunkt das Scanergebnis speichern und nach einer Minute kannst Du einen neuen Scan durchführen. Jeder I2C-Slave muss eine eindeutige Adresse haben. Bau Dir einmal einen Testaufbau mit 3 I2C-Slaves und einem BASCOM-I2C-Scanner - dann bekommst Du schnell ein Gefühl dafür.
      WO an I2C-Bus ein Slave ist, ist dem Master egal. Da musst Du Dir selbst etwas überlegen.
    • I2C hat was mit Chips zu tun. Sind also Bausteine mit einer besonderen Adressierungsart. I2C oder TWI genannt.
      Schau dir mal die Grundlagen dazu an. rn-wissen.de/wiki/index.php/I2C_Chip-%C3%9Cbersicht

      Ferner schau mal ind die Dokumentationen eines Bausteines rein.
      Hier zum Beispiel ein PCF8474. nxp.com/docs/en/data-sheet/PCF8574_PCF8574A.pdf

      Du erkennst an der Pinbelegung Anschlüsse die sich A0, A1, A2 nennen.
      Das bedeutet, wenn alle diese 3 Pins 0 Potential haben, gilt die Baustein-Grundadresse des Chips.
      Es können somit 7 Chips der gleichen Art (Bezeichnung z.B PCF8574) gesondert adressiert werden.

      Falls Du diese Grundlagen noch nicht kanntest, hoffte ich dazu mehr Info zu liefern.
    • stefanhamburg wrote:

      WO an I2C-Bus ein Slave ist, ist dem Master egal.
      Und das wird ein Problem wenn mitten drin einer gesteckt wird.
      Eine Möglichkeit wäre wenn jeder Slave zum Master der darauf folgenden würde. Das führt jedoch zu erheblichen Laufzeiten wenn da viele zusammen kommen.
      Auch könnte eine weitere Leitung mit durchgeschliffen werden. Daran könnte ein Slave erkennen ob einer hinter ihm hinzu gekommen ist bzw der Master ob einer da ist.
    • Falls Du diese Grundlagen noch nicht kanntest, hoffte ich dazu mehr Info zu liefern.
      Danke bitlogger, das muss ich überflogen haben. Aber 8 Stück sind schonmal eine Menge. Falls ich erweitern möchte müsste ich also einen zweiten pin nehmen um weitere 8 Stück PCF8574 über i2p steuern möchte?


      Auch könnte eine weitere Leitung mit durchgeschliffen werden

      @Plito25: Genau daran habe ich auch gedacht. Ich habe im meinen Notizen ein oAr Gedankengänge geschrieben wie sowas realisiert erden könnte.


      Was für Stecker sollen denn benutzt werden? Könnte ein eingesteckter Stecker außer der I2C-Verbindung noch zwei Kontakte der Buchse kurzschließen?
      @stefanhambueg: Stecker ist noch nicht ausgesucht. Kann anslo iwas mehrpoliges sein. Vieleicht 8pol. Als 2,54mm Raster oder so.

      Hier meine Notizen:
      Files
    • Schade, Du hast es anscheinend noch nicht richtig verstanden. Deshalb nochmal, diese Chips sind eindeutig über Ihre Hardware-Adresse zugewiesen, zu zu weisen. Der Master sucht nicht nach Chips, sondern der Master adressiert diese Chips.
      Es sind Chips entweder mit ihrer Chip-typischen Grundadresse zu adressieren, oder bis zu 7 weitere gleiche Chips über die zugehörigen Adresspins zusätzlich zu addressieren.

      Soweit mal die Grundlagen der Hardware. Softwaretechnisch läuft es in gewissem Sinne ab. Ein über die Hardwareadresse angesprochener Chip liefert ja sinngemäß Daten und zusätzlich ein ACK oder Nack mit. Je nachdem ob weitere Daten zu liefern sind oder nicht.

      Es müssen also keine zusätzlichen Adern zwecks Adressierung verlegt, oder berücksichtigt werden. Ein Chip muss nur eindeutig per Adresspins am Chip (sofern vorhanden) adressiert werden, ist somit über I2C/Twi eindeutig erreichbar.
      Hilfreich für die Programmentwicklung, -umsetzung werden dann Aliases etc sein, die (gedanklich) helfen den Überblick über das ansprechen der Module zu behalten.
      Mitch wird dir dazu dienliche Tipps liefern können, das Programmtechnisch gut zu lösen. ;)
      (Mitch, okay du sagtest 8 Chips sind adressierbar. Klar, ich vergaß nur vor meiner 7 zu schreiben zusätzliche 7) ;)

      Sinngemäß mal gedankliche Vorarbeit. Modul1 bekommt die Chip-Grundadresse. Modul2 bekommt Chipgrundadresse plus Adresswertigkeit von Pin A1. Usw. Somit sind 8 Module gleichen Chiptypes so zu verwalten. Erst wenn es mehr als 8 Module gleichen Chiptypes werden müssten, werden zusätzliche "Adressleitungen" benötigt.
    • Soweit die Grundlagen zu I2C/TWI.
      Das dürfte dir nicht viel helfen, weil Du im Eingangspost von LED (irgendwas) gesprochen hast, das LED's unterschiedlich dimmen können sollte.
      Um darauf näher eigehen zu können, müsstest Du uns nähere Infos zu den Modulen liefern, die entweder schon fertig (Hardware) vorhanden sind, oder gekauft werden sollen.
      Oder, falls solche Module in Hard- und Software zu erstellen wären, werden entsprechende Informationen benötigt.

      (Die von mir gelieferten Infos beziehen sich ausschließlich auf die I2C Chips, die am Markt verfügbar sind. Damit ist eine Auswahl eines geeigenten Chips möglich, bzw bietet Infomöglichkeiten über diesen Chip.) Ich hatte einfach nur als Beispiel den Chip PCF8574 genannt, um die zusätzliche Chipadressierung per Adresspins zu verdeutlichen.

      Zur gezielteren Hilfe deines Grundpostes werden genauere Infos zu den Modulen benötigt.
    • bitlogger wrote:

      Zur gezielteren Hilfe deines Grundpostes werden genauere Infos zu den Modulen benötigt.
      Genau, dem kann ich mich anschließen.

      Mir stellen sich mehrere Fragen bei deinem Projekt.
      • Wie viele LED's sollen den je Modul gedimmt werden?
      • Hast du da einen bestimmten I2C-Baustein (Typ) im Sinne oder eben eine fertige Baugruppe?
      • Ist es ein Muss, dass die Module nacheinander in Anschluss-Reihenfolge gedimmt werden und warum?
      • Muss es unbedingt I2C sein?
      Grundsätzlich ist es ja so, dass I2C-Bausteine (integrierte Schaltungen, bzw. IC's) vom Hersteller eine bestimmte Basis-Adresse eingeprägt werden, die man als Benutzer nicht ändern kann. Viele Herstelle geben aber die Möglichkeit, ein oder mehrere Bits der Adresse herauszuführen, damit der Anwender mehrere Bausteine am Bus betreiben kann.

      Diese Bausteine sind für sich gesehen ziemlich dumm. Denen kann man i.d.R. keine Adresse per Bus-Ansteuerung zuweisen (vielleicht gibts ein paar).
      Sie geben Daten aus oder geben welche zurück. Manche kann man konfigurieren (aber keine Adresse) und können Daten ausgeben oder zurückgeben wie der PCF8574.
      Dieser im speziellen ist aber kein PWM-Baustein. Dafür wurde der nicht gebaut.

      Da die Adressen der Bausteine vom Hersteller vorgegeben sind, spielt die Anschlussreihenfolge der Bausteine am Bus keine Rolle. Die IC's werden anhand ihrer Hardware-Adresse identifiziert.

      Bausteine während des Betriebs anzustecken oder abzustecken kann zu Problemen führen. Z.B. würd ein Baustein gerade gelesen, der mitten in der Kommunikation angezogen wird.
      Das Bestätigungsbit bleibt aus und der Bus steht. Es können auch Übertragungsfehler bei Ausgaben passieren, wenn etwas während der Kommunikation angesteckt wird. Dies kann zu falschen Daten beim Slave führen. Es gibt ja keine Checksumme oder Fehlerkorrektur.

      Es ist aber trotzdem nicht ganz aussichtslos, dein Vorhaben umzusetzen.
      Ich würde hierbei auf AVR's setzen, die als "inteligente' I2C-Slaves arbeiten.
      D.h. du kannst jetzt die Slaves so programmieren, wie du es haben möchtest und ein Protokoll einführen, das Fehler am Bus erkennt und an den Master meldet.

      Vorstellbar wäre ein Slave, der z.B. unkonfiguriert die Adresse 127 besitzt.
      Über diese Adresse findet ein Master heraus, ob ein neues Modul angesteckt wurde.
      Erkennt dies der Master, kann er dem Slave an Adresse 127 eine neue Adresse, die im Bus noch nicht belegt ist, vergeben, die dann der Slave bestätigt.
      An dann ist der Slave als Teilnehmer mit einer internen logischen Reihenfolge beim Master im RAM hinterlegt.

      Zyklisch, wenn gerade nix anderes zu tun ist, kann der Master alle Adressen mal abklappern und schauen, welche noch da sind.
      Meldet sich ein Slave nicht, wird der aus der Liste gestrichen und der Master kennt die neue Reihenfolge.

      Ein abgezogener Slave vergisst seine Adresse, wenn er stromlos wird. Und hat automatisch Adresse 127 wenn er gestartet wird (am Bus).

      Das Protokoll müsste etwas aufwendiger sein, denn das ACK-Bit als Handshake reicht nicht, um ein Übertragungsfehler auszuschließen.
      Dazu muss dann neben der Adresse des Bausteins auch der Befehl, die Daten und die Checksumme übermittelt werden, die dann der Slave bestätigen muss.
      Damit meine ich nicht das Ack-Bit, sondern wieder mehrere Bytes Daten als Response.

      Auf diese weise könnte ich mir vorstellen das umzusetzen. Dann ist PWM auch kein Thema mehr!, denn jeder Controller kann das. Zur Nor auch Soft-PWM, denn sonst macht der Slave ja vermutlich nix.

      Einfacher würde es vielleicht mit SPI gehen, man könnte die Slaves einfach hintereinander anstecken. Die Daten würden dass einfach durchgeschoben.
      Ähnlich einem Schiebe-Register.
    • Nun, vieles ist noch nicht geklärt, wir sind quasi noch am Anfang. Ich habe mich mal bissel umgesehen, ob es bereits fertige I2C Bausteine gibt, die LED per PWM steuern können. Habe einen gefunden, dessen Fähigkeiten so benannt werden:
      16-channel, 12-bit PWM Fm+ I2C-bus LED controller. Nennt sich PCA 9685 und hier ist sein Datenblatt:
      pdf1.alldatasheet.com/datashee…w/293576/NXP/PCA9685.html

      Ob sich dein Projekt mit sowas realisieren lässt, incl den Programtechnischen Aufwand kann ich nicht abschätzen.
      Ich liefere wieder mal nur technische Informationen zum ansehen, lernen um was es da geht, usw. Du könntest recherchieren, ob es Module auf dem Markt gibt, auf denen dieses IC verbaut ist, und so nebenbei ermitteln, ob sowas für deine Zwecke verwendbar ist.