Guten Morgen allerseits Ich beschäftige mich gerade mit der Schnittstelle I2C und frage mich gerade, ob die Teilnehmer am Bus immer I2C fähige Teilnehmer sein müssen. Die müssen ja sozusagen die gleiche Sprache sprechen. Wie macht man es aber, wenn man 2 Geräte hat, die nicht I2C fähig sind und trotzdem I2C nutzen möchte. Also es gibt einen Controller, der I2C fähig ist, aber 2 Geräte die es nicht sind. Gibt es da ICs mit denen man die Geräte als I2C fähige Teilnehmer kennzeichnen kann? Vielen Dank
I2C ist ein Protokoll ... keine Fähigkeit. Entweder spricht ein Device auf dem Bus dieses Protokoll und liefert ebenso verständliche Antworten, oder eben nicht.
Martin schrieb: > Wie macht man es aber, wenn man 2 Geräte hat, die nicht I2C fähig sind > und trotzdem I2C nutzen möchte. Man braucht einen Umsetzer von I2C auf nicht I2C - was auch immer das ist. Die Geräte selbst werden nie I2C nutzen können, solange sie nicht über eine I2C-Schnittstelle verfügen. > Gibt es da ICs mit denen man die Geräte als I2C fähige > Teilnehmer kennzeichnen kann? Mit Kennzeichnung hat das nichts zu tun, sondern mit Protokollfähigkeit.
Ralf G. schrieb: > I2C ist ein Protokoll ... keine Fähigkeit. > > Entweder spricht ein Device auf dem Bus dieses Protokoll und liefert > ebenso verständliche Antworten, oder eben nicht. Hallo Ralf Das ist mir klar. Vielleicht habe ich die Frage nicht klar gestellt. Meine Frage ist: Kann man die Geräte, die über keine I2C Schnittstelle verfügen, nicht durch ICs die es auf dem Markt gibt, mit einer Adresse versehen, sodass sie angesprochen werden können. Man könnte das ja durch zusätzliche Prints machen?
Martin schrieb: > nicht durch ICs die es auf dem Markt gibt, mit einer Adresse > versehen, sodass sie angesprochen werden können. Gibt es, nennt sich µC. Die meisten von denen können auch als I2C-Slave programmiert werden und mit der passenden Software auch recht viele andere Protokolle auf der "anderen Seite" bedienen.
Klar geht das! Ich hab das mal für nen ATMEGA 8 gemacht und dem das I2C Protokoll beigebracht. Danach steht es dir frei alles weitere mit dem Mega8 zu machen. Auch als ein Interface zu anderen Devices.
Martin schrieb: > Meine Frage ist: Kann man die Geräte, die über keine I2C Schnittstelle > verfügen, nicht durch ICs die es auf dem Markt gibt, mit einer Adresse > versehen, sodass sie angesprochen werden können. Was verstehst du unter "mit einer Adresse versehen"? Das Teil muss I²C verstehen. Wenn es das nicht tut, brauchst du eine Art Umsetzer, also etwas, das I²C versteht und es auf das umsetzt, was das Teil versteht. Eine Adresse reicht dafür nicht. > Man könnte das ja durch zusätzliche Prints machen? Prints?
Peter D. schrieb: > Z.B.: > https://www.nxp.com/products/peripherals-and-logic/signal-chain/bridges/ic-bus-to-spi-bridge:SC18IS602B Die Notlösung ist ein kleiner uC, gibt es aber auch einfach ein IC der i2c hat und nichts anderes tut und nur über Adresskonfigurationspins verfügt
Martin schrieb: > Kann man die Geräte, die über keine I2C Schnittstelle verfügen, Hier musst Du zwingend ein Beispiel nennen oder eine Anwendung oder "Geräte" einschränken. Beliebige Geräte erfordern beliebige Lösungen.
Ich habe einige Objekte, die ich unterscheiden möchte, wenn ich sie an ein Arduino anschließe, indem ich jedem Objekt eine eindeutige ID gebe. Derzeit verwende ich ein Potentiometer für jeden Objektsatz mit unterschiedlichen Werten, damit Arduino jedes Objekt voneinander unterscheiden kann - wenn jedes an einen analogen Eingang angeschlossen wird. Dies ist nur eine primitive Lösung zum Testen, aber das Problem ist natürlich die Anzahl der Eingänge (kann nicht viel erweitert werden) und die Art und Weise, wie IDs mechanisch eingestellt werden (ich meine von Hand, einen "zufälligen" Wert am Potentiometer einstellen). . Gibt es ICs oder ICs, die ich kombinieren könnte, um das Hinzufügen, Bearbeiten von IDs durch I2C festlegen kann? Es muss I2C sein.
Ralf G. schrieb: > Klar geht das! Ich hab das mal für nen ATMEGA 8 gemacht und dem das I2C > Protokoll beigebracht. Das konnte der im Wesentlichen schon vor deinen Bemühungen. Der hat (wie alle Megas) schließlich ein entsprechendes Hardwareinterface, bloß dass dieses bei Atmel aus lizenztechnischen Gründen halt TWI heisst. Als Slave ist der in Software zu implementierende Rest des Protokolls wirklich minimal. Im Prinzip muss man nur mitkriegen, ob man aktuell Transmitter oder Receiver (oder nix davon) ist und dementsprechend auf Anforderung Bytes ausliefern oder abholen, wenn man halt Transmitter oder Receiver ist. Und man muss als Transmitter die ACKs des Master checken oder als Receiver die eigenen passend übermitteln, um das Ende der Transaktion mitzubekommen bzw. zu erklären. Das war's schon. Hochtrivial, wenn man die Funktionsweise des Protokolls erstmal verstanden hat. Sollte man zumindest meinen... Problematisch wird die Sache allerdings durch die unzähligen kaputten I2C-Implementierungen, deren "Verfasser" die Sache offensichtlich nicht richtig verstanden hatten. Als Slave muss man sich allerdings nur mit einem einzigen Problem aus der vielfältigen Auswahl rumschlagen: Mit Mastern, die Clock-Stretching nicht beherrschen. Dann hilft dann nur eins, schnell genug sein, also: ASM. Und nichtmal dies hilft immer, nur bei passender Umgebung und passenden Randbedingungen...
Martin schrieb: > Gibt es ICs oder ICs, die ich kombinieren könnte, um das Hinzufügen, > Bearbeiten von IDs durch I2C festlegen kann? Es muss I2C sein. Google nach "i2c unique id" und du wirst erschlagen von Angeboten. Mit/Ohne RAM, EEPROM, RTC, ...
Martin schrieb: > Ich habe einige Objekte, die ich unterscheiden möchte, wenn ich sie an > ein Arduino anschließe, indem ich jedem Objekt eine eindeutige ID gebe. > Gibt es ICs oder ICs, die ich kombinieren könnte, um das Hinzufügen, > Bearbeiten von IDs durch I2C festlegen kann? Es muss I2C sein. http://ww1.microchip.com/downloads/en/devicedoc/Atmel-8807-SEEPROM-AT24MAC402-602-Datasheet.pdf Jeder Chip hat da eine einzigartige ID unlöschbar einprogrammiert. fchk
c-hater schrieb: > Als Slave muss man sich allerdings nur mit einem einzigen Problem aus > der vielfältigen Auswahl rumschlagen: Mit Mastern, die Clock-Stretching > nicht beherrschen. Das ist richtig, aber es ist auch in 99% aller Fälle schnurz, weil in eben diesen 99% als Slaves nur fertige Dinge wie EEProms, Displays und andere fertige Peripherie benutzt wird (die alle ohne Clockverlängerung auskommen) und der besagte µC dann eben immer der Master ist. Allerdings ist das Problem des TO ("Ich beschäftige mich gerade mit der Schnittstelle I2C") wohl eher sein rein theoretisches Verständnis und nicht irgend ein tatsächlicher Anwendungsfall. W.S.
Martin schrieb: > Vielleicht habe ich die Frage nicht klar gestellt. > Meine Frage ist: Kann man die Geräte, die über keine I2C Schnittstelle > verfügen, nicht durch ICs die es auf dem Markt gibt, mit einer Adresse > versehen, sodass sie angesprochen werden können. Klar geht das wenn man Glück hat und den passenden Adapter findet. Das z.b. ist einer meiner Lieblingsadapter. https://eckstein-shop.de/IIC-I2C-SPI-Serial-Interface-Modul-for-1602-2004 Mit den Steuere ich immer meine Displays an. Aber es ist wie alles auf der Welt. Du brauchst einen Konverter / Umwandler der beide "Sprachen/Protokolle" kann und als Übersetzer sein Job macht.
Moin, Martin schrieb: > Die Notlösung ist ein kleiner uC, gibt es aber auch einfach ein IC der > i2c hat und nichts anderes tut und nur über Adresskonfigurationspins > verfügt Vielleicht reicht schon so ein kleines, 8 beiniges I2C-EEPROM. Das kannste einmal programmieren, z.b. mit einer Seriennummer (ggf. verschluesseltem Hash) und die dann immer auslesen. Oder wenns schon am programmieren der EEPROMS scheitert: die haben oft auch ein paar Adressselectpins. Dann machst du die Unterscheidung nur nach der Adresse, wo sich was meldet. Ist halt nicht so arg sicher und geht fuer max. 8 verschiedene Teilnehmer. Gruss WK
Andi schrieb: > Martin schrieb: >> Gibt es ICs oder ICs, die ich kombinieren könnte, um das Hinzufügen, >> Bearbeiten von IDs durch I2C festlegen kann? Es muss I2C sein. > > Google nach "i2c unique id" und du wirst erschlagen von Angeboten. > Mit/Ohne RAM, EEPROM, RTC, ... Bin vorher schon fündig geworden. Vielen Dank trotzdem Für alle anderen: Ich habe I2C schon verstanden, nur bringt es mir nichts, wenn die Geräte, die ich nutzen will nicht die selbe Sprache sprechen, sondern komplett blöd sind und damit auch SPI nicht können. Die müssen im Prinzip nur bekannt geben, ob sie da sind (angeschlossen sind) oder nicht. Dazu benötigen sie einfach einen Namen in Form einer Adresse, mit der sie angesprochen werden können. Die Lösung ist eben denen nicht kommunikationsfähigen Geräten etwas zu spendieren, die die komplette I2C-Sprache abnehmen. Da sind solche EEPROMS wie Wie Andi schon richtig vorgeschlagen hat, super. Vielleicht habe ich das nicht so deutlich rüber gebracht. Aber danke trotzdem an alle.
Martin schrieb: > Die müssen im Prinzip nur bekannt geben, ob sie da sind (angeschlossen > sind) oder nicht. Diese wichtige Info hast du allerdings anfangs verschwiegen.
Martin schrieb: > Die müssen im Prinzip nur bekannt geben, ob sie da sind (angeschlossen > sind) oder nicht. Dazu benötigen sie einfach einen Namen in Form einer > Adresse, mit der sie angesprochen werden können. Jo, mei. Diese Information, nämlich dass du eigentlich nur einen "Presence-Detection"-Dummy willst, der mit der eigentlichen Gerätefunktion rein garnix zu tun hat, hätte als allerestes in dein allererstes Posting gehört. So ein Ansatz ist ja schließlich nicht ehrenrührig, z.B. macht die gesamte Display-Industrie es mit EDID so. Aber das zeigt andererseits eigentlich auch schön, dass dein Konzept ziemliche SCHEISSE ist. Du solltest wenigstens so clever sein, es auf dem Level von EDID (antürlich mit deinen eigenen Strukturen) abzuhandeln und nicht auf dem Level von I2C-Adressen... Von letzterem gibt es schließlich nur 127 und praktisch alle davon sind bereits vielfach durch existierende Hardware bzw. das Protokoll selber "belegt".
Martin schrieb: > Es muss I2C sein. Also eine Hausaufgabe? Sonst wäre can dafür das sinnvollste, quasi beliebig viele Objekte konfliktfrei. Wie viele Objekte sollen denn gleichzeitig erkannt werden? Und wie vermeidest Du Adresskonflikte (falls mehr als 1)? Im einfachsten Fall kannst Du kleine eeproms nehmen, mit 3 konfigurierbaren Adressbits, also bis 8 verschiedene. Dann brauchst Du ins eeprom nichts reinschreiben um sie unterscheiden zu können.
Bitte 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.