Hallo, ich habe vor eine 7-Segmentanzeige (inkl. I2C-Controller) von einem µC aus anzusteuern. Es handelt sich um dieses Modell: https://learn.adafruit.com/adafruit-led-backpack/1-2-inch-7-segment-backpack# Das sollte ja eigentlich ganz einfach sein, ist es aber nicht... Meine Verkabelung ist wie folgt: - GND an den GND meines µC - VCC an 5V - IO-VCC an 3,3V (mein µC läuft mit 3,3V) - SCL und SDA an die entsprechenden Pins meines Controllers Die Verkabelung habe ich nachgemessen, und es sieht so weit alles gut aus (5V, 3,3V liegen an). Als Code habe ich erst mal das Arduino-Beispiel von Adafruit hergenommen, um zu sehen ob alles tut. Doch leider bleibt das Display aus, es ist nix zu sehen :-( Ich habe dann mit dem Logic-Analyzer auf SCL und SDA geschaut (siehe Bild). Allerdings kann ich damit (da ich mich mit I2C noch nicht so auskenne) nicht viel anfangen. Hat jemand eine Idee, woran es liegen könnte? Oder zumindest was ich noch prüfen könnte?
Angehängte Dateien:
-
7Segment.jpg
170 KB
:
Bearbeitet durch User
Deine 5V und 3,3V haben auch die gleiche Masse bzw. sind deren Massen verbunden? Edit: Seltsam... Müsste da nicht auch irgendwann ein ACK vom Display zurückkommen?
:
Bearbeitet durch User
Ja, die liegen gegen die gleiche Masse an. Stephan S. schrieb: > Edit: Seltsam... Müsste da nicht auch irgendwann ein ACK vom Display > zurückkommen? Ich würde mal vermuten ja. Das NAK im Logic-Analyzer würde ich so deuten, dass kein ACK vom Display kommt. Aber da bin ich wie gesagt vorerst mit meinen I2C-Kenntnissen am Ende.
:
Bearbeitet durch User
So sieht es aus. Poste doch mal dein Beispielprogramm hier, dann können wir mal sehen, was passiert. Denn die Übertragung sollte schon ein bisschen mehr enthalten.
Borislav B. schrieb: > Ich würde mal vermuten ja. Das NAK im Logic-Analyzer würde ich so > deuten, dass kein ACK vom Display kommt. Aber da bin ich wie gesagt > vorerst mit meinen I2C-Kenntnissen am Ende. Die richtige Adresse gesendet ? Laut DaBla können 8 verschiedene Adressen eingestellt werden.
Das NAK bedeuted, dass das Display nicht antwortet. Das kann diese ursachen haben: - Die Adresse ist falsch, das Display hat eine andere >> siehe Datasheet - Das Display hat kein Strom
Markus M. schrieb: > - Die Adresse ist falsch, das Display hat eine andere >> siehe Datasheet > - Das Display hat kein Strom Einen hast du vergessen ;-) - Das Display ist kaputt Aber das will ich ja mal nicht hoffen. Also Strom hat es, das habe ich ja bereits nachgemessen. Die Adresse sollte per Default 0x70 sein. Das ist auch das, was das Beispiel benutzt (siehe Anhang).
1. Als Erstes wird die sog. Primäradresse vom master gesendet, nur wenn sie vom Slave als sein eigenes erkennt wurde, zieht der Slave die SDA-Linie nach unten ,als ack. stimmt die Primäradresse mit der des slave überein? Hier wird zweimal nacheinander $E0 ausgegeben? 2. Änderungen auf SDA dürfen nur vorkommen wenn SCL auf low ist. Auf dem Scope ist dies nicht genau erkennbar. 3. Start und Stop sind auch zwischen den zwei Datenwörtern, es sind also zwei unabhängige Telegramme, mit denen $E0 ausgegeben wird. Es wäre ganz gut, eine Programmschleife zu schreiben, die inc... = 0....255 ausgibt, und beim Eintreffen eines ACK-Zustands stehen bleibt. Damit findet man heraus, welche Primäradresse der angeschlossene Slave hat. Oder halt per Hand alle möglichen Slave-Adressen durchprobieren, bis die richtige erwischt ist.
Als Erstes wird die sog. Primäradresse vom master gesendet (hier $E0=224). Nur wenn sie vom Slave als seine eigene erkannt wurde, zieht der Slave die SDA-Linie beim 9. Takt (pos. Flke) nach unten ,als ack. Stimmt die Primäradresse mit der des slave überein? Hier wird zweimal nacheinander $E0 ausgegeben? Das ist eigentlich sinnlos. Start und Stop sind hier auch zwischen den zwei Datenwörtern, es sind also zwei unabhängige Telegramme, mit denen $E0 ausgegeben wird. wenn das erste byte die Primäradresse sein sollte und das zweite Daten oder eine Sekundäradresse wäre das zwischen-stop-start natürlich falsch. Es wäre ganz gut, eine Programmschleife zu schreiben, die start,(inc.adr. =) 0....255, stop ausgibt, und beim Eintreffen eines ACK-Zustands stehen bleibt. Damit findet man heraus, welche Primäradresse der angeschlossene Slave hat. Oder halt per Hand alle möglichen Slave-Adressen durchprobieren, bis die richtige erwischt ist.
Danke für die Erklärungen! Mir ist gerade noch aufgefallen, dass die gemeldete Adresse (224) genau das doppelte der eingestellten Adresse ist (0x70 bzw. 112). Zufall? Entweder zeigt der Analyzer Mist an, oder... Die anderen Adressen (0x70 bis 0x77 sind möglich) habe ich übrigens auch ohne Erfolg ausprobiert. Es kommt kein Ack :-(
:
Bearbeitet durch User
> Mir ist gerade noch aufgefallen, dass die gemeldete Adresse (224) genau > das doppelte der eingestellten Adresse ist (0x70 bzw. 112). > Zufall? > Entweder zeigt der Analyzer Mist an, oder... Das ist schon richtig. Die Adresse wird in den Bits 7..1 übertragen, Bit 0 ist das R/W-Bit.
Rainer B. schrieb: > Das ist schon richtig. Die Adresse wird in den Bits 7..1 übertragen, Bit > 0 ist das R/W-Bit. Ah, ok. Also geht tatsächlich die richtige Adresse auf den Bus. Da ich alle in Frage kommenden (0x70 - 0x77) ausprobiert habe, muss das Problem also ein anderes sein. Die Spannungen habe ich ja bereits gemessen, also sollte mit der Versorgung alles OK sein. Bleibt nur noch ein Defekt :-/ Dagegen spricht wiederum, dass das Modul vor einigen Wochen schon mal lief (an einem anderen Aufbau), und seit dem nur in der Ecke lag. Da sollte also nichts dran gekommen sein..
PullUp-Widerstände an SDA und SCL hast du eingebaut? Oder sind auf dem 7S-Modul verbaut? Ansonsten probier mal je 10k-20k zwischen SDA und SCL und Vio.
Die Adresse 70-hex ist binär 0111 000 und 112-dez und nicht, wie oben angezeigt, E0-hex also 1110 0000-bin und 224-dez Vielleicht liegts daran?
Peter R. schrieb: > Die Adresse 70-hex ist binär 0111 000 und 112-dez > > und nicht, wie oben angezeigt, E0-hex also 1110 0000-bin und 224-dez > > Vielleicht liegts daran? Rainer B. schrieb: > Das ist schon richtig. Die Adresse wird in den Bits 7..1 übertragen, Bit > 0 ist das R/W-Bit.
gesendet wird aber beim I2C das MSB zuerst. (meines Wissens und auch bei Deinem Salea logic-analyzer ablesbar der zeigt ja 224 ). Das MSB ist bei E0h eine 1 und bei 70h eine 0 Das von Dir erwähnte R/W-Bit ist das LSB, also das letzte bit der 8 bits. bring den master halt mal dazu, ein 112dez = 70h auszugeben, sodass es der analyzer auch anzeigt.
Peter R. schrieb: > Das MSB ist bei E0h eine 1 und bei 70h eine 0 I2C-Adressen sind bei der 7-Bit-Adressierung nur 7-Bit breit! Also 0x00-0x7f. Und da Adresse vor dem R/W bite gesendet wird, wird aus Adresse 0x70 plus Write-Bit genau 0xE0. Guckst du hier: http://rn-wissen.de/wiki/index.php?title=I2C#Aufbau_einer_7-Bit-Adresse
:
Bearbeitet durch User
SDA und SCL vertauscht? Alle möglichen Adressen durchprobiert? (0x70 .. 0x77)?
Joe F. schrieb: > SDA und SCL vertauscht? > Alle möglichen Adressen durchprobiert? (0x70 .. 0x77)? Habs schon rumgedreht (mehrmals) ;-) Rainer B. schrieb: > PullUp-Widerstände an SDA und SCL hast du eingebaut? > Oder sind auf dem 7S-Modul verbaut? > Ansonsten probier mal je 10k-20k zwischen SDA und SCL und Vio. Die sollten schon drauf sein. Hab noch mal manuell welche hinzugefügt, holft aber auch nix...
Gibt's vom 7-Segment-Modul einen Schaltplan? Und mach doch mal ein Foto von deinem Aufbau, auf dem die gesamte Verkabelung zwischen Arduino und 7S-Modul erkennbar ist. Und eine Aufnahme der Rückseite des 7S-Moduls (also die Seite, auf der der IC und das Hühnerfutter klebt).
Borislav B. schrieb: > Die Verkabelung habe ich nachgemessen, und es sieht so weit alles gut > aus (5V, 3,3V liegen an). Immer diese Selbstüberschätzung. Muss da nicht noch ein Pegelwandler in die Signale? Borislav B. schrieb: > - IO-VCC an 3,3V (mein µC läuft mit 3,3V) > - SCL und SDA an die entsprechenden Pins meines Controllers Was sind denn "entsprechende" Pins und welcher Controller? In der Kurzbeschreibung steht aber (Will not Run with 3,3V). Dann wäre es auch kein Wunder. Borislav B. schrieb: > Hat jemand eine Idee, woran es liegen könnte? > Oder zumindest was ich noch prüfen könnte? Mach erst mal korrekte Angaben(z.B. zum Displaytyp) und lege einen Schaltplan vor. Das ist nämlich usus hier.
Peter R. schrieb: > bring den master halt mal dazu, ein 112dez = 70h auszugeben, sodass es > der analyzer auch anzeigt. Der Analyser zeigt nicht die Adresse an, sondern den Wert des Bytes. Wenn die Adresse 0x70 ist, muss folglich - je nachdem R/W - entweder 0xE0 oder 0xE1 übertragen werden. Was willst du da mit 70h?
Peter R. schrieb: > Als Erstes wird die sog. Primäradresse vom master gesendet (hier > $E0=224) Nö. Eine I²C Adresse hat nur 7 Bit. Rainer B. schrieb: > PullUp-Widerstände an SDA und SCL hast du eingebaut? Zumindest erkennt der LA Signale auf dem Bus. Der LA zeigt 2x STA + Adresse 70h + Write + NACK + STO Das ist soweit korrekt, wenn die Adresse stimmen sollte. (Zumindest vom Controller aus) Und dann sollte das Display auch antworten. Dass es falsch angeschlossen ist, sagst Du, ist auszuschließen. Spannung hat es auch. idR. sollte das Display 3,3V auch als H interpretieren. Borislav B. schrieb: > https://learn.adafruit.com/adafruit-led-backpack/... Ähm, ist das so ein Ding zum selber zusammenbasteln? Was ist das für ein Controller darauf? Benötigt der Software? Wenn ja, hat er sie bekommen? Wenn nein, hat das Ding eine Bezeichnung? Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Was ist das für ein Controller darauf? https://cdn-shop.adafruit.com/datasheets/ht16K33v110.pdf Jobst M. schrieb: > Benötigt der Software? Wenn ja, hat er sie bekommen? Borislav B. schrieb: > Als Code habe ich erst mal das Arduino-Beispiel von Adafruit > hergenommen,
:
Bearbeitet durch User
Jobst M. schrieb: >> https://learn.adafruit.com/adafruit-led-backpack/... > > Ähm, ist das so ein Ding zum selber zusammenbasteln? > Was ist das für ein Controller darauf? Da ist vermutlich ein HT16K33 verbaut, ein 16*8 Treiber. https://cdn-shop.adafruit.com/datasheets/ht16K33v110.pdf Edit: Ups, da war Leo schneller als ich?
:
Bearbeitet durch User
Leo C. schrieb: > Jobst M. schrieb: >> Benötigt der Software? Wenn ja, hat er sie bekommen? > > Borislav B. schrieb: >> Als Code habe ich erst mal das Arduino-Beispiel von Adafruit >> hergenommen, Das scheint die SW für den Master zu sein. Ich meinte aber die SW für den Controller am Display. Aber nun kann ich mir das selbst anschauen, wie das Ding arbeitet. Gruß Jobst
... welcher der 3 Chips ist es? Gibt es einen Schaltplan zu dem Displaymodul? Ich habe auf der Seite nichts finden können. Gruß Jobst
Cyborg schrieb: > Immer diese Selbstüberschätzung. > Muss da nicht noch ein Pegelwandler in die Signale? Hö? Selbstüberschätzung? Sowohl der µC als auch das Display arbeiten übrigens mit 3,3V Logik. Jobst M. schrieb: > Ähm, ist das so ein Ding zum selber zusammenbasteln? > Was ist das für ein Controller darauf? > Benötigt der Software? Wenn ja, hat er sie bekommen? > Wenn nein, hat das Ding eine Bezeichnung? Jein. Ich habe ein fertig verlötetes bekommen. Und das lief vor 3 Wochen auch schon mal ;-) Der Controller da drauf ist ein HT16K33.
Borislav B. schrieb: > Der Controller da drauf ist ein HT16K33. Ja. Welcher? 20, 24 oder 28 Pins? Und: Jobst M. schrieb: > Gibt es einen Schaltplan zu dem Displaymodul? Gruß Jobst
Borislav B. schrieb: > Sowohl der µC als auch das Display arbeiten übrigens mit 3,3V Logik. Der HT16K33 laut Datenblatt aber nicht:
1 | Operating voltage: 4.5V~5.5V |
Jobst M. schrieb: >> Gibt es einen Schaltplan zu dem Displaymodul? Findet man auf der Adafruit Seite (runterscrollen): https://learn.adafruit.com/adafruit-led-backpack/downloads
Angehängte Dateien:
-
IMG_20161112_152507.jpg
260 KB
Zitat aus dem Adafruit-Tutorial: Due to the size of this display, there are 2 LEDs in series for each segment. Because of this, the display requires 5v to run. It will not run on 3.3v. For use with 3.3v processors, connect the IO pin to 3.3v. This will keep the I2C bus signals at a safe level for your processor. With 5v processors like the Arduino UNO, this pin can be connected to either 5v or 3.3v. (use 3.3v if there will be other 3.3v devices on the bus) Connections for 3.3v Processors: D -> SDA C -> SCL + -> 5v - -> GND IO -> 3.3v Sollte also passen. Ich gehe mittlerweile von einem Defekt des Displays aus. Die Platine ist nämlich kräftig gebogen (wurde wohl vom unglaublichen China-Hulk verlötet). Würde mich nicht wundern, wenn da irgendwo Haarrisse entstanden sind...
Borislav B. schrieb: > Connections for 3.3v Processors: > D -> SDA > C -> SCL > + -> 5v > - -> GND > IO -> 3.3v Wenn überhaupt, funktioniert das höchstens zufällig. High-Pegel an SCL und SDA muß laut Datenblatt mindestens 0,7*Vdd betragen, also >= 3,5 Volt.
Leo C. schrieb: > Wenn überhaupt, funktioniert das höchstens zufällig. High-Pegel an SCL > und SDA muß laut Datenblatt mindestens 0,7*Vdd betragen, also >= 3,5 > Volt. Hmmm... Würden die Jungs/Mädels von Adafruit das tatsächlich als 3,3V kompatibel verkaufen, wenn es garnicht funktionieren kann? Das würde mich wundern ;-) Ich dachte eigentlich der IO Pin wäre genau dafür da die Kommunikations-Spannung vorzugeben....
>Würden die Jungs/Mädels von Adafruit das tatsächlich als 3,3V kompatibel >verkaufen, wenn es garnicht funktionieren kann? Das würde mich wundern ;-) Sieht aber in der Tat danach aus! Das ominöse Vio ist lediglich die Versorgung für die IC2-Pullups, nix mit komplizierter Levelshifter-Mimik für I2C. Sorgt halt nur dafür, dass SDA und SCL auf max. Vio gezogen werden. Sorgt aber nicht dafür, dass der LED-Treiber wirklich seine lt. Spec minimal erforderlichen mehr als 0,7*Vdd für Hi-Signal bekommt. Wie oben bereits gesagt, das funktioniert dann nur zufällig, aber nicht sicher. Hast du denn deinen erfolgreichen Test letztens auch mit 3V3 Signalen gemacht oder mit einem 5V-Prozessor? Wenn du die Möglichkeit dazu hast, probier die Ansteuerung nochmal mit 5V-Prozessor aus. Dann kannst du zumindest ausschließen, dass es an einem zu geringen High-Level auf SDA und SCL liegt. Defekte Leitungen: Einfach prüfbar: Vdd, Vss, SDA und SCL einmal bis zu den Pins am 7S-Treiberbaustein durchklingeln. Wenn diese 4 Leitungen Durchgang haben, dann sollte das ausreichen, damit der Treiberbaustein über I2C antwortet.
Joa, mit einem alten Arduino Uno der hier noch rumflog tut es tatsächlich! Vorher hatte es zwar auch schon mal mit dem 3,3V Controller geklappt, aber das war dann wohl Zufall. Danke euch für die sachdienlichen Ratschläge! Dann muss ich mal schauen, wie ich aus den 3,3V des Controllers 5V mache ;-)
Borislav B. schrieb: > Dann muss ich mal schauen, wie ich aus den 3,3V des Controllers 5V mache > ;-) http://www.aliexpress.com/item/Free-shipping-3-3V-5V-TXS0108E-8-Channel-Logic-Level-Converter-Convert-TTL-Bi-directional-Mutual/32413364906.html
Manfred schrieb: > http://www.aliexpress.com Delivery Time:30-50days ROFL. Nimm 2 FETs und baue den von Phillips empfohlenen Billo-Levelshifter auf: http://www.nxp.com/documents/application_note/AN10441.pdf
:
Bearbeitet durch User
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.