Hi, wenn ich zum Beispiel einen ATmega mit einem LCD verbinden möchte der I2C unterstützt kann ich dann auch selber zwei I/O Pins benutzen und zu I2C machen? Warum braucht man da extra Schnittstellen? Wo ist eigentlich der unterschied zwischen TWI und I2C? Vielen Dank! Guten Tag
@ Hurricane Bilbo (Gast) >Hi, wenn ich zum Beispiel einen ATmega mit einem LCD verbinden möchte >der I2C unterstützt kann ich dann auch selber zwei I/O Pins benutzen und >zu I2C machen? Ja. >Warum braucht man da extra Schnittstellen? Weil die ggf. schneller und komfortabler sind. >Wo ist eigentlich der unterschied zwischen TWI und I2C? I2C ist die originale Bezeichnung von Phillips, TWI die nicht patentrechlich geschützte von Atmel. Siehe I2C. Ein SS (slave select) Signal gibt es bei I2C nicht, dort wird alles über die Buskommunikation adressiert. SS gibt es nur bei SPI.
Oh entschuldigung wegen SS. Damit war auf jeden fall erstmal Schnitstelle gemeint. D.h Atmel muss eventuell auch geld für die nutzung von i2c schnittstellen bezahlen. I2C Schnittstellen würde ich auch gerne mal im Datenblatt im Detail sehen. ich finde auf Anhieb nur Expander. Aber damit ich mal den Unterschied zwischen TWI und I2C anschauen kann wäre es gut die beiden Schaltungen der Port genau anzuschauen... Gibt es denn auch LCD Displays die man mit TWI betreiben kann? Vielen DANK!
Hurricane Bilbo schrieb: > Gibt es denn auch LCD Displays die man mit TWI betreiben kann? Ja, es gibt sogar LCD-Display-Anzeige-Bildschirme.
@ Hurricane Bilbo (Gast) >Oh entschuldigung wegen SS. Ignorier die Idioten. >D.h Atmel muss eventuell auch geld für die nutzung von i2c >schnittstellen bezahlen. Nein. Eben weil sie es TWI und nicht I2C nennen, müssen sie keine Lizenzgebühren zahlen. >Unterschied zwischen TWI und I2C anschauen kann wäre es gut die beiden >Schaltungen der Port genau anzuschauen... Es gibt keinen! Technisch sind sie identisch! >Gibt es denn auch LCD Displays die man mit TWI betreiben kann? JA! Alle!
Hi,
>Warum braucht man da extra Schnittstellen?
braucht man nicht. Du kannst auch mit I/O-Pins im Handbetrieb
I2C machen.
Die Schnittstelle hat einfach den Vorteil, dass du Sende- und
Empfangsregister hast, die du lesen und schreiben kannst.
Also musst du dich nicht um das serialisieren (Tx)
bzw. deserialisieren (Rx) kümmern und hast i.d.R. auch einen
Empfangsinterrupt.
Gut habe das auch in einem Atmel Datenblatt gefunden: >The Two Wire serial Interface (TWI) is compatible with Philips' I2 >C protocol. The >bus was developed to allow simple, robust and cost effective communication >between integrated circuits in electronics. Ok, danke. Das heißt also dass es relativ einfach ist , bei 6 Freien Pins 3 I2C Geräte dranzuhängen? Das wäre ja praktisch :D
Oder eigentlich braucht man doch nur 2 Pins und kann bis zu 128 Geräte dranhängen. >The strengths of the TWI bus includes >the capability of addressing up to 128 devices on the same bus, arbitration, >and the >possibility to have multiple masters on the bus.
Hurricane Bilbo schrieb: > Ok, danke. Das heißt also dass es relativ einfach ist , bei 6 Freien > Pins 3 I2C Geräte dranzuhängen? Da I2C/TWI ein Bus ist, reichen für drei Geräte sogar zwei Pins. Voraussetzung ist aber, dass man jedem Gerät eine andere Adresse zuweisen kann.
>Oder eigentlich braucht man doch nur 2 Pins und kann bis zu 128 Geräte >dranhängen. Theoretisch. - Beschränkungen sind die Adressen der IC, es kann verschiedene ICs mit der gleichen Adresse geben. - Beschränkung ist die Hardware, die muß 128 ICs treiben (Kapazitäten Leitungslängen)
Danke. Mal schauen ob man auch selber zwei PINS mit TWI programmieren kann um dann mehrere Geräte zu betreiben. Sollte ja eigentlich funktionieren. Vielen Dank!
> die muß 128 ICs
Einige Adressen sind reserviert.
z.B. die 0 für den "General Call"
Auch belegen viele Bausteine mehrere Adressen.
127 Bausteine ist also arg/zu optimistisch!
Einen IC2 master in reiner Software zu programmieren, ist ziemlich simpel. Die Slaves sind aufwändiger, weil die ständig auf Signale lauschen müssen (oder Interrupts verwenden). Aber selbst das ist immer noch deutlich einfacher, als eine serielle (UART) Schnittstelle zu emulieren.
Stefan U. schrieb: > Die Slaves sind aufwändiger, weil die ständig auf Signale lauschen > müssen Das Problem dabei ist, dass sie das auch noch schnell genug tun müssen. Zumindest auf eine fallende Clock Flanke müssen sie schnell genug reagieren, und selber Clock auf Low halten (clock stretching) - danach können sie sich dann Zeit lassen.
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.