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?
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.
