Hallo, ich habe massive Probleme mit Störungen auf meinem I²C Bus. Die Teilnehmer sind verteilt, eine naheliegende Motorendstufe strahlt voll rein (der Bus schmiert komplett ab). Jetzt habe ich zweierlei Informationen, wie man I²C verdrillen kann: SDA+GND oder SDA+VCC Beitrag "Re: Reichweite I2C" https://forum.arduino.cc/index.php?topic=138065.msg1041570#msg1041570 Ist es egal?
Der normale I2C-Bus ist prinzipbedingt störempfindlich. Es gibt aber eine differentielle Version, die Du benutzen kannst, und die Deine Probleme lösen sollte. Schau Dir das hier an: https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf Du brauchst für SCL und SDA je ein verdrilltes Adernpaar, plus GND. fchk
Motorendstufe und I2C passen nicht wirklich gut zusammen.Mit dem PCA9615 könnte man vieleicht eine Krücke haben um doch ans Ziel zu kommen. Aber richtig gut wird das so nie werden. Grüsse
Ich kann die Hardwareumgebung nicht elementar umbauen. Ich schirme jetzt die I²C-Leitungen und schaue mal, ob es besser wird.
Schirmung dürfte dir wenig helfen. Du dürftest es mit massiven induktiven Einkopplungen zu tun haben, die Magnetfeler rauschen durch die dünne Leitfolie recht ungehindert durch. Anders wäre es, wenn du mit Eisenrohren oder ähnlichem schirmst und die Magnetfehler damit um deinen Bus herumleitest. Haben die Bus-Teilnehmer und die Motoren ein gemeinsames Bezugspotential? Wenn ja, dann könntest du versuchen es aufzutrennen. In den meisten Fällen, wo hier von getrennten Massen schwadroniert wird, lehne ich dieses Konzept ab, aber hier könnte das - jedenfalls so weit man das bei einer Ferndiagnose ohne Kenntnis des Schaltplans und des Platinenlayouts sagen kann - hilfreich sein.
Martin S. schrieb: > Ich schirme jetzt die I²C-Leitungen und schaue mal, ob es besser wird. Kann sein, möglicherweise auch nicht: Abschirmung bedeutet zusätzliche Kapazität. Außerdem ist es auch möglich, dass die Störungen leitungsgebunden z.B. über die Stromversorgung eingetragen werden. Wie groß sind denn deine Pullup-Widerstände? I²C-Devices können laut Spec 3mA treiben. https://www.nxp.com/docs/en/user-guide/UM10204.pdf Also lege die Pullups auf knapp 3mA aus; an 5V z.B. 1k8 und an 3.3V 1.2k.
HildeK schrieb: > Also lege die Pullups auf knapp 3mA aus; an 5V z.B. 1k8 und an 3.3V > 1.2k. Hatte ich schon probiert. Das brachte leider keine neuen Erkenntnisse. Die Versorgungsspannungen sind i.O., es scheint tatsächlich einfach reinzublasen. Die Endstufe arbeitet mit 15 kHz, der I2C-Bus mit 100 kHz. Die Oberwellen stören also scheinbar voll rein.
Martin S. schrieb: > Ich kann die Hardwareumgebung nicht elementar umbauen. Aber genau das kommt eben dabei raus, wenn man I2C über ein längeres Kabel leiten will. Einen Bus der dafür nicht konzipiert wurde. Egal wie viele positive Berichte und sonstiges es dafür gibt. Er funktioniert auf einer PCB zwischen dort aufgebrachten Bausteinen tadellos, und genau dafür ist er gemacht. Man muss sowas einfach nur gleich mit RS232, RS485 oder eben diff. I2C planen. Wozu gibt es diese Dinge? Sorry, das konnte man vorhersehen.
:
Bearbeitet durch User
Was bei mir schon öfters geholfen hat, sind Kapazitäten gegen GND an jedem Busteilnehmer auf SDA und SCL. Bereich etwa 47-100pF. Flanken müssen mit Oszi kontrolliert werden!
geb schrieb: > Flanken müssen mit Oszi kontrolliert werden! Und zwar direkt am IC-Pin. Am besten mit einer Massefeder zum nächstliegenden Massepin. Martin S. schrieb: > Die Teilnehmer sind verteilt Die nachfolgende Frage ist eigentlich ganz naheliegend für einen Inter-IC-Bus, der dafür vorgesehen ist, Kommunikation zwischen ICs in einem kompakten Gerät (bis zur Größe eines Fernsehers) abzuhandeln: Wie weit? geb schrieb: > Motorendstufe und I2C passen nicht wirklich gut zusammen. Es kommt da auch noch ganz arg darauf an, wie die (Leistungs-)Ströme durch diesen ganzen Aufbau fließen müssen.
Die Leitungslänge sollte eigentlich nicht so das Problem sein. Etwa 1,5m. Ich habe alle Leitungen gestauscht und den Pullup geändert, und teste gerade durch. Mal sehen, ob's jetzt besser wird.
Martin S. schrieb: > Die Leitungslänge sollte eigentlich nicht so das Problem sein. Etwa > 1,5m. Ich fürchte, das siehst du falsch.
>Die Leitungslänge sollte eigentlich nicht so das Problem sein. Etwa 1,5m.
Welche Informationen führen Dich denn zu so einer krassen
Fehleinschätzung?
geb schrieb: > Was bei mir schon öfters geholfen hat, sind Kapazitäten gegen GND an > jedem Busteilnehmer auf SDA und SCL. Bereich etwa 47-100pF. Hab 33p aus den Tiefen des Lagers gezogen. Probiere zusätzlich noch, jeden Teilnehmerbusanschluss mit 1µ abzustützen. Mit den verdrillten Adern ist es deutlich besser geworden. Immerhin. Die Busfehler treten jetzt nicht sofort, sondern erst nach einer gewissen Laufzeit auf. Immerhin etwas.
Martin S. schrieb: > Die Leitungslänge sollte eigentlich nicht so das Problem sein. Etwa > 1,5m. Genau das ist aber das Problem denn wie u.a. der Cyberlord schon schrieb ist I2C nicht für solche Einsätze entwickelt worden. Eine Lösung könnte sein, dass man das I2C-Signal auf z.B. RS485 bringt und erst dann in die 1,5m lange Leitung einspeist.
M. K. schrieb: > Eine Lösung könnte sein, dass man das I2C-Signal auf z.B. RS485 bringt > und erst dann in die 1,5m lange Leitung einspeist. Ja das ist das nächste Mittel, wenn die Kapazitäten und bessere Schirmung der Motorleitungen nichts bringt. Das ist halt die deutlich zeitaufwändigere Methode.
Länge ist alles schrieb: > Welche Informationen führen Dich denn zu so einer krassen > Fehleinschätzung? Solange die störende Motor-PWM aus ist, läuft der Bus ohne Probleme. An der Leitungslänge liegt es also prinzipiell erstmal nicht. Aber bei diesem Kabelverhau vom Vorgänger sind bestimmt so manche Antenne drinnen...
Martin S. schrieb: > Das ist halt die deutlich zeitaufwändigere Methode. Zeitaufwändiger als sich das jetzt irgendwie hinzufummeln und doch immer wieder Störungen drauf zu haben? Denk mal nach...
Martin S. schrieb: > Solange die störende Motor-PWM aus ist, läuft der Bus ohne Probleme. An > der Leitungslänge liegt es also prinzipiell erstmal nicht. > > Aber bei diesem Kabelverhau vom Vorgänger sind bestimmt so manche > Antenne drinnen... Schick mal Fotos. Hast du Motordrosseln drin?
Hauke Haien schrieb: > Schick mal Fotos. Darf ich leider nicht. Hauke Haien schrieb: > Zeitaufwändiger als sich das jetzt irgendwie hinzufummeln und doch immer > wieder Störungen drauf zu haben? Denk mal nach... Ja, weil das Gesamtkonstrukt dringend gebraucht wird, und so eine Leiterplatte vor 4 AT nicht einsetzbar ist. Die Lösung werde ich jetzt trotzdem favorisieren und umsetzen. Bis dahin braucht es aber Abhilfe.
M. K. schrieb: > eigentlich nicht so das Problem sein. Etwa >> 1,5m. ist kein Problem, hier läuft es seid Jahren über 6m (mit 40Khz). Pullups an beiden Enden und evt die Frequenz etwas senken sollte reichen.
Spannend. Mit den 33pF von SDA/SCL gegen Masse schmiert der Bus jetzt nicht mehr ab. Er wird nurnoch langsamer, wenn hohe Motorströme fließen.
Martin S. schrieb: > Spannend. Mit den 33pF von SDA/SCL gegen Masse schmiert der Bus jetzt > nicht mehr ab. Er wird nurnoch langsamer, wenn hohe Motorströme fließen. Wie kann es sein dass er langsamer wird? Der Takt wird doch vom Master bestimmt. Meinst du eher, du musst den Bus langsamer Takten damit es noch klappt? Wie kann die Busgeschwindigkeit sich im Betrieb ändern, nur weil die Motoren jetzt mehr stören?
:
Bearbeitet durch User
Martin S. schrieb: > Solange die störende Motor-PWM aus ist, läuft der Bus ohne Probleme. Kenn ich. Ich bin ständig müde, sobald ich mich hinlege gehts... A. H. schrieb: > ist kein Problem, hier läuft es seid Jahren über 6m (mit 40Khz). Aha, 40 kHz für nen Bus, der eigentlich für 100 kHz gebaut wurde...kann man machen, muss man aber nicht. Man hätte ja gleich richtig entwickeln können. Aber OK, wenns funktioniert: Glückwunsch. Ich finde aber nicht, dass das etwas ist, dass man nachmachen sollte.
Cyblord -. schrieb: > Wie kann die Busgeschwindigkeit sich im Betrieb ändern, nur weil die > Motoren jetzt mehr stören? Vielleicht kommt der Controller durcheinander? Wenn der Motor stört, warum entstört man denn den nicht? Das ist meistens die sinnvollere Vorgehensweise, anstatt bei allen gestörten anderen Schaltungsteilen nach Maßnahmen zu suchen.
HildeK schrieb: > Cyblord -. schrieb: >> Wie kann die Busgeschwindigkeit sich im Betrieb ändern, nur weil die >> Motoren jetzt mehr stören? > > Vielleicht kommt der Controller durcheinander? ja ich denke auch eher an Fehler und entsprechend viel Retrys. Ist riesen Pfusch so.
Cyblord -. schrieb: > ja ich denke auch eher an Fehler und entsprechend viel Retrys. Ist > riesen Pfusch so. Jupp. Wird sich ja dann ändern, wenn differentielle Leitungstreiber kommen. Dauert halt noch. HildeK schrieb: > Wenn der Motor stört, warum entstört man denn den nicht? Der Vorgänger hat die Motorleitungen mit Kupfer umwickelt und geerdet. Ich gehe da aber auch nochmal rüber, weil mir das viel zu viel stört, als dass es eigentlich halbwegs "dicht" sein müsste.
M. K. schrieb: > Aha, 40 kHz für nen Bus, der eigentlich für 100 kHz gebaut wurde...kann > man machen, muss man aber nicht. Siehst du ein Problem darin? I2C ist doch für Geschwindigkeiten bis 100 kHz, oder liege ich da falsch? Bei vielen Anwendungen ist es völlig Wurst, ob die zwei Byte Nutzdaten nun 300us oder 1ms brauchen.
Martin S. schrieb: > Der Vorgänger hat die Motorleitungen mit Kupfer umwickelt und geerdet. > Ich gehe da aber auch nochmal rüber, weil mir das viel zu viel stört, > als dass es eigentlich halbwegs "dicht" sein müsste. Ob das was nützt? Normalerweise: - Gehäuse an Erde - An den Zuleitungen direkt am Motor mit Drosseln und Kondensatoren die Störungen nach außen reduzieren
Max G. schrieb: > I2C ist doch für Geschwindigkeiten bis > 100 kHz 100kHz ist Standart, 400kHz ist auch gebräuchlich. Einige Chips gehn in den MHz Bereich rein. (z.B. ADS1110 3,4Mhz). Runter gehts bis "Kippschalter" Der Master gibt den Takt vor. Langsamer (Datentransfer nicht Clock) kann es werden wenn er den Slave nicht verstanden hat (CRC Fehler) und nochmals fragte. Oder mehrmals fragen musste weil der Slave ihn nicht verstand. In meinem Fall kann der Master nicht schneller (Software I2c und nur 1Mhz Takt)
A. H. schrieb: > 100kHz ist Standart 100kHz ist eine Frequenzangabe. Mit der Art zu stehen hat das wenig zu tun. Im I2C-Standard gibt es Standard-mode, Fast-mode (Fm) und Fast-mode Plus (Fm+). Zu jedem dieser drei Modi ist die maximale Taktfrequenz festgelegt - unabhängig davon, wie oft oder selten sie verwendet wird. Standard ist Standard. https://www.nxp.com/docs/en/user-guide/UM10204.pdf
A. H. schrieb: > Runter gehts bis "Kippschalter" > Der Master gibt den Takt vor. Was aber nichts nützt wenn der Slave nicht oversampelt. I2C ist imo das am wenigsten geeignete Protokoll für störanfällige Umgebungen.
Martin S. schrieb: > Spannend. Mit den 33pF von SDA/SCL gegen Masse schmiert der Bus jetzt > nicht mehr ab. Freut mich dass meine Erfahrungen auch bei dir funktionieren... > Er wird nurnoch langsamer, wenn hohe Motorströme fließen. was meinst du damit genau??
M. K. schrieb: > Martin S. schrieb: >> Die Leitungslänge sollte eigentlich nicht so das Problem sein. Etwa >> 1,5m. > > Genau das ist aber das Problem denn wie u.a. der Cyberlord schon schrieb > ist I2C nicht für solche Einsätze entwickelt worden. > > Eine Lösung könnte sein, dass man das I2C-Signal auf z.B. RS485 bringt > und erst dann in die 1,5m lange Leitung einspeist. RS-485 ist als physical layer für I2C-Signale einigermaßen ungeeignet.
:
Bearbeitet durch User
A. H. schrieb: > 100kHz ist Standart, 400kHz ist auch gebräuchlich. Eigentlich nicht, als minimale High-Zeit sind 4,0µs und als Minimale Low-Zeit sind 4,7µs vorgegeben. Daraus kann man sich eine Frequenz von rund 100kHz errechnen. Ein solches Device darf sich Standard-Mode nennen. Für Devices, die das Label Fast-Mode (aka 400kHz) haben wollen, sind es 0,6 und 1,3µs. Es steht aber nirgendwo geschrieben, daß High oder Low Zeit minimal sein müssen und auch nicht, daß die Zeiten bei jedem Bit gleich lang sein sollen. Cyblord -. schrieb: > Aber genau das kommt eben dabei raus, wenn man I2C über ein längeres > Kabel leiten will. Einen Bus der dafür nicht konzipiert wurde. Egal wie > viele positive Berichte und sonstiges es dafür gibt. Er ist dafür erfunden worden, verschiedene Platinen in einem Consumergerät mit möglichst wenig Adern billigsten Drahtes zu verbinden. Und das konnte in einem Röhrenfernseher schon ganz schön lang werden. Die Erfinder des des HDMI Standards waren sich sicher, daß der I2C Bus in den entsprechenden HDMI-Kabeln auch für 5m gut ist. Daher findest du ihn auch dort. MfG Klaus
Klaus schrieb: > Die Erfinder des des HDMI Standards waren sich sicher, daß der I2C Bus > in den entsprechenden HDMI-Kabeln auch für 5m gut ist. Daher findest du > ihn auch dort. Nein, die haben das genommen, da es bei DVI schon verwendet wurde. HDMI und DVI sind kompatibel, nur kleinerer Stecker...
Moin, Die "Erfinder" des Displayport-StandarDs waren sich da dann wohl schon nicht mehr so sicher und haben den I2C lieber durch einen AUX-Channel mit symmetrischem Leitungspaar ersetzt (warum nur?)... Gruss WK
P. S. schrieb: > RS-485 ist als physical layer für I2C-Signale einigermaßen ungeeignet. Na ich meinte damit auch nicht, dass man RS485 so 1:1 mit dem I2C-Signal modeliert werden sollte ;) Klaus schrieb: > Und das konnte in einem Röhrenfernseher schon ganz schön lang werden. Wie das? Das Signal-Kabel fünf mal um die Röhre wickeln oder wie? Als 1.5m wären schon was, aber noch mehr...wie gesagt, es funktioniert (kann funktionieren) aber eigentlich wurde I2C für solche Strecken nie entwickelt. Ich meine sogar mich zu erinnern, dass I2C von Phillips nur entwickelt wurden um ICs auf einem PCB miteinander zu verbinden. Mit Kabeln verschiedene PCBs noch zu verbinden via I2C hab ich grade nicht auf dem Schirm. Geht aber natürlich auch, mach ich hin und wieder auch. Wie aber schon mal gesagt: Grade in diesem Projekt erscheint mir der I2C-Bus so, wie er hier angewandt wurde, nicht als sinnvoll und es wurde ja auch schon gesagt, dass da umstrukturiert werden soll. Das finde ich eine gute Idee.
:
Bearbeitet durch User
Martin S. schrieb: > Jetzt habe ich zweierlei Informationen, wie man I²C verdrillen kann: Die sind beide nur sehr begrenzt sinnvoll, weil Verdrillen was bewirkt bei Differenzsignalen, und die hat I2C eben nicht. Wie schon mehrfach gesagt, mit Absicht, weil I2C nicht für die böse Aussenwelt entworfen wurde. Georg
fchk schrieb: > Der normale I2C-Bus ist prinzipbedingt störempfindlich. Es gibt > aber > eine differentielle Version, die Du benutzen kannst, und die Deine > Probleme lösen sollte. > > Schau Dir das hier an: > https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf > > Du brauchst für SCL und SDA je ein verdrilltes Adernpaar, plus GND. > > fchk Habe gesehen, dass der PCA9615 einen Enable hat, der beim Startup nicht High sein darf (falls ich das richtig verstanden habe). Der PCA9600 ist eine vereinfachte Version, der eigentlich meinen Zweck voll erfüllen könnte. https://www.nxp.com/products/interfaces/ic-spi-serial-interface-devices/ic-bus-repeaters-hubs-extenders/dual-bidirectional-bus-buffer:PCA9600 Hat jemand Erfahrungen damit? Idealerweise wird das Ding ja einfach Plug&Play dazwischen geschaltet, oder?
Ich würde alle Signalleitungen inlkl. Signalground schirmen. Den gemeinsamen Schirm nur an der der Seite des Busmasters mit Masse verbinden. Verdrillte Signalleitungen helfen nur bei symetrischer Signalübertragung bei ausreichender Gleichtaktunterdrückung des Empfängers.
A. H. schrieb: > Standart kein Gemecker, kein Genörgel, nur ein Hinweis zum Lernerfolg Standart ist eine Art zu stehen bei Flamingos auf einem Bein *Standard!*
Joachim B. schrieb: > Standart ist eine Art zu stehen bei Flamingos auf einem Bein *Standard!* Was übrigens sogar noch funktioniert wenn der Flamingo Tod ist ;-)
M. K. schrieb: > Klaus schrieb: >> Und das konnte in einem Röhrenfernseher schon ganz schön lang >> werden. > > Wie das? Das Signal-Kabel fünf mal um die Röhre wickeln oder wie? Ich konnte mir damals schon ein Gerät mit einer 70cm Röhre leisten. georg schrieb: > Wie schon mehrfach gesagt, mit Absicht, weil I2C nicht für die > böse Aussenwelt entworfen wurde. Dann hast du I2C nicht verstanden. Das Konzept verlangt zwingend, das mindestens SCL gleichzeitig von beiden Seiten gleichzeitig getrieben werden kann. War bei anderen Bussen aus dieser Zeit auch üblich. georg schrieb: > Martin S. schrieb: >> Jetzt habe ich zweierlei Informationen, wie man I²C verdrillen kann: > > Die sind beide nur sehr begrenzt sinnvoll, weil Verdrillen was > bewirkt bei Differenzsignalen, und die hat I2C eben nicht. Das verdrillen von Signalen bewirkt schon was, furchtbares Übersprechen. Da reicht schon ein halber Meter und nichts geht mehr. Auf die Idee kann nur einer kommen, der, wie oben beschrieben, I2C nicht verstanden hat. Martin S. schrieb: > SDA+GND oder SDA+VCC Da sehe ich nichts vom Verdrillen von Signalen. GND und Vcc sind Wechselspannungsmäßig equivalent. Es ist also egal ob SDA mit Vcc oder GND verdrillt wird. Wichtiger ist aber SCL. Und auch da ist egal mit welcher Versorgung. Man kann zusätzlich noch Vcc und GND auf beiden Seiten abblocken. MfG Klaus
Martin S. schrieb: > fchk schrieb: >> Der normale I2C-Bus ist prinzipbedingt störempfindlich. Es gibt >> aber >> eine differentielle Version, die Du benutzen kannst, und die Deine >> Probleme lösen sollte. >> >> Schau Dir das hier an: >> https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf >> >> Du brauchst für SCL und SDA je ein verdrilltes Adernpaar, plus GND. >> >> fchk > > Habe gesehen, dass der PCA9615 einen Enable hat, der beim Startup nicht > High sein darf (falls ich das richtig verstanden habe). > > Der PCA9600 ist eine vereinfachte Version, der eigentlich meinen Zweck > voll erfüllen könnte. Äh, nein. Da bekommst Du keinen differentiellen Bus raus. Der PCA9600 wandelt die bidirektionalen Open Collector SCL/SDA Signale in unidirektionale SCL_TX/SCL_RX und SDA_TX/SDA_RX Signale um. Das ist aber nicht das, was Du eigentlich brauchst. Hier https://learn.sparkfun.com/tutorials/qwiic-differential-i2c-bus-extender-pca9615-hookup-guide/all steht geschrieben, dass EN nur optional ist und eher für Hotswap und Diagnose gebraucht wird. Wenn Du kein Hot-Swap brauchst, müsste ein Pullup am EN reichen. fchk
Martin S. schrieb: > Der PCA9600 ist eine vereinfachte Version, der eigentlich meinen Zweck > voll erfüllen könnte. Ich schicke damit Daten über 15m im KFZ, allerdings sind das nur "Nice-To-Have" Daten...die werden sekündlich abgefragt und wenn sie mal für 10s ausbleiben oder ganz ausfallen, dann ist das halt so. Für Daten die unbedingt ankommen sollten (Steuerbefehle etc) nehme ich CAN. In deinem Fall solltest du deine Daten ebenfalls klassifizieren und abschätzen was schlimmstens passiert, wenn deine Daten beim Empfänger ausbleiben...(Motor dreht unkontrolliert hoch etc) Je nach dem wie schnell dein System auf Änderungen von Daten die auf dem i2c laufen reagieren soll, kannst den Empfänger erst Daten verarbeiten lassen, die 3x empfangen und identisch sind (Ringspeicherprizip = mehr Störsicherheit). VG Paul
Klaus schrieb: > georg schrieb: >> Wie schon mehrfach gesagt, mit Absicht, weil I2C nicht für die >> böse Aussenwelt entworfen wurde. > > Dann hast du I2C nicht verstanden. Das Konzept verlangt zwingend, das > mindestens SCL gleichzeitig von beiden Seiten gleichzeitig getrieben > werden kann. Was hat denn das eine mit dem anderen zu tun? Daß I²C nicht für störende Umgebungen gedacht ist, ist auch mein Kenntnisstand. Wenn da die Busleitungen schon so elendig mit Kapazitäten zerpfuscht werden - sind die PWM-Stufen denn wenigstens mit ein paar anständigen LC-Filtern versehen? Denn das: Martin S. schrieb: > Der Vorgänger hat die Motorleitungen mit Kupfer umwickelt und geerdet. hört sich für mich nicht nach einem brauchbaren Filter an.
Hallo, hatte ähnliche Problem auch vor einiger Zeit. Wollte mim BMS des Akkus für meine Motorendstufe kommunizieren. Wie auch du schon erfahren hast, geht das nur sehr schwer. Bei mir warens leitungsgebunden Störungen. Da Motor-GND auch BMS-GND ist, ist das eine Katastrophe und naheliegend. Abhilfe haben bei mir Ferrite auf den Leitungen gebracht. Jetzt funktionierts so lala, da sich die Daten (Akkustand) auch nicht im ms-Takt ändern, ists nicht so schlimm und hin und wieder kommt was durch. Auch zu beachten ist das Freitakten eines I2C Teilnehmers, wenn er mal einen Fehler hat. Machst du das nicht, bleibt er einfach aufgehängt. (siehe I2C spec - zu viele cycles am clock zwischen start und Stop resettieren die Kommunikation)
Wühlhase schrieb: > Daß I²C nicht für störende Umgebungen gedacht ist, ist auch mein > Kenntnisstand. och hat im TV den Einsatz wohl nie behindert! Im TV kann eine Menge stören, der Tuner, die ZF, die ZE die HS......
M. K. schrieb: > Na ich meinte damit auch nicht, dass man RS485 so 1:1 mit dem I2C-Signal > modeliert werden sollte ;) Sondern?
P. S. schrieb: > M. K. schrieb: >> Na ich meinte damit auch nicht, dass man RS485 so 1:1 mit dem I2C-Signal >> modeliert werden sollte ;) > > Sondern? Na jetzt mal mitdenken bitte. So schwer ist das nicht. Aber ne, warte, du suchst ja nur was worauf du rumhacken kannst. Dafür bin ich nicht zu haben, sorry.
Frank K. schrieb: > Äh, nein. Da bekommst Du keinen differentiellen Bus raus. Der PCA9600 > wandelt die bidirektionalen Open Collector SCL/SDA Signale in > unidirektionale SCL_TX/SCL_RX und SDA_TX/SDA_RX Signale um. Das ist aber > nicht das, was Du eigentlich brauchst. Ok, das wäre ein Griff ins Klo gewesen. > Hier > > https://learn.sparkfun.com/tutorials/qwiic-differential-i2c-bus-extender-pca9615-hookup-guide/all > > steht geschrieben, dass EN nur optional ist und eher für Hotswap und > Diagnose gebraucht wird. Wenn Du kein Hot-Swap brauchst, müsste ein > Pullup am EN reichen. Wenn der EN dauerhaft High sein darf, dann habe ich das falsch verstanden. Dann tut er ja eigentlich genau das, was er soll.
Joachim B. schrieb: > Wühlhase schrieb: >> Daß I²C nicht für störende Umgebungen gedacht ist, ist auch mein >> Kenntnisstand. > > och hat im TV den Einsatz wohl nie behindert! Im TV kann eine Menge > stören, der Tuner, die ZF, die ZE die HS...... Das vermag ich nicht zu beurteilen. Weder, wieviele Störer es in einem Fernsehr gab, noch ob I²C darin gut funktionierte oder wieviel die Entwickler da zurechtpfuschen mußten wie der TS hier z.B. Hier funktioniert es ja offensichtlich nicht besonders gut, und I²C wurde für solche Einsatzzwecke halt nie gebaut. Störer und längere* Wege waren sicher kein Teil der Spezifikation was man schon daran sieht, daß I²C eine gemeinsame Masse vorraussetzt, und keine galvanische Trennung vorsieht. Im Gegensatz z.B. zu CAN, daß da deutlich andere Schwerpunkte setzt. *Alles was nicht mehr auf derselben Leiterkarte sitzt.
Update: Der o.g. PCA funktioniert, wie er soll. Danke für eure Hilfe :-)
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.