Hallo zusammen, Ich möchte die I2C Signale im timing manipulieren, und zwar in einem Bereich von 100-400 ns delay. Beim SCL hätte ich jetzt ein RC Glied genommen um die Flanken flacher zu bekommen, mit einem darauf folgenden OPV als Schmitt Trigger mit threshold Hysterese, welche ich so einstelle dass ich meine Verzögerung bekomme. Hat sowas schon mal jemand gemacht, auch anders? Wie könnte ich das beim bidirektionalen SDA implementieren? Da will ich nur in einer Richtung verzögern. Grüße Tweaker
Hallo nochmal, ich weiß es hört sich komisch an, es geht aber darum ein nicht I2C spec konformes Timing eines Bausteins zu fixen, damit er keine falsche start condition generiert. Hat jemand doch eine Idee? tweaker
Mach Software-I2C. Dort läßt sich das Timing entsprechend "verbiegen", bis es auf den angeschlossenen Baustein paßt. Bernhard
wo genau liegt denn das Timing Problem? Vielleicht lässt es sich ja auch anders lösen, als über Verzögern der Signale
Software I2C geht hier denke ich nicht, ich muss mit einem Master verschiedene Slave ansprechen. Der Master und ein Slave haben, ich nenne es einfach mal "richtiges" timing, ein anderer Slave hat aber ein von der Spec leicht abweichendes. Deswegen die Idee eine Hardware vor diesen einen Baustein zu setzen. Das timing Problem liegt darin dass durch eine Verschiebung im SCL zum SDA Signal ein falsches Start erkannt wird, das aber keines sein soll.
Das heisst: Der Salve erkennt eine Start-Condition, wo eigentlich keine ist??? I²C start-condition: fallende Flanke auf SDA während SCL = High. Wenn du jetzt SCL verzögerst, machst du doch alles noch schlimmer, oder seh ich was falsch..
Ich habe genaue Vorgaben bekommen wie ich die Signale bei rising UND falling edge verändern soll, speziell damit nicht fälschlicherweise die start condition auftaucht. Die Masterfrage ist jetzt wie ich das technisch realisieren kann, vor allem die bidirektionalen Signale. Das letztendlich richtige timing hinzubekommen stelle ich mir nicht so komplex vor.
>vor allem die bidirektionalen Signale.
Garnicht. WEnn dieses IC nicht I2C-tauglich ist, geht es halt nicht an
dem Bus.
Mach das falsche Timing als I2C-Master in Software. Wenn das dann der richtige I2C-Chip nicht mehr verstehen kann, mache 2 getrennte I2C-Busse. Peter
Darf man mal erfahren, was das denn das für ein Baustein ist, der so rumzickt?
Wenn Takt und Daten nicht in der korrekten Phase zueinander sind, dann reiecht es ja, wenn du eines der beiden Signale veschiebst. Das könntest du z.B. über eine Delayline machen (nicht ganz billig, aber sehr genau) Solange du aber hier nicht genau erklärst, wie du wann welche Signale verändern muss, und ggf auch warum, wird dir wohl keiner eine "fuchsige" Lösung bringen können. Ausserdem musst du beachten, dass I²C das sogenannte Clock-Stretching unterstützt, was ggf. zu Problemen führen kann, wenn du am Takt rumbiegst. Ebenso musst du bedenken, dass die Singale nur aktiv nach Low getrieben werden und diese Eigenschaft GRUNDLEGEND für die Funktion von I²C notwendig ist. Bei einer aktiven Manipulation der Signale (Treiber etc) muss du genau hinschauen, ob die ganzen Mechanismen dann noch funktionieren.
Wäre es nicht das einfachste, einen kleinen Atmega zu nehmen? Mit dem seinem (hoffentlich) korrekt arbeitenden I2C-Interface wird er an den eigentlichen Bus angeschlossen. Auf zwei Pins erzeugst du dann einen I2C-Bus in Software, mit angepasstem Timing. Die Verzögerung sollte eigentlich nicht allzu groß werden können. Während der Atmega das Protokoll "übersetzt", kannst du den Master mittels Clock Stretching einfach warten lassen.
Danke für euren Input. Ich kann nicht sagen was es für ein Bauteil ist. Ich werde das mit dem Software I2C mit µC mal durchgehen. cu tweaker
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.