Gast
#3880103
Ich suche nach einer Möglichkeit I²C über LVDS-Treiber und LVDS-Receiver zu schicken. Ist das aufgrund der Spgs-LvL nicht möglich oder hat das schon mal jemand gemacht. Grüße
Gast
#3880112
Steven schrieb: > Ist das aufgrund der Spgs-LvL nicht möglich Die Spannung ist eigentlich egal. Die I2C Leitungen sind, auch von der Protokollogik, bidirektional open collector, das läßt sich nicht auf LVDS abbilden. Man könnte I2C eigentlich nur auf einen 4 Leitungs-Bus aufsplitten und diese dann übertragen. Das machen manche galvanischen Trenner so. Ob das aber bei I2C Sinn macht oder ob man sich da nicht besser einen anderen Bus sucht? MfG Klaus
Gast
#3880190
Schau dir mal FPD-Link III an, da wird mit I2C über LVDS zusammen mit RGB natürlich gearbeitet.
Gast
#3880321
Normalerweise haben sind die Daten auf LVDS ja "codiert" (APIX, etc.). Die haben auch immer Sideband-Kanäle auf denen I2C gut läuft.
123 schrieb: > Die haben auch immer Sideband-Kanäle auf denen I2C gut läuft. Und wie wird da die Bidirektionalität von I²C umgesetzt?
Gast
#3882821
Also ich war zwischenzeitlich auf der Elektronika und bin fündig geworden. TI hat einen Full Duplex im Angebot, namens SN65MLVD207
Gast
#3882833
... auch da musst Du dem LVDS Bus für jedes Bit sagen, in welche Richtung gerade gesendet wird. DE/nRE Signale obliegen Deiner Verantwortung. Nicht sexy, aber wohl irgendwie machbar.
Gast
#3882896
Wie ich schon schrieb: I2C mit einem Buffer wie z.B. P82B96 in einen 4-Leitungs-Bus (2 mal Transmit, 2 mal Receive) aufteilen und dann mit 2 LVDS Treibern und 2 LVDS Empfängern (2 mal SN65MLVD203) auf 8 Leitungen zur entsprechend aufgebauten Gegenseite übertragen. Ob das dann noch einen praktischen Nährwert hat? Das klingt etwa so, als ob man die Signale eines Zeigertelegrafen über HDTV überträgt. Oder aber das i2c Protokoll mit kräftiger Überabtastung decodieren, das ganze dann in ungenutzten Bits eines sowieso vorhandenen High-Speed Links verpacken, und auf der anderen Seite das Protokoll wieder abspielen. Wenn man das aus Kompatibilitätsgründen machen muß und dabei ein paar Kabeladern spart, auch gut. Aber lohnt der Aufwand nur für i2c? MfG Klaus
KLaus schrieb: > Oder aber das i2c Protokoll mit kräftiger Überabtastung decodieren, das > ganze dann in ungenutzten Bits eines sowieso vorhandenen High-Speed > Links verpacken, und auf der anderen Seite das Protokoll wieder > abspielen. Und wie bekommst Du damit die Bidirektionalität des I²C übertragen?
Gast
#3882948
Hallo, wie schon oben erwähnt, FPD Link II kann genau das geforderte. Hier mal beispielhaft ein Chip: http://www.ti.com/product/ds90ua102-q1 Cheers
Gast
#3882950
Sry; Falscher Link. http://www.ti.com/product/ds90ub901q-q1
Gast
#3882966
Rufus Τ. Firefly schrieb: > Und wie bekommst Du damit die Bidirektionalität des I²C übertragen? Ich weiß jetzt nicht wie das z.B. bei dem genannten FPD-Link III gemacht wird. Die Richtung oder genauer gesagt, welche Seite den Bus treibt, läßt sich schon erkennen indem man die Richtung des Stroms beobachtet. Das ist das, was eigentlich alle I2C Treiber so machen, die Stromrichtung an einem Längswiderstand erkennen. Dabei leidet natürlich der Low-Pegel. Das ist beim SMBus mit seinen 0,8V TTL Low besonders problematisch, geht aber. Wenn ich also weiß, wer den Bus treibt (keiner, eine Seite, die andere Seite oder beide) kann ich diese Information beliebig kodiert (eigentlich über jeden schnellen bidirektionalen Link) übertragen und passend ausgeben. Und mit entsprechend großer Überabtastung ist das Delay bezogen auf die I2C Geschwindigkeit vernachlässigbar. MfG Klaus
Gut, das ist jetzt geklärt. Mit diesem FPD-Link-Baustein lässt sich das nebenbei erledigen. Bleibt die Frage, warum "Steven" das überhaupt anstellen will.
Gast
#3883003
Danke erst mal für die vielen Antworten. Hintergrund ist, dass ich momentan einen Messaufbau habe indem ich aufgrund von Leitungslänge und Geschwindigkeit, SPI über LVDS spreche. Ein Kollege von mir möchte diesen Messaufbau auch nutzen aber sein Device spricht er mit I2C an.
Gast
#3883089
Da macht ihr Euch meines Erachtens so keinen Gefallen. Entweder das Target des Kollegen um-modeln auf SPI oder eine SPI-I2C Bridge dazwischen schalten wäre ziemlich sicher einfacher. Deine Lösung SPI über LVDS würde mich interessieren. Welche Bausteine verwendest Du? Gibt es ein Schema/Code? Gruss Simon
Gast
#3883351
Die Wandlung in LVDS ist eine Vorgabe damit wir schneller und sicherer Daten übertragen könne. Für SPI habe ich diesen Baustein verwendet http://www.ti.com/lit/ds/symlink/ds90lv011aq-q1.pdf
Gast
#3883364
Steven schrieb: > Die Wandlung in LVDS ist eine Vorgabe damit wir schneller und sicherer > Daten übertragen könne. Was ist denn jetzt genau die Vorgabe? Schnell und sicher, oder dass dies über LVDS geschehen muss? Über CAN wäre schnell und sicher... http://www.nxp.com/documents/application_note/AN10364.pdf
Gast
#3883387
Die Datenübertragungsstrecke ist für CAN leider zu lang. Daher SPI und um das Ganze noch etwas zu frisieren habe ich in LVDS gewandelt. (Für schnellere Übertragungsrate und sichere Datenerfassung) Ich muss vllt noch erwähnen, dass ich über Schleifringe in eine TempKammer gehe.
Gast
#3883466
Ich glaube, das hier einige nicht wissen, das man mit LVDS schnell und sicher Daten übertragen kann. Steven: schau dir doch auch mal die Chips von inova an. Ansonsten gäbe es von ti noch die ds90xxx Kandidaten
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.