Moin moin, Kurze Version: Kann ich 2 serielle Leitungen (I2C) über einen Demux laufen lassen, oder mach die Verzögerungszeitvon (etwa 40ns) Probleme ? Ausführliche Version: ich sitz' grad an einem Projekt wo ich Daten mittels i2c zwischen 2 Arduino Nanos austauschen möchte. Für i2c habe ich ja 2 Leitungen (SDA, SCK) zudem soll nur einer der Arduinos mit Strom versorgt werden der andere zehrt vom ersten, was also nochmal 2 Leiungen (5V, GND) hinzufügt. Insesamt habe ich also 4 Leitungen zwischen den Nanos. Für das Projekt ist es jetzt wichtig, dass die I2C Leitungen und auch die Spannungsversorgung falsch verpolt werden darf (SCK mit SDL und GND mit 5V). Mit einem B2 Brückengleichrichter hätte ich ja das Problem im Fall einer verpolten Versorgungsspannung gelöst. Aber wie mache ich das bei der SCK und SDA Leitungen ? Ich habe mir überlegt, dass man es ja evtl. mit einem Demulitplexer lösen könnte. Je nachdem ob richtig oder falsch verpolt wurde, wird eben auf einen anderen Ausgang geschaltet, welche jedoch beide miteinaner verbunden werden. Davon geht dann die eigentiche Leitung ab. So habe ich ja immer das Richtige Signal am Ausgang anliegen. Da SDA und SCK immer dann verpolt sind, wenn auch die Spannungversorgung verpolt ist, könnte ich die info für den Demux zum schalten ja aus dem B2 nehmen. 1. Frage, meint ihr das klappt so wie ich mir das vorstelle? 2. Frage, der demux hat eine verzögerung von etwa 40ns, bringt das vielleicht Probleme mit sich bzgl. der Taktleitung? Vielen Dank schoneinmal vorab :)
Die Verzögerung ist ziemlich sicher egal. Ein kleines Problem kann je nach Design der innenwiderstand im multiplexer sein, aber das ist auch durch richtige Bauteilwahl zu bewältigen. Dein größtes Problem wird sein, dass an den Dioden im Brückengleichrichter 0.7v abfällt. Nicht nur frisst dir das die Versorgungsspannung auf, du hast auch noch einen Masse-Versatz. Mit schottkys (0.3V) könntest du Glück haben und im akzeptablen Bereich liegen, aber ich würde mir lieber Gedanken um einen verdrehsicheren Stecker machen.
NumiX schrieb: > Für das Projekt ist es jetzt wichtig, dass die I2C Leitungen und auch > die Spannungsversorgung falsch verpolt werden darf Wozu der beschreibene Aufwand? Kommen einfache Lösungen nicht in Frage: 1. Steckverbinder, die nicht verpolt werden können 2. Steckverbinder mit mehr als 4 Pins und symmetrischer Belegung. ?? Besonders für die Stromversorgung würde ich nach Punkt 2 vorgehen, ein Brückengleichrichter ist ungeeignet, und so etwas wie ein geschalteter Gleichrichter/Umpoler mit FETs ist viel zu viel Aufwand. NumiX schrieb: > So habe ich ja immer das Richtige Signal am > Ausgang anliegen Das genügt ja nicht, zumindest SDA ist bidirektional. Kann dein Mux beide Richtungen? Glaube ich nicht. Georg
NumiX schrieb: > Brückengleichrichter Lustige Idee.... Aber es ist dir schon klar, dass du dann keinen gemeinsamen GND mehr hast .... I2C ist für sowas nicht ausgelegt. z.B. Ethernet+POE erfüllt deine Anforderungen. Zumindest entsteht bei der Verpolung kein Schaden.
Oha, das ging schnell und vor allem viele gute Einwände - vielen Dank dafür! Max D. schrieb: > Dein größtes Problem wird sein, dass an den Dioden im > Brückengleichrichter 0.7v abfällt. Nicht nur frisst dir das die > Versorgungsspannung auf, du hast auch noch einen Masse-Versatz. > Mit schottkys (0.3V) könntest du Glück haben und im akzeptablen Bereich > liegen, aber ich würde mir lieber Gedanken um einen verdrehsicheren > Stecker machen. Ja über den Spannungsabfall habe ich mir auch schon gedanken gemacht ich muss mir das noch mal anschauen wie der Arduino mit weniger Spannung klar kommt. Den Masseversatz hatte ich gar nicht auf dem Schrim als Laie. Einen verdrehsicheren Stecker kommt leider nicht in Frage. Die Arduinos sind Prototypen für einen späteren mC der später in ein würfelförmiges Gehäuse kommt. Auf der unter und oberseite sind keine Anschlüssen, allerdings an den 4 anderen Seiten. Jede Seite soll mit 4 Kontakten ausgestattet werden und egal wie herum mit einem anderen "Würfel" kommunizieren können. Wenn ich jetzte die Anordnung der 4 überall gleich anlege habe und den anderenwürfel waagerecht um 180° drehe, sind die Anschlüsse gespiegelt. Das Drehen um 180° muss in jeden Fall möglich sein Falls es Probleme gibt, könnte man ja auch immer noch auf 5 Pins ausweichen, die Pins sind ja später mal fest im Gehäuse verbaut. Bei folgender Anordnung: SDA/SCK, 5V, GND, 5V, SDA/SCK würde es ja keine Probleme mit der Spannung geben. 5 Pins sollten auch noch akzeptabel sein. georg schrieb: > 2. Steckverbinder mit mehr als 4 Pins und symmetrischer Belegung. Ja den Ansatz hatte ich auch schon, allerdings sollten nicht mehr als 5 Pins belegt werden, bzw. die Herausforderung besteht darin genau dieses "Problem" zu beheben. georg schrieb: > zumindest SDA ist bidirektional. Kann dein Mux > beide Richtungen? Glaube ich nicht. Das Signal muss nur von dem "Slave" Nano zum "Master" Nano geschickt werden, eine Bidirektionale Kommunikation ist daher zum Glück nicht nötig. Arduino Fanboy D. schrieb: > Aber es ist dir schon klar, dass du dann keinen gemeinsamen GND mehr > hast .... Ja wie schon gesagt, ich denke die Versorgungspinns werde ich wie oben erwähnt, spiegeln. Das hat einfach deutlich mehr Vorteile und würde eben auch nur einen Pin mehr ergeben.
und wenn du 8 pins nebeneinander nimmst oder 4x2? also vcc | scl | sda | gnd | gnd | sda | scl | vcc oder vcc | scl | sda | gnd gnd | sda | scl | vcc
NumiX schrieb: > Das Signal muss nur von dem "Slave" Nano zum "Master" Nano geschickt > werden, eine Bidirektionale Kommunikation ist daher zum Glück nicht > nötig. So tief steckst du im Irrtum!?!? Der Slave kann von sich aus nichts zum Master schicken. Die Transaktion geht immer vom Master aus. Beide Partner zucken und ruckeln an SDA und SCL. Die Kommunikation ist bidirektional. Immer! Tipp: Mache dich kundig, wie I2C funktioniert.
NumiX schrieb: > > Das Signal muss nur von dem "Slave" Nano zum "Master" Nano geschickt > werden, eine Bidirektionale Kommunikation ist daher zum Glück nicht > nötig. Informiere Dich mal über das I2C-Protokoll. Die "Kommunikation" ist schon durch das ACK-Bit quasi Bi-Direktional. Fazit: Suche Dir eine Lösung mit symmetrischen Stecker (wie oben mehrfach vorgeschlagen).
Sven A. schrieb: > und wenn du 8 pins nebeneinander nimmst oder 4x2? > > also > > vcc | scl | sda | gnd | gnd | sda | scl | vcc Da würden 7 Pins reichen ;-) [GND|SCL|SDA|Vcc|SDA|SCL|GND]
Eric B. schrieb: > Da würden 7 Pins reichen ;-) ich hab auch noch nichts optimiert - das wäre erst der nächste schritt gewesen :-D
Sven A. schrieb: > und wenn du 8 pins nebeneinander nimmst oder 4x2? > > also > > vcc | scl | sda | gnd | gnd | sda | scl | vcc > > oder > > vcc | scl | sda | gnd > gnd | sda | scl | vcc Geht leider beides nicht da es zu viele Stecker sind. Beim letzteren habe ich die Anschlüsse ja immer noch verpolt wenn ich den den Würfel drehe. Arduino Fanboy D. schrieb: > So tief steckst du im Irrtum!?!? > > Der Slave kann von sich aus nichts zum Master schicken. > Die Transaktion geht immer vom Master aus. > > Beide Partner zucken und ruckeln an SDA und SCL. > Die Kommunikation ist bidirektional. > Immer! > > Tipp: > Mache dich kundig, wie I2C funktioniert. Master und Slave war vor dem Hintergrund der I2C Diskussion vielleicht falsch gewählt. Ich hatte es extra in Anführungszeichen gesetzt. Mit "Master" meine ich den Nano der am USB bzw Steckdose hängt, als "Slave" den, der am "Master" dranhängt. Im I2C sind beide als Master angemeldet. Das Funktioniert bisher auch wunderbar. Wenn immer nur der eine Master an den anderen Master schickt, ist die Kommunikation doch nicht Bidirektional?
NumiX schrieb: > Beim letzteren > habe ich die Anschlüsse ja immer noch verpolt wenn ich den den Würfel > drehe. würdest du darauf wetten?
NumiX schrieb: > Wenn immer nur der eine Master > an den anderen Master schickt, ist die Kommunikation doch nicht > Bidirektional? Ich fürchte das ist ein vollkommen hoffnungsloser Fall. Georg
Wenn die Datenübertragung über einen Eindrahtbus läuft, dann kommst du mit 3 Kontakten aus. vcc/bus|gnd|vcc/bus Der "master" (aka das Element über das die Energieversorgung erfolgt) entscheidet welcher Pin vcc und welcher der bus ist. Die "slaves" schleifen beide Pins direkt durch und ziehen bei beiden mit einer Schottky Strom ab (der master liefert einfach ~5,3V aus um den Abfall auszugleichen). Nach dem Poweron "horcht" jeder Slave auf beiden "Hybridpins" nach dem Datenburst des Master. Wenn er den gesehen hat, dann weiß er welcher der beiden Pins der Bus ist und welcher nur Versorgung. Ab dann muss er nurnoch dem Bus zuhören und (falls benötigt) eine Rückmeldung liefern indem er selber den Bus zieht (ähnlich Onewire). Wenn man zwischen I/O und "Hybridpins" einen Widerstand (~0,5k) schaltet, dann darf sich der Slave auch vertun damit welcher pin bus ist ohne kurzschluss. ESD bei Berührung und dgl. musst du eh noch mit entsprechenden bauteilen abfangen.
NumiX schrieb: > ist die Kommunikation doch nicht > Bidirektional? Doch ist sie! Osi Level 1 Hardwareauslegung Bidirektional Osi Level 2 Implementierung des grundlegenden Protokolls. ..... Osi Level 8 Muss nicht wissen, was auf Level 1 bis 7 abgeht. Nur der Spezifikation gemäß benutzen. Sonst Sorgen.
georg schrieb: > Ich fürchte das ist ein vollkommen hoffnungsloser Fall. > > Georg Tut mir leid wenn ich grad erst in das Thema einsteige und mir einige Sachen noch nicht so klar sind wie dir ... Max D. schrieb: > Wenn die Datenübertragung über einen Eindrahtbus läuft, dann > kommst du > mit 3 Kontakten aus. > > vcc/bus|gnd|vcc/bus > > Der "master" (aka das Element über das die Energieversorgung erfolgt) > entscheidet welcher Pin vcc und welcher der bus ist. > Die "slaves" schleifen beide Pins direkt durch und ziehen bei beiden mit > einer Schottky Strom ab (der master liefert einfach ~5,3V aus um den Wenn ich den Vorschlag richtig verstehe, dann aber der Arduino Nano das Problem, dieser dieser kann keine Daten auf dem Versogungspin einlesen. Sprich er würde es gar nicht merken wenn die Datenleitung Verorgungspin anliegt. Ich hab mir ja auch schon überlegt, ob das ganze sich Softwareseitig lösen lässt,je nachdem wie deie Spannungsversorgung anliegt, i2c auf anderen Pins am Nano ausgegeben wird, leider sind die jedoch HW-Seitig definiert un könen über Software nicht geändert werden. Sofern der Demux auch nicht funktioniert (aufgrung der bidirektionalität) muss ich wohl auf Senkrechte anschlüsse setzen, eine Drehung des Bauteils (Waagerecht) hätte dann ja keine Auswirkungen auf die Anordnung der Pins. Eigentlich sollte sowas vermieden werden aber scheinbar gibt es ja sonst leider keine vernünftige Lösung. Ideal wäre eigentlich sowas wie ein mechanischer Switch ähnlich einer Weiche, der je nach Zustand, den Eingang mit Ausgang 1 oder Ausgang 2 direkt verbindet.
Du hast 2 I/Os dem Bus zugewiesen (nenen wir mal links und rechts). Jeder dieser I/Os kann entweder bus oder Versorgung sein. Der uC weiß am Anfang noch nicht welcher Pin zum Bus gehört, deswegen wartet er am Anfang ab bis der Master den Bus über ein Datenpaket kenntlich macht. Danach hast du einen eindraht Bus auf welchem deine Kommunikation läuft. Wenn die datenrate entsprechend dezent ist, dann kann man es problemlos in Software in einem interrupt machen.
Ordne die Kontakte einfach senkrecht in der Mitte der Seiten an. Dann kannst du die Würfel drehen wie du willst, voraus gesetzt, Ober- und Unterseiten sind definiert, d.h. ein Würfel sollte nicht mit der Unterseite nach oben liegen.
NumiX schrieb: > Das Drehen um 180° muss in jeden Fall möglich > sein Es gibt 4-polige Klinkenstecker, die kannst Du beliebig drehen.
Angehängte Dateien:
Max D. schrieb: > Du hast 2 I/Os dem Bus zugewiesen (nenen wir mal links und rechts). > Jeder dieser I/Os kann entweder bus oder Versorgung sein. > Der uC weiß am Anfang noch nicht welcher Pin zum Bus gehört, deswegen > wartet er am Anfang ab bis der Master den Bus über ein Datenpaket > kenntlich macht. Danach hast du einen eindraht Bus auf welchem deine > Kommunikation läuft. Wenn die datenrate entsprechend dezent ist, dann > kann man es problemlos in Software in einem interrupt machen. Das klingt auf jeden Fall interessant, ich werde mir das mal weiter anschauen. Was haltet ihr eigentlich von diesem analogen Mux im Anhang ? Dadurch, dass er analog arbeitet sollte er doch bidirektional funktionieren und ist somit doch genau das was ich gesucht habe.
TCA9548A Aber sach doch mal.... Woher kommt eigentlich deine Fixierung auf I2C ? Auf mich macht es den Eindruck, als wolltest du eine Fehlentscheidung, mit Gewalt durchdrücken.
Den TCA9548A hatte ich ganz zu Anfang auch auf dem Schirm, wir hatten uns aber gedacht, dass es doch irgendwas einfaches geben muss, was "maßgeschneiderter" wäre. Ich meine, dass er damals auch extrem lange lieferzeiten hatte. Der wäre natürlich auch eine gut Option. Es geht um ein Projekt in der Uni mit mehreren Kommilitonen. Von mir kommt die I2C Festlegung nicht, allerdings funktioniert es einwandfrei damit bisher. Warum ist des denn eine Fehlentscheidung?
Kleines Update zum (De-)mux, vielleicht hat ja jemand ein ähnliches Problem. Der CD4052BE funktioniert hervorragend, keinerlei Problem mit den I2C Signalen.
NumiX schrieb: > Es geht um ein Projekt in der Uni mit mehreren Kommilitonen. Von mir > kommt die I2C Festlegung nicht, allerdings funktioniert es einwandfrei > damit bisher. Warum ist des denn eine Fehlentscheidung? Wenn eine Anforderung lautet "Steckverbindungen müssen auch gedreht funktionieren" dann ist es ungünstig, etwas auszuwählen, das eine eindeutige Zuordnung verlangt - jedenfalls wenn man das nicht über eine symmetrische Steckverbindung erledigen will. Sieh dir z.B. Gigabit Ethernet an, da wird Crossover automatisch erkannt. Falls es aber eine Projektvorgabe war, dann solltet ihr sicherlich dieses Problem selbst lösen und nicht auch eine fertige Lösung (wie eben GE) zurückgreifen. Dafür ist die Uni ja da. ;-)
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.