-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 16

Thema: I2C zwischen Controllern

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705

    I2C zwischen Controllern

    Anzeige

    Dear all,

    ich arbeite mich gerade in die Materie ein, mehrere Controller per I2C kommunizieren zu lassen. Die Rollenverteilung ist einfach: Ein Master der nur sendet und 2-3 Slaves, die nur empfangen.

    Der Befehl I2cwbyte funktioniert schon mal super, im Oszillogramm sehe ich, dass der Master perfekte Clock- und Data-Signale einschließlich Taktzyklus für das ACK-Bit generiert.

    Auf der Slave-Seite muss dann ja der Befehl I2crbyte dazugehören, allerdings frage ich mich gerade woher der Slave weiß, wann er diesen Befehl ausführen soll. Schließlich kann der Code im Slave ja nicht wissen, wann der Master seine Daten schickt... Und was ich ebenfalls nicht verstehe: Was ist, wenn das ACK-Bit des Slaves ausbleibt, weil er z.B. gerade anderweitig beschäftigt ist? Ich habe verstanden dass dieses ACK-Bit dem Master signalisiert, dass der Slave korrekt durch seine Adresse angesprochen wurde - aber was wenn nicht? Dann würde es ja keinen Sinn machen, gleich mit I2cwbyte weitere Daten auf den Bus zu schicken...

    Viellecht kann mir ja jemand mal vom Schlauch runterhelfen, auf dem ich gerade zu stehen scheine...

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Zitat Zitat von Sauerbruch Beitrag anzeigen
    ... allerdings frage ich mich gerade woher der Slave weiß, wann er diesen Befehl ausführen soll.
    Immer dann, wenn er adressiert wurde. Das entscheidet entweder die Hardware-Mimik des Slave-Controllers, sofern man ihn als (ideal: interruptgetriebenen) Slave konfiguriert hat - oder die Firmware.
    Zitat Zitat von Sauerbruch Beitrag anzeigen
    ... Schließlich kann der Code im Slave ja nicht wissen, wann der Master seine Daten schickt...
    Naja, Interrupt oder eben Polling. Mehr Auswahl gibt es meines Wissens nicht.
    Zitat Zitat von Sauerbruch Beitrag anzeigen
    ... Und was ich ebenfalls nicht verstehe: Was ist, wenn das ACK-Bit des Slaves ausbleibt, weil er z.B. gerade anderweitig beschäftigt ist? ...
    Dann bleibt die Kommunikation stecken - ohne wenn und aber - so ist I2C spezifiziert. Abhilfe kann ein Timeout-Zähler und Warteschleifenabbruch schaffen.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beiträge
    1.401
    Zitat Zitat von Sauerbruch Beitrag anzeigen
    Was ist, wenn das ACK-Bit des Slaves ausbleibt, weil er z.B. gerade anderweitig beschäftigt ist?
    Ein Slave muß ständig auf dem Bus mitlauschen. Wenn da eine Startcondition zu sehen ist, weiß er daß die nächsten 7 Bit die Slaveadresse sind. Er hat dann 1 Bit Zeit um festzustellen, ob er angesprochen wird. Daß RW braucht er sich nur für später zu merken. Beim nächsten Takt vom Master zieht er SDA auf low und der Master liest das als ACK. Tut der Slave. das nicht, aus welchem Grund auch immer, ist es ein NAK und der Master muß die Übertragung abbrechen. Wenn der Slave einen kleinen Aufschub braucht, kann er die SCL-Leitung auf low halten, bis er sich entschieden hat, was er antworten will.
    aber was wenn nicht? Dann würde es ja keinen Sinn machen, gleich mit I2cwbyte weitere Daten auf den Bus zu schicken...
    Das ist richtig, es interessiert aber eigentlich Niemand. Bei fast jedem Codestück, das ich hier im Forum gesehen habe, wird ACK/NAK niemals ausgewertet sondern munter an einen nicht antwortenden Slave weitergesendet.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Ja, soweit hatte ich das auch verstanden, aber trotzdem verwirrt mich noch etwas: Das "lauschen" an sich (und das anschließende Vergleichen, ob die gerade gehörte 7-Bit-Adresse die eigene war) benötigt ja keinen eigenen, konkreten Befehl, oder? Ich stell´ mir das so vor wie das Reintrudeln von Bytes über die USART-Schnittstelle, was ja auch jederzeit unabhängig vom gerade laufenden Programm geschehen kann. Aber I2crbyte ist ja nun mal ein konkreter Befehl, der ja sofort ablaufen müsste, wenn der Controller seine eigene Slave-Adresse und das "W"-Bit vom master erkannt hat, oder?

    RoboHolIc deutete Interrupts an - aber ich werde diesbezüglich aus dem Daenblatt (ATMega8 ) irgendwie nicht richtig schlau: Dort steht als Interrupt-Vektor Nr. 18 zwar ein TWI-Interrupt, aber was heißt denn bitteschön die Interrupt-Definition "Two-wire serial interface"? Was muss denn genau in diesem Interface passieren, damit der Interrupt ausgelöst wird?

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Die Analogie zum USART ist treffend bzgl. des asynchronen Eintrudelns von Eingangsdaten.

    Das "lauschen" erledigt das I2C / TWI-Modul und aktiviert ggf. Statusflags, auf die man einen Interrupt ansetzen oder eben aktiv pollen muss. I2crbyte ist dann der konkrete Befehl, der das Auslesen des Empfangsbuffers und evtl das ACK-Handling plattformunabhängig implementiert. (ich schreib das mal ganz mutig in Analogie zu den PIC-Controllern).

    Bei keinem der (wenigen) I2C-Bausteine, die ich bisher verwendet habe, gibt es Clockstretching. Alle liefern auf Anfrage Daten und kennen keine unvorhersehbaren Verzögerungen bei der Buskommunikation, weil sie die I2C-Engine in Hardware haben.

    Allerdings sollte man das Auftreten von Busblockierungen einkalkulieren, die durch EMI, unerwartete Resets und Kontaktprobleme entstehen können.

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beiträge
    1.401
    Zitat Zitat von RoboHolIC Beitrag anzeigen
    Bei keinem der (wenigen) I2C-Bausteine, die ich bisher verwendet habe, gibt es Clockstretching. Alle liefern auf Anfrage Daten und kennen keine unvorhersehbaren Verzögerungen bei der Buskommunikation, weil sie die I2C-Engine in Hardware haben.
    Das sagst du so locker.

    Clockstretching tritt sogar ohne Slave auf. Nimm mal einen "sauber" implementierten I2C Master und betreibe ihn mit 400kHz, bei höheren Geschwindigkeiten ist der Effekt leichter zu erkennen. Ein Slave ist nicht angeschlossen, die Pullups sind so 10kOhm. Die 400kHz sind leicht nachzumessen. Nun schalte mal 400pF zwischen SCL und GND, das ist die maximale kapazitive Buslast nach der Spec. Der Bus wird jetzt merkbar langsamer (solange der Master sauber implementiert ist). Der Grund ist einfach: der Master setzt SCL für die halbe Bitzeit passend zu 400kHz auf low. Dann läßt er das Signal los und wartet, daß es high wird. Durch die hohe Kapazität des Busses dauert es aber eine Zeit, bis der High-Pegel erreicht wird. Erst dann startet er den Timer, wieder eine halbe Bitzeit, für die High-Phase von SCL. Die messbare SCL-Frequenz wird damit langsamer, die Clock "gestreckt". Es ist egal, wer oder warum SCL länger low ist, als der Master vorgibt. Der häufigste Fall ist natürlich, daß sich der Slave beim ACK erwas Zeit nimmt indem er SCL low hält.

    Bei einer Prozessor-Prozessor Verbindung ist Clockstretching eigentlich unvermeidlich und sehr hilfreich. Man kann im Slave wesentlich lockerer mit Interrupten und Interrupt-Sperren umgehen ohne die Integrität der Übertragung zu gefährden.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Nun ja. Wenn man das elektrische Tiefpassverhalten der Busverdrahtung (aus Sicht des Masters verständlich) auch dem Thema Clockstretching zuordnet, dann hast du natürlich recht.

    Andererseits: 400kHz und 400pF sind zwar innerhalb der Spec, nicht aber in Verbindung mit den 10k Pullups, weil man damit eine RC-Zeitkonstante von 4µs, mithin 250kHz vorgibt, aber den Bus mit 400kHz betreibt. Die Busverlangsamung demonstriert dann, dass der Master das Clockstretching toleriert.

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Also im Moment wäre ich ja schon froh, wenn der Slave einfach nur auf den Master reagieren würde... habe hierzu folgenden Code für den Master geschrieben:

    Code:
    $regfile = m8def.dat
    $Crystal = 1000000
    
    Config sda = PORTD.7
    Config scl = PORTB.0
    
    Do
    
    I2cstart
    I2cwbyte &b00000010
    I2cstop
    
    waitms 200
    
    Loop
    scl und sda sind mit 4k7 mit +5V verbunden, die Signale sehen gut aus.

    Beim Slave wollte ich mit einer toggelnden LED einfach nur mal sehen, ob er wenigstens schon mal in die TWI-ISR springt, wenn der Master die Slave-Adresse sendet:

    Code:
    $regfile = m8def.dat
    $crystal = 1000000
    
    Config sda = PORTD.7
    Config scl = PORTB.0
    
    DDRD.0=1
    
    TWCR = &b00000101
    TWAR = &b00000010
    
    On TWI Empfang
    Enable TWI
    Enable Interrupts
    
    Do
    Loop
    
    Empfang:
    Toggle PORTD.0
    Return
    Aber leider passiert nichts. Ich habe mir vorsichtshalber gerade die I2C-lib gekauft und werde sie heute Abend mal einbinden...

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    OK, mein Beitrag über dedizierte I2C-Slave-ICs war schon am Thema vorbei.
    Aber jetzt klinke ich mich besser aus, weil ich aus dem Code nichtmal rauslesen kann, ob es sich um TWI-Hardware oder eine Emulation in den Slaves handelt.

  10. #10
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Aber jetzt klinke ich mich besser aus, weil ich aus dem Code nichtmal rauslesen kann, ob es sich um TWI-Hardware oder eine Emulation in den Slaves handelt.
    Ich würd´s Dir gerne verraten - wenn ich es selber wüsste

    Mal sehen ob mich die I2c-Lib weiterbringt, ich werde jetzt noch ein wenig weiterpuzzeln!

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. PID Regler bei Brushless Controllern üblich?
    Von HeyHey im Forum Elektronik
    Antworten: 0
    Letzter Beitrag: 04.03.2013, 20:41
  2. LCD-Lib von P. Fleury für Display mit 2 Controllern
    Von pyr0skull im Forum C - Programmierung (GCC u.a.)
    Antworten: 22
    Letzter Beitrag: 26.04.2009, 10:03
  3. Reset Pin bei Atmel Controllern
    Von Powell im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 28.03.2007, 14:49
  4. Komuntikation zwischen Controllern
    Von NemesisoD im Forum Microcontroller allgemeine Fragen/Andere Microcontroller
    Antworten: 5
    Letzter Beitrag: 19.11.2006, 16:31
  5. Tonerzeugung mit Controllern
    Von ricoderrichter im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 24.08.2005, 17:43

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •