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?
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?
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.
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 :-(
> 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.
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.
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
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
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
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
;-)
7Segment.jpg
(170 KB)
