Hey Leute,
auf meinem Display sehe ich kein Text, aber man sieht, dass es sich mit
der der "delay" Zeit aktualisiert. (wird kurz dunkler jede Sekunde)
Den Poti kann ich drehen wie ich will. Es ändert sich nichts.
Auch wenn ich das Board anstatt über der PC mit der VIN versorge
Ich möchte mir mit einem Ultraschall Sensor den Abstand angeben lassen.
Den I2C Controller kann ich finden (SDA/SCL richtig angeschlossen)
Das Display ist ein 162F-FC-BC-3LP von DISPLAYTECH
A4 = SDA
A5 = SCL
1
# include <LiquidCrystal_I2C.h>
2
LiquidCrystal_I2Clcd(0x27,16,2);
3
4
// Pins für Senden/Empfangen definieren
5
# define SENDEN 12
6
# define ECHO 13
7
8
// Variable für Zeit und Entfernung initialisieren
9
longZeit;
10
longEntfernung;
11
12
voidsetup()
13
{
14
pinMode(SENDEN,OUTPUT);
15
pinMode(ECHO,INPUT);
16
17
// LCD starten
18
lcd.init();
19
lcd.backlight();
20
}
21
22
voidloop()
23
{
24
// Sender kurz ausschalten um Störungen des Signals zu vermeiden
25
digitalWrite(SENDEN,LOW);
26
delay(10);
27
28
// Signal für 10 Mikrosekunden senden
29
digitalWrite(SENDEN,HIGH);
30
delayMicroseconds(10);
31
32
// Sender ausschalten
33
digitalWrite(SENDEN,LOW);
34
35
// pulseIn → Zeit messen, bis das Signal zurückkommt
Der Datentyp der Berechnung stimmt nicht.
Zeit = pulseIn(ECHO, HIGH);
Entfernung = (Zeit / 2) * 0.03432; <--- Fehler
Zeit und Entfernung sind int32_t Typ. Die Multiplikation mit Float
(0.03432) funktioniert so nicht.
Besser wäre es Entfernung als Float zu deklarieren und Zeit als float zu
casten:
Float Entfernung;
Entfernung = ( (float) Zeit / 2.0 ) * 0.03432;
Schreib mal was zum Display vor dem IF Block und dann drehe am Kontrast
Poti bis sich die Anzeige klar lesen läßt.
Kommentiere das IF Statement und die Klammern weg. Dann müsste irgendwas
angezeigt werden.
Ist das nicht so ein PCF8574 LCD Modul? Kann es sein, dass es komplett
falsch herum angelötet wurde? Bei mir verschwinden die unter dem LCD
Display, wenn ich die anlöte.
Hab jetzt nicht ins DaBla geschaut, aber sieht für mich falsch aus.
Dirk B. schrieb:> LiquidCrystal_I2C lcd(0x27, 16, 2);
Ich vermisse auch #include <Wire.h>
Suche fertige Beispiele, die Initialisierung sieht bei mir anders aus:
Spiele mal den Anhang auf, der ist nicht wirklich sinnvoll, aber damit
sollte sich etwas im Display bewegen. Je nach Version des I2C-Adapters
die Adresse anpassen, Du scheinst ja 0x27 anstatt 3F zu haben.
Timo N. schrieb:> Kann es sein, dass es komplett falsch herum angelötet wurde?
War auch meine erste Idee, aber, wenn man es hinten auflötet, ergibt das
die gleiche Belegung - sollte also passen.
Außerdem gibt es neben dem PCF8574 noch einen PCF8574A. Die Chinesen
sehen das nicht so eng und bestücken, was da ist. Der A-Typ hat einen
anderen Adressbereich, beide Versionen lassen sich auf 8 verschiedene
Adressen jumpern. Es kann auch sein, das die Adresse auf der
Leiterplatte fest verdrahtet ist.
Du tust gut daran, auf dem Arduino temporär einen I2C Scanner zu
installieren und die real verwendete Adresse rauszufinden u. ggf. die
Adresse in deinem Programm entsprechend zu ändern.
Manfred schrieb:> sollte also passen.Auaaaahhh - Bild nochmal angeschaut, Kommando zurück - das I2C-Modul
ist tatsächlich 180° verdreht drauf, so wird das nichts.
Kann man eventuell über dessen Initialisierung lösen, falls es nicht
gestorben ist - die Belegung suche ich jetzt nicht nach.
Manfred schrieb:> Manfred schrieb:>> sollte also passen.>> Auaaaahhh - Bild nochmal angeschaut, Kommando zurück - das I2C-Modul> ist tatsächlich 180° verdreht drauf, so wird das nichts.>> Kann man eventuell über dessen Initialisierung lösen, falls es nicht> gestorben ist - die Belegung suche ich jetzt nicht nach.
Das I2C Modul ist richtig drauf. Ich habe meins vor mir liegen mit dem
identischen LCD Modul und es funktioniert einwandfrei. Die 4 Anschluss
Punkte müssen an der linken oberen Kante sein. Pin1 vom LCD und Pin1 vom
I2C müssen zusammen gelegt werden.
Sehe es Dir nochmals an.
Gerhard O. schrieb:> Das I2C Modul ist richtig drauf. Ich habe meins vor mir liegen mit dem> identischen LCD Modul und es funktioniert einwandfrei. Die 4 Anschluss> Punkte müssen an der linken oberen Kante sein. Pin1 vom LCD und Pin1 vom> I2C müssen zusammen gelegt werden.
Schau mal bei ihm sieht man die Unterseite des Moduls, wenn man von oben
auf das Display schaut. Die Unterseite schaut bei ihm aber über das
Display hinaus.
Bei deinen Bildern ist die Unterseite des Moduls unter dem Display und
von diesem verdeckt (schaut also nicht über die Kante des Displays
raus).
Es ist bei ihm vermutlich falsch draufgelötet.
Er hätte es über die Kante des LCD löten können, wenn dann aber die
ganze bestückte Seite des Moduls nach oben schauen würde.
Timo N. schrieb:> Gerhard O. schrieb:
...
> ganze bestückte Seite des Moduls nach oben schauen würde.
Ich bin nicht sicher was ich bei ihm sehe. Wenn Die PI1 Zuordnung links
nach rechts wie bei mir ist, dann müsste es schon funktionieren. Das
Problem bei seinem LCD Modul ist, dass die Anschlüsse links unten
angeordnet sind und das I2C Modul etwas Abstand braucht wenn es wie
üblich installiert werden soll. Das ist bei ihm aber nicht möglich wenn
keine 10mm Abstands Header verwendet werden. Bei den üblichen LCDs mit
Anschlüssen am linken oberen Ende, könnte man das I2C Modul mit nur
2.5mm Abstand draufloeten.
Gerhard O. schrieb:> Sehe es Dir nochmals an.
Vergleiche mal mein Bild / Dein Bild mit dem im Eröffnungsbeitrag - Dirk
hat das I2C Modul 180° verdreht aufgelötet.
Manfred schrieb:> Gerhard O. schrieb:>> Sehe es Dir nochmals an.>> Vergleiche mal mein Bild / Dein Bild mit dem im Eröffnungsbeitrag - Dirk> hat das I2C Modul 180° verdreht aufgelötet.
Hast recht!
Jetzt fällt mir auf, dass das ein ganz anderes Modul ist. Da müsste man
erst mal wissen auf welcher Basis es beruht. Es gibt auch I2C LCD Module
mit dem MCP23017 drauf. Die Rückseite von meinem Modul sieht gänzlich
anders aus. Es wäre vom T.O. wichtig uns mitzuteilen welches LCD er
verwendet und welches I2C Modul er hat. Ich kenne seines nicht.
Gerhard O. schrieb:> Es wäre vom T.O. wichtig uns mitzuteilen welches LCD er> verwendet und welches I2C Modul er hat.
Spielt das wirklich eine Rolle ;-)
Es entsteht doch schon jetzt eine angeregte Diskussion und jeder kann
seine eigene Displayanbindung vorstellen Modulbeschreibungen oder ein
Foto, auf dem man gar die Pin-Belegung oder den verwendeten I2C
Interface-Baustein erkennen könnte, würde sämtlichen Mutmaßungen den
Boden unter den Füßen wegziehen - wäre doch schade.
Wie gesagt, erst sollte die Kontrastspannung stimmen.
Ich will sehen, dass das Display vor der Initialisierung graue Balken
anzeigt und auch nach der Initialisierung müsste man die Pixel ganz
schwach erkennen können.
Wenn man nicht dahin kommen kann, braucht man gar nicht weiter an der
Software herum fummeln. Eine falsch angeschlossene Platine würde auch
dabei auffallen.
E.Gärtner schrieb:> Der Datentyp der Berechnung stimmt nicht.
Der Datentyp ist OK, die Berechnung auch.
Nachweis:
1
#include<stdio.h>
2
#include<stdint.h>
3
4
longZeit;
5
longEntfernung;
6
7
intmain()
8
{
9
Zeit=6000;// Mikrosekunden
10
Entfernung=(Zeit/2)*0.03432;
11
printf("Entfernung: %ld cm",Entfernung);
12
}
Ausgabe:
Entfernung: 102 cm
Begründung:
Es geht um einen HC-SR04 Sensor. Dessen Ausgangsimpuls ist 58 µs pro
Zentimeter. In meinem Beispiel sind es 6000 µs / 58 = 103 cm. Den
kleinen Rundungsfehler kann man tolerieren.
Gerald B. schrieb:> Außerdem gibt es neben dem PCF8574 noch einen PCF8574A.
Das wird hier nicht der Fall sein, denn er schrieb, dass er das Modul
finden kann (vermutlich mit dem I²C Scanner Sketch).
Ich hatte auch schon Displays, da waren 2 Pins vertauscht.
Genauso erinnere ich nich ganz schwach, das bei einem Modell I2C
Adapterplatinen mußte man eine Datei in der Lib patchen, weil 2 der 3
Schreibsignale vertauscht waren. Ich erinnere mich aber nicht mehr, ob
das die Pollindinger, oder die vom Chinesen waren.
Ich würde systematisch vorgehen:
- Display parallel, ohne I2C zum Laufen bringen (manche Libs können
beides)
Dann I2C drauf, die Kontrasteinstellung beibehalten, Adresse rausfinden
und danach dann ggf. Googeln, ob andere in dieser Konstellation ähnliche
Probleme hatten.
Mitunter vertragen sich auch 2 Libs nicht. Darum immer erst ganz klein
mit "Hello World" anfangen, um derlei Effekte eingrenzen zu können.
Was für ein komischer thread. Richtig rum -falsch rum. Bei meinen Lcds
ist die i2c-Steckleiste an der kurzen Seite des lcd - müsste also
richtig sein.
Fehlersuche systematisieren:
- Erster Test, ob i2c funktioniert. Schreiben von abwechselnd 0b01010101
/0b10101010 mit Delay von 2 Sekunden, so dass man das mit dem Multimeter
messen kann.
Stefan ⛄ F. schrieb:> Wie gesagt, erst sollte die Kontrastspannung stimmen.>> Ich will sehen, dass das Display vor der Initialisierung graue Balken> anzeigt und auch nach der Initialisierung müsste man die Pixel ganz> schwach erkennen können.Gerald B. schrieb:> ... bei einem Modell I2C Adapterplatinen mußte man eine Datei in der Lib> patchen, weil 2 der 3 Schreibsignale vertauscht warenDirk B. schrieb:> Den Poti kann ich drehen wie ich will. Es ändert sich nichts.
Da nützt es überhaupt nichts, an der Software rumzufummeln und über
Skalierungsfaktoren oder Pin-Vertauschungen in der Software
nachzudenken.
Falsche/fehlende Kontrastspannung ist ein Hardware-Fail.
Hallo Stefan,
>> Der Datentyp ist OK, die Berechnung auch.
Wieso funktioniert das eigentlich ? Die Multiplikation hat doch einen
Float Wert.
Ist das ein GCC "Feature" der das automatisch intern als float berechnet
(Überladung) und danach wieder in long konvertiert?
Mit allen anderen Nicht-GCC C-Compilern mit denen ich bis jetzt zu tun
hatte, ginge das nicht. Ich muß wohl lange hinterm Mond gelebt haben;-)
Vorausgesetzt, es ist eine "GCC" Feature, warum erlaubt man das?
Irgendwie sträubt sich in mir alles. Das ist für mich das erste Mal, daß
ich das in einen fremden Code sehe.
Es wäre nett wenn Du mir die Bezeichnung für diese "Feature" benennen
könntest, damit ich die GCC Doku diesbezüglich konsultieren könnte.
Gerhard
Gerhard O. schrieb:> Wieso funktioniert das eigentlich ? Die Multiplikation hat doch einen> Float Wert.
Ja und?
Niemand hindert dich daran, einen Integer mit einem Float zu
multiplizieren und das (Float) Ergebnis dann wieder abgerundet als
Integer zu speichern. Die implizite Umwandlung übernimmt der Compiler.
Das ist kein GCC Feature, sonder C Standard. IMHO verhalten sich alle
Programmiersprachen so ähnlich.
> Mit allen anderen Nicht-GCC C-Compilern mit denen> ich bis jetzt zu tun hatte, ginge das nicht.
Prüfe das nochmal, denn ein C Compiler der sich nicht einmal an den
ältesten C Standard hält, dürfte nicht so heißen.
Gerhard O. schrieb:> Es wäre nett wenn Du mir die Bezeichnung für diese "Feature" benennen> könntest, damit ich die GCC Doku diesbezüglich konsultieren könnte.
Unter "Implicit type casting" sollte man etwas finden. Aber schau nicht
in die GCC Doku, sondern die C Spezifikation, falls du darauf Zugriff
hast.
Moin,
Danke Euch Allen,
Habe wieder was gelernt.
Ich bin jetzt ohne Ausprobieren nun auch nicht sicher, aber beim CCS
geht das bestimmt nicht.
Ich werde es mal beim PIC-CCS, CVavr und Keil Compiler ausprobieren wenn
ich wieder am PC bin. I will be back:-)
Gerhard
grundschüler schrieb:> Was für ein komischer thread. Richtig rum -falsch rum. Bei meinen Lcds> ist die i2c-Steckleiste an der kurzen Seite des lcd - müsste also> richtig sein.
Ach was waren das noch Zeiten als man Pin 1 mit Pin 1 verbunden hat. ;)
Ich jedenfalls schaue seit meiner Jugend IMMER ob ich irgendwo etwas
finde was aussieht wie eine 1. Und bei Kabeln schaue ich das die 1 immer
mit der farbigen Seite verbunden wird.
Ich habe schon locker 10 x diese I2C-Platine an Displays gelötet, und
danach wurde IMMER die i2c-Platine HINTER den Display versteckt.
Ist doch so was von Einfach. 2 Zahnstocher unter die i2c Platine machen,
ein Gummiband drüben zum Fixieren, ein paar Pins anlöten. Gummi
entfernen, und den Rest mal eben anlöten. Dann sitzt das ganze perfekt
gerade und hat kein Kontakt zu anderen Platine. Dauert keine 2 Min. wenn
ich gemütlich arbeite.
Kleine Anmerkung. Man bekommt diese Konstruktion übrigens auch fertig
gelötet inzwischen. z.b. https://www.ebay.de/itm/165071464022
Allein schon aus den Grund weil man da weniger Platz braucht. Es ist
nämlich ein Unterschied ob man 1 cm mehr Dicke hat, oder das Display
einige cm mehr Platz braucht.
Leider denken die Chinesen nicht bei allen Bauteilen so effizient. Die
Elektronik (Pin-Reihe) einer Touch-Platine kotzt mich z.b. voll an. Weil
ich die immer um löten muss.
Und wenn die Platine nicht richtig angelötet ist, dann frage ich mich wo
die beiden Pins hingehen, die den Kontrast regeln ;) Nein, ich bin zu
faul im Datenblatt zu schauen.
B. W. schrieb:> Das Pinout von dem Display scheint nicht so ganz trivial zu sein...> https://docs.rs-online.com/f6e9/0900766b80f5299b.pdf
Die Belegungsreihenfolge ist wie bei den 1602 Chinesen, also nichts
besonderes - vergleiche Datenblatt mit Foto.
Die Falle: Bei den Chinesen sitzt die Anschlußreihe oben links, bei
diesem Display aber unten links.
Also mal messen, ob an 1-2, den beiden linken Pins, die
Versorgungsspannung korrekt anliegt. Unklar bleibt, was für eine
I2C-Platine er dort verwendet hat, die sieht anders als die verbreiteten
Chinesen aus.
Stefan ⛄ F. schrieb:> Gerhard O. schrieb:>> Es wäre nett wenn Du mir die Bezeichnung für diese "Feature" benennen>> könntest, damit ich die GCC Doku diesbezüglich konsultieren könnte.>> Unter "Implicit type casting" sollte man etwas finden. Aber schau nicht> in die GCC Doku, sondern die C Spezifikation, falls du darauf Zugriff> hast.
Hallo Stefan,
ich muss tatsächlich jahrzehntelang hinterm Mond gehaust haben.
Sämtliche embedded Compiler auf dem PC funktionieren. Ich testete CCS-C
für PIC, CVAVR, ZILOG (Z8 enore), Atollic, CoIde, IAR EW und KEIL uV.
Die machen das "Implicit type casting" alle wie von Dir behauptet.
In über zwanzig Jahren hat mich darüber niemand je aufgeklärt und die
zugänglichen Compiler Handbücher schwiegen sich darüber stillschweigend
aus. (Ich durchforschte das CCS Handbuch) Auch in der Firma machte mich
nie ein Kollege darauf aufmerksam, dass das auch so geht. Das ist jetzt
im "großen Forum" sehr peinlich für mich - ist aber so;-)
Mir kam es nie in den Sinn floats mit ints zusammen zu berechnen und
habe in gemischten Datentypen Situationen meist casts verwendet um das
gewünschte Resultat zu erhalten oder von vornherein mit fixed point
gearbeitet. Allerdings war ich fast immer in float Ausgaben
interessiert und da würde man natürlich sowieso keinen int für das
Resultat deklarieren.
So kann es gehen und liege zerschmettert am Boden:-)
Gruß,
Gerhard
B. W. schrieb:> Ich seh schon... die Zahlen sind nur Dekoration.
:-) Wie es aussieht, sind 1...14 umgekehrt, und dann die
Hintergrundbeleuchtung doch noch hintendrangewürgt...
Gruss Chregu
Dirk B. schrieb:> Danke für die vielen Antworten.> Lag wirklich dran, dass 1-14 gedreht sind… So ein Schwachsinn. Aber gut.
Ende gut, alles gut:-) freut mich, daß es jetzt funktioniert.
Der Schwachsinn kommt aber noch schlimmer:
Ich habe ein paar 1601 COG LCD Module im grauen Plastikgehäuse aus alten
HP Druckern gerettet. Hat ein 14-poligen FPC Flachkabel dran. Das Pinout
ist identisch mit der üblichen HD44780 Modul Pin-Belegung, außer dass
VDD und VSS vertauscht sind. Wer das gutgläubig anschließt, wird es
falsch polen.
Wie man auf so eine "Gemeinheit" nur kommt:-) es war gut, daß ich
anfangs die Anschlußplatine durchsah und es gleich bemerkte. Naja, die
Designer werden schon gute Gründe dafür gehabt haben. Vielleicht
verhinderte es eine schwierige Überkreuzung des dünnen FPC Kabels, wer
weiß... Funktioniert einwandfrei als HD44780 Typ.