Prüfen ob I2C Bus aktiv ist?

    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!

    • Prüfen ob I2C Bus aktiv ist?

      Hallo zusammen,

      ich stehe gerade etwas auf dem Schlauch und brauche Hilfe.

      Ich habe an meinem I²C-Bus 2 Teilnehmer. Ein OLED-Display und ein Current-Output-DAC. Ich sende regelmäßig durch einen Timer gesteuert Daten an den DAC. Leider derzeit noch mit Start xxxxx Daten Stop. Das kostet mich aber sehr viel Zeit. Um das zu beschleunigen, wollte ich das eben so machen: Start xxxxx Daten, Daten, Daten, Daten (Stop, wenn OLED was schreiben soll).

      Versteht ihr, der I²C-Bus soll die Datenübertragung zum DAC nur dann stoppen, wenn das LCD etwas schreiben soll. Und das kommt nur 1 Mal pro Sekunde vor. Die Restliche Zeit soll der kontinuierlich Daten an den DAC senden. Somit kann ich meine Regelung viel Schneller Arbeiten lassen.

      So Schaut das dann grob aus.

      Quellcode

      1. DAC Senden kontinuierlich Daten:
      2. I2CSTART
      3. I2CWBYTE Ltc1427_adr
      4. I2CWBYTE spg48vHigh
      5. I2CWBYTE spg48vLow
      6. I2CWBYTE spg48vHigh
      7. I2CWBYTE spg48vLow
      8. I2CWBYTE spg48vHigh
      9. I2CWBYTE spg48vLow
      10. .....
      11. I2CSTOP
      12. Waitms 10
      13. Dann immer nach einer Sekunde LCD
      14. I2cstart 'start condition
      15. I2cwbyte &H78 'slave address
      16. 2cwbyte &H40
      17. For Zab2 = 1 To 128 '128 columns wide
      18. I2cwbyte Ddata(point)
      19. Incr Point
      20. Next
      21. I2cstop
      22. Waitms 10
      23. Und wieder DAC
      Alles anzeigen
      Jetzt ist halt der I²C ja immer offen so lange der DAC kontinuierlich Daten bekommen. Muss aber vor dem Umschalten auf OLED ja geschlossen werden. Ich würde nun einfach gerne prüfen, ob dies auch der Fall ist. Und weis nicht so wirklich, wie ich das machen soll.

      Hat da jemand eine Idee?

      Danke und Gruß
    • Hi, du bist doch der 'master', das heißt, du hast die Kontrolle und musst nix prüfen. Nach einem i2cstart lauschen die slaves nach der Adresse, damit sie, wenn sie gemeint sind, die Befehle verarbeiten. Ansonsten haben die nix am bus verloren.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • Snatch schrieb:

      Somit kann ich meine Regelung viel Schneller Arbeiten lassen.
      Als begeisterter Busfahrer würde ich eine Abfrage erstellen.
      Z. B ist DAC xyz Wert NEU, anders als der ALTE, nur dann die Adressefür LCD- IC aufrufen.

      Naja ich kenne deine Regelung nicht aber wenn LCD für ca. 100µs unterbricht, setze ich voraus das deine Sensoren viel schnellere Ergebnisse bereit stellen und die möchtest du zeitnah aktualisieren und sogar auswerten.
      Dann kleiner Tipp:
      Betrachte einfach das Bussystem als Eigenständig dann begrenzt nur der CPU die Geschwindigkeit.
      Also alle Busteilnehmer in eine Schleife ständig aktualisieren.
      Mit Ack oder Nack bestätigt jeder Teilnehmer sein „Ergebnis“ somit bestimmen diese grob gesagt die Busgeschwindigkeit.
      In dieser Schleife sollte kein Wait stehen(analog ISR)
      Da du innerhalb dieser Schleife alle Ereignisse aller Teilnehmer in Variablen speicherst, kannst du dies als Puffer betrachten.
      Nun kannst du in der Hauptschleife Entscheidungen treffen welches Ereignis wann und wo bearbeitet werden soll.
      Prinzip verstanden?

      Mit freundlichen Grüßen
    • fredred schrieb:

      Galahat schrieb:

      Ich würde für das Display einen software-Bus aufmachen.
      Ist eine Möglichkeit wenn noch Pins verfügbar sind.
      Bitte erkläre mal wo dann die geforderte Geschwindigkeit für Reglung herkommt wenn zwei Buslinien bedient werden müssen.
      Gruß
      Der TE will nicht schneller werden, sondern hauptsächlich eine asychrone stop - start - stop Sequenz auf dem Bus vermeiden, da er seiner Aussage nach sonst zuviel Zeit verliert, was aber sicher auch bei einer IDLE-Bus-Prüfung der Fall sein wird. Daher ist mein Vorschlag eine Variante dieser Problemstellung einfacher zu begegnen.
    • fredred schrieb:

      wo dann die geforderte Geschwindigkeit für Reglung herkommt
      nachdem das keine Sensor ist, sondern ein Ausgabegerät, was da am Bus hängt, ist es vom Programmierer abhängig, wie schnell er die Daten hintereinander aus gibt. Er muss das Teil nur 1x adressieren, dann kann er nacheinander beliebig viele Daten ausgeben. Wenn er fertig ist, ein i2cstop. Bus ist wieder frei für andere Dinge, wie display ansteuern.


      The LTC1427-50 is a receive-only (slave) device.
      The master initiates communication with the LTC1427-50with a START condition (see SMBus Operating Sequence)and a 7-bit address followed by the write bit = 0. TheLTC1427-50 acknowledges and the master delivers thecommand byte. The LTC1427-50 acknowledges and latchesthe active bits of the command byte into register A (seeBlock Diagram) at the falling edge of the acknowledgepulse. The master sends the data byte and the LTC1427-50 acknowledges the data byte. The data byte and last twooutput bits from register A are latched into register C at thefalling edge of the final acknowledge pulse and the DACcurrent output assumes the new 10-bit data value (seeBlock Diagram). A STOP condition is optional.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • Galahat schrieb:

      Der TE will nicht schneller werden, sondern hauptsächlich eine asychrone stop - start - stop Sequenz auf dem Bus vermeiden, da er seiner Aussage nach sonst zuviel Zeit verliert, was aber sicher auch bei einer IDLE-Bus-Prüfung der Fall sein wird. Daher ist mein Vorschlag eine Variante dieser Problemstellung einfacher zu begegnen.
      Akzeptiere deine Antwort, wenn ich die Anfrage des TE völlig falsch verstanden habe.
      Hab es wohl falsch gedeutet. In der Annahme er möchte ein optimales Regelverhalten das nicht ständig durch Ereignisanzeige diese unterbricht.

      tschoeatsch schrieb:

      nachdem das keine Sensor ist, sondern ein Ausgabegerät, was da am Bus hängt, ist es vom Programmierer abhängig, wie schnell er die Daten hintereinander aus gibt. Er muss das Teil nur 1x adressieren, dann kann er nacheinander beliebig viele Daten ausgeben. Wenn er fertig ist, ein i2cstop. Bus ist wieder frei für andere Dinge, wie display ansteuern.
      Für mich ist es uninteressant ob Sensor oder Aktohr am Bus genagelt ist. Teilnehmer benötigen halt Zeit.
      Nun verstehe ich nix mehr. Wann und wo weis der Teilnehmer das alles Ok ist, wohl nicht wenn ein I2Cstop den Bus trennt.
    • fredred schrieb:

      Wann und wo weis der Teilnehmer das alles Ok ist, wohl nicht wenn ein I2Cstop den Bus trennt.
      Early STOP ConditionsThe LTC1427-50 recognizes a STOP condition at any pointin the SMBus communication sequence. If the STOPoccurs prematurely before the data byte is acknowledgedin the Write Byte protocol, the DAC output current value isnot updated; otherwise internal register C is updated withthe new data and the DAC output current changescorrespondingly.

      Wenn du den LTC1427 als Teilnemer bezeichnest, dann ist er darauf eingestellt, dass ein i2cstop kommen kann.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • fredred schrieb:

      wenn ich die Strippe wehrend der Übertragung trenne weis es was für Daten noch kommen könnten
      na sicher nicht, was mich auch nicht wundert. Das Teil ist nur so schlau, dass man jederzeit einen i2cstop machen kann, ohne das es zu falschen Ergebnissen führt.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • Galahat schrieb:

      fredred schrieb:

      Galahat schrieb:

      Ich würde für das Display einen software-Bus aufmachen.
      Ist eine Möglichkeit wenn noch Pins verfügbar sind.Bitte erkläre mal wo dann die geforderte Geschwindigkeit für Reglung herkommt wenn zwei Buslinien bedient werden müssen.
      Gruß
      Der TE will nicht schneller werden, sondern hauptsächlich eine asychrone stop - start - stop Sequenz auf dem Bus vermeiden, da er seiner Aussage nach sonst zuviel Zeit verliert, was aber sicher auch bei einer IDLE-Bus-Prüfung der Fall sein wird. Daher ist mein Vorschlag eine Variante dieser Problemstellung einfacher zu begegnen.
      Bitte um Entschuldigung, dass ich mich nicht gemeldet habe.

      Du hast mit deiner aussage Recht. Ich will nicht schneller werden.
      Ich habe nur das Problem, dass meine Regelung, direkt nach dem ermitteln und Berechnen der Regelparameter, dass Ergebnis an den I²C sendet. Jetzt soll das OLED ca. ein Mal pro Sekunde Werte ausgeben. Problem ist nun, dass ich für das Schreiben an den IC und das Schreiben an das OLED 2 verschiedenen Routinen verwende. Und es ab und zu vorkommt, dass mein OLED nur Buchstabensalat anzeigt, weil die Regelung da wieder rein Pfuscht.

      Und genau daran hänge ich gerade etwas. Ich bekomme es nicht gebacken, dies so zu trennen, dass die Regelung weiter sauber und in ihrem doch recht langsamen Tempo von max. 10 ms arbeitet und das OLED in der Zwischenzeit kurz Daten überträgt, wenn die Regelung eben nichts überträgt.

      Die Lösung mit einem Software-Bus ist eine, dann wären die Systeme getrennt und das Problem sicher behoben. Technisch auch machbar. Aber kann man das nicht anders lösen? Ich stehe da immer noch auf dem Schlauch.

      Folgendes als Beispiel, welches Buchstabensalat auswirft:
      Ich habe so versucht, das LCD nur dann zum Schreiben zu bewegen, wenn die Regelung Pause hat.

      Quellcode

      1. ISR-REGELUNG_10ms:
      2. Regelungs....
      3. Arbeiten....
      4. PID....
      5. CALL Write_I2C
      6. RETURN
      7. SUB Write_I2C
      8. OLEDWRITE = 1
      9. I2CSTART
      10. I2CWBYTE Ltc1427_adr
      11. I2CWBYTE spg48vHigh
      12. I2CWBYTE spg48vLow
      13. I2CSTOP
      14. OLEDWRITE = 0
      15. END IF
      16. END SUB
      17. DO
      18. IF OLEDWRITE = 0 AND SEKUNDE = 1 THEN
      19. SEKUNDE = 0
      20. LCDAT 1,1,"TEST"
      21. END IF
      22. LOOP
      Alles anzeigen
      Grüße und Danke!

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Snatch ()

    • Verstehe jetzt nicht ganz. Du sendest Daten an deine Stromdingsbums, die adressiert und dann päärchenweise eine Daten. Jetzt kannst du doch mit dem i2cstop diesen Strom jederzeit unterbrechen, mit (nach) i2cstart das display adressieren und nun dorthin die gewünschten Daten schicken. Bist du damit fertig, wieder ein i2cstop und nach einem i2cstart dein Stromdings adressieren und dessen Daten senden.
      Dein display ist für deine Busgeschwindigkeit geeignet?
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • tschoeatsch schrieb:

      Verstehe jetzt nicht ganz. Du sendest Daten an deine Stromdingsbums, die adressiert und dann päärchenweise eine Daten. Jetzt kannst du doch mit dem i2cstop diesen Strom jederzeit unterbrechen, mit (nach) i2cstart das display adressieren und nun dorthin die gewünschten Daten schicken. Bist du damit fertig, wieder ein i2cstop und nach einem i2cstart dein Stromdings adressieren und dessen Daten senden.
      Dein display ist für deine Busgeschwindigkeit geeignet?
      Hallo, schau nochmal in meinen Beitrag eins über deinem. Habe da noch einen Beispielcode eingefügt.
      So wie du es beschreibst macht das Sinn. Aber es funktioniert bei mir so leider nicht wenn ich die BASCOM eigene LIB für das SSD1306 verwende.

      Du hast mich aber gerade auf die Idee gebracht, diese eben nicht zu verwenden.

      Also habe ich umgestellt auf:

      Quellcode

      1. ISR-REGELUNG_10ms:
      2. Regelungs....
      3. Arbeiten....
      4. PID....
      5. CALL Write_I2C
      6. RETURN
      7. SUB Write_I2C
      8. OLEDWRITE = 1
      9. I2CSTART
      10. I2CWBYTE Ltc1427_adr
      11. I2CWBYTE spg48vHigh
      12. I2CWBYTE spg48vLow
      13. I2CSTOP
      14. OLEDWRITE = 0
      15. END IF
      16. END SUB
      17. DO
      18. IF OLEDWRITE = 1 THEN
      19. text1 = str(adcupos)
      20. Call Lcd_text(text1 , 1 , 1 , 2)
      21. Call Lcd_show()
      22. OLEDWRITE = 0
      23. END IF
      24. LOOP
      25. Sub Lcd_show()
      26. Local Page As Byte , Zab1 As Byte , Zab2 As Byte
      27. Local Point As Word
      28. Point = 1
      29. Page = &HB0
      30. Call Lcd_comm_out(&H40)
      31. For Zab1 = 0 To 7
      32. Call Lcd_comm_out(page)
      33. Call Lcd_comm_out(&H10)
      34. #if Driver_typ = 1
      35. Call Lcd_comm_out(&H00)
      36. #else
      37. Call Lcd_comm_out(&H02)
      38. #endif
      39. I2cstart
      40. I2cwbyte &H78
      41. I2cwbyte &H40
      42. For Zab2 = 1 To 128
      43. I2cwbyte Ddata(point)
      44. Incr Point
      45. Next
      46. I2cstop
      47. Incr Page
      48. Next
      49. End Sub
      Alles anzeigen
      Und schon geht es.

      Keine Ahnung, was die Bascom Lib da anders macht.


      Grüße
    • Langsam kapier ich mehr, denke es zumindest.
      In einer isr sprichst du dein Stromdings an. Das kann natürlich auch während einer Ausgabe an dein display passieren. Ich würde während der Displayausgaben eher deinen interrupt verhindern. Dem passiert ja nix. Nur die Anweisungen an dein display können mit einem überraschendem i2cstart aus der isr durcheinander kommen.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • Du kannst ja auch den Spieß um drehen. Du packst die Ausgabe an das display in eine 1-Sekunden-isr. Der erste Befehl ist ein i2cstop, was deinem Stromdinds sagt 'jetzt ist stopp angesagt', dann die Befehle für das display. Als Abschluss wird mit i2cstart dein Stromdings wieder adressiert und die isr beendet. Du musst nur bei deinem Datenstrom an das Stromdings den interrupt zwischen den zusammengehörenden bytes sperren. Oder, sofern du das mit der isr weiter betreibst, einen 10msec interrupt für das Stromd.. und einen 1sec interrupt für die Anzeige.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • SSD1306 Oled display 1.3" I2C SPI?

      Hatte vor Jahren mal einen SSD1306 I2C Treiber programmiert, ganz ohne Lib.
      ...Weil es diese noch nicht gab.


      Funktionierte auch sehr zügig, da ich Segmente des Displays ansteuere und nicht alle Pixel.
      Wenn du nicht durchblickst, helfe ich Dir gerne.

      Es könnte dein Problem eventuell lösen?



      eine kleine Modifikation des Codes wird erfordert, wenn dein Display etwas zickt.
      mit denen die ich hatte, ging alles ohne.
      Hier dann die Lösung:

      Quellcode

      1. '+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      2. Sub Rstoled 'OLED RESET, Aufwecken, alles loeschen
      3. ' Dim I As Byte
      4. Dim J As Integer
      5. Dim Page As Byte
      6. Page = 176
      7. Temp = 0
      8. Do
      9. Senden = Lookup(temp , Oled_rst) 'Daten holen bis
      10. If Senden = &HFF Then Exit Do 'FF geladen wird
      11. I2cstart
      12. I2cwbyte Oled_adr
      13. I2cwbyte Oled_cmd
      14. I2cwbyte Senden 'DISPLAY aufwecken sleep= &HAE
      15. I2cstop
      16. 'Print Temp ; " " ; Hex(senden)
      17. Incr Temp
      18. Loop
      19. I2cstart
      20. I2cwbyte Oled_adr
      21. I2cwbyte &H40 'Datenempfang
      22. For J = 0 To 1023
      23. I2cwbyte &H00 'sende "leere Column"
      24. Next J
      25. I2cstop
      26. End Sub
      27. '****************** DATA's *****************************************************
      28. Oled_rst:
      29. Data &HAE , &HD5 , &H80 , &HA8 , &H3F , &HD3 , &H00 , &H40 , &H8D , &H14 , &H20,
      30. Data &H00 , &HA1 , &HC8 , &HDA , &H12 , &H81 , &HCF , &HD9 , &HF1 , &HDB , &H40,
      31. Data &HA4 , &HA6 , &HAF , &HFF 'FF markiert das Ende
      Alles anzeigen
      zu spät gelesen, dass Du die Lösung bereits gefunden hast

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von sk8erboi ()