Moin, Ich würde gerne ein Programm für meinen Atmega schreiben, der mir alle am I2C-Port angeschlossenen Geräte anzeigen kann (also nur die Adresse). Aber hat jemand von Euch eine Idee, wie man so etwas umsetzen kann? MfG, und vielen Dank, Ozzy
Adresse in ner For-Schleife. START, Die Adresse senden und schauen ob ein ACK zurückkommt, STOP. Kommt Ack: Adresse existent. Kommt nix: Kein Slave mit der ID.
Danke, das ist ja einfach... Hat auch noch irgendwer Erfahrungen, wie lange es dauern kann, bis der Slave antwortet?
Naja, sehr lang können sich die Slaves wohl selbst bei 100 kHz nicht lassen. Wenn sie (intern) mehr Zeit brauchen, müssen sie trotzdem reagieren, Stichwort "Clock Stretching". Am besten mal eine Doku lesen. ;-) Denk auch daran, die Schleife zweimal (für kurze und lange Adressen) laufen zu lassen.
Beim I2C gibts neben den normalen 7-Bit-Adressen auch welche mit 10-Bit. Hatt ich aber noch nie. Zudem muss die Schleife da nicht 2x durchlaufen werden, da nur ein Teil der 7-Bit-Adressen auf 10 Bit erweitert wird. Von der Zeitdauer: Ich selber merk im normalen Programm keine Verzögerung, wenn der Slave nicht antwortet. Erkenn ich nur am Rückgabewert einer Send-Funktion.
Michael L. schrieb: > Denk auch daran, die Schleife zweimal (für kurze und lange Adressen) > laufen zu lassen. Was soll das? I²C hat nur 8-Bit von denen die ersten hadcoded auf den Typen des Bausteins sind. Die meisten Chips haben nur 1-2 Adresspins, einige auch 3-4 und diverse haben Tri/Quad-State Adresspins wegen dem Pin-Count... Na viel Spaß damit. Bei NXP gibt es übrigends das I²C Tutorial und weitere nützliche Dokumentation herunterzuladen... Grüße Michelle
Oh je Michelle - Bevor du sowas behauptest, solltest du ordentlich lesen. Die Adressen sind nur 7 Bit lang. Das 8. Bit ist die Kennzeichnung für Schreiben/Lesen, denn dann unterscheidet sich das nachfolgende Protokoll. Desweiteren ist der i2c-Bus auf Kompatibilität mit dem sogenannten CBUS ausgelegt, so daß man über die gleichen Pins beide Bussysteme parallel fahren kann. Der CBUS ist der Vorläufer des i2cBus. Schau mal in alte Valvo-Datenbücher. Es gab mal ne Zeit, da hatte ein Gerät der Unterhaltungselektronik eben gemischte Designs bestehend aus alten CBUS-ICs und 'neueren' i2c-ICs. Es sollte aber absolut billig verkabelt werden können. Der SAA1056 und der spätere SAA1057 sollten in diese Zeit fallen. Wenn ich mich recht erinnere, wird dort sogar noch der CBUS im Datenblatt erwähnt. In der Praxis stößt man allerdings nur auf 7-Bit Adressierung. Die zentrale Adressenverwaltung durch Philips ist auch nicht eindeutig, weil Fremdhersteller nicht die Lizenzen bezahlen wollten und der Adressbereich auch irgendwann zu klein wurde. Dann gibt es noch Broadcast-Adressen usw. Dann gibt es noch den 10ms(??) Timeout beim smBUS, der ein aktualisierter i2c-Bus ist und von Intel eingeführt wurde. Wird viel auf PC-Motherboards benutzt. Er unterscheidet sich auch noch durch weitere Punkte, die Bausteine sind aber prinzipiell auch im i2c-System benutzbar. Das i2c-Patent ist abgelaufen und NXP kümmert sich auch nicht mehr drum. Früher<tm> durfte man nämlich den i2c-Bus nur benutzen, wenn man originale i2c-Bausteine von Philips/Valvo einsetzte! Ein sogenanntes Bit-Banging also Softwareemulation in einem Mikrocontroller als Master war nicht erlaubt. So haben sich findige Fremdhersteller wie Atmel auf neue Namen für den i2c-Bus einfallen lassen: 2-wire usw. Dann gibt es Chips die sehen wie i2c aus, sind es aber nicht, z.B. die von Sensirion. Weiters gibt es viele Microcontroller, die eine generalisierte i/o-Zelle haben, die sowohl SPI, i2c, UART usw. ansteuern kann. Und dann haben wir noch einige mehr oder weniger i2c-Busse, die anders heißen. Irgendwas mit Displaybus usw. Und was wurde aus dem i2c und dem ADB (von Apple)? Ja ja, der USB. Alles schön weiterabgekupfert. Die Eltern von USB sind offensichtlich. Wenn ich länger nachdenke, fällt mir bestimmt noch mehr ein... Gruß - Abdul
Michelle Konzack schrieb: > Michael L. schrieb: >> Denk auch daran, die Schleife zweimal (für kurze und lange Adressen) >> laufen zu lassen. > > Was soll das? Das hättest DU DICH mal selbst fragen sollen! Hättest mal ein wenig mehr lesen sollen, das hilft. ;-) > I²C hat nur 8-Bit von denen die ersten hadcoded auf den Typen des > Bausteins sind. Die meisten Chips haben nur 1-2 Adresspins, einige auch > 3-4 und diverse haben Tri/Quad-State Adresspins wegen dem Pin-Count... Das möchtest du mit dieser zusammengewürfelten Aussage erreichen? Was hat das damit zu tun? Damit stiftest du nur noch mehr Verwirrung. Es ist grundsätzlich erstmal richtig, alle Adressen abzufragen, ganz egal wie bei einem einzelnen Chip die Adresse festgelegt wird! > Na viel Spaß damit. > > Bei NXP gibt es übrigends das I²C Tutorial und weitere nützliche > Dokumentation herunterzuladen... Das ist der erste vernünftige Gedanke. Allerdings hat das, was man bei der Suche nach "I2C Tutorial" findet, mehr den Touch einer BWL-Powerpoint-Präsentation: http://www.nxp.com/acrobat_download/various/philips_i2c_logic_overview.pdf Deshalb würde ich eher die Bus-Spezifikation empfehlen: http://www.standardics.nxp.com/support/documents/i2c/pdf/i2c.bus.specification.pdf http://www.i2c-bus.org/ ist übrigens auch eine gute Quelle. In der Doku wird dem OP bestimmt der Teil über kurze (7 Bit) und lange (10 Bit) Adressen auffallen. Er wird auch etwas über reservierte Adressen lesen, und mit etwas Überlegung darauf kommen, wie man recht einfach feststellen kann, ob überhaupt Chips mit langer Adresse angeschlossen sind. Wenn nicht, kann man sich ja detailiertere Abfragen sparen.
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.