LCD I2C ATmega32 initialisieren

[Marcus M. (marcusm)]

Hallo zusammen,

ich verzweifle, seit fast zwei Monaten, an der eigentlich recht 
einfachen Aufgabe ein LCD über den I2C-Bus ans laufen zu bringen.

Ich habe die Libary von Nico und Thomas Eichelmann (i2clcd) und die 
benötigte i2cmaster von Peter Fleury eingebunden.
Pin-Belegung und Adresse habe ich entsprechend angepasst.
Der µC ist ein ATmega32, CPU-Takt: 8MHz (wird für die spätere Anwendung 
gebraucht).
Aktuell habe ich zwei Displays von Reichelt im Test (20x4 und 16x2), 
keins davon will mit mir arbeiten. Davor hatte ich auch schon ein 
China-Display erfolglos getestet.
Nach dem Einschalten habe ich die Standardansicht, in der man den 
Kontrast einstellen kann (nachStart.jpg). Rufe ich die 
lcd_init()-Funktion auf, gehen alle Zeilen aus (nachProgramm.jpg).
Jedoch bekomme ich weder den Cursor zum Blinken noch irgendetwas 
angezeigt.
Die Initialisierung habe ich auch schon nach Datenblatt aus dem Internet 
selbst nachgebaut, jedoch mit dem gleichen Ergebnis.
Versuche ich einen String auszugeben ("Hi World"), geht die 
Hintergrundbeleuchtung aus. Die kann ich dann durch schreiben von 0x80 
wieder einschalten.

Abschlusswiderstände des Busses habe ich auch schon verändert. Mit dem 
Oszilloskop sehen die Signale mit 500Ohm sehr gut aus, mit 1k und 2k 
habe ich aber genauso wenig Erfolg.
Ich teste mit dem Atmel Evaluations-Board und einem Steckbrett. 
Programmierung mit Atmel-Studio 7

Meine main.c:

#define F_CPU 8000000

#include <util/delay.h>
#include "i2cmaster.h"
#include "i2clcd.h"

int main(void) {
  //  Bus initialisieren
  i2c_init();
  //  Display initialisieren
  lcd_init();

  unsigned char string[] = "Hi World";
  lcd_print(string);

  lcd_command(LCD_DISPLAYON | LCD_CURSORON | LCD_BLINKINGON);

  // Display Hintergrundbeleuchtung ein
  i2c_start_wait(LCD_I2C_DEVICE+I2C_WRITE);
  i2c_write(0x08);
  i2c_stop();

  while(1) {
  }          //-  Endless loop

}

Die benutzten Bibliotheken habe ich angehängt.
Ich habe schon soviel in Google gesucht, aber keine Lösung für mein 
Problem gefunden. Vielleicht kennt einer das Problem oder weiß so was 
ich da falsch mache.

Vielen Dank
Marcus

Edit: Sorry. Ein Foto habe ich versehentlich zweimal hochgeladen.

[Jobst M. (jobstens-de)]

In zips wird Dir hier niemand reinschauen.
Außerdem ist es einfacher, hier einfach mal in die Datei schauen zu 
können, als das erst entpacken zu müssen ...


Gruß

Jobst

[Christian S. (roehrenvorheizer)]

Hallo,

Niemand konnte erkennen, daß Du mit den ZIP-Dateien lediglich die 
originalen Bibliotheken, die Du gefunden hast, zeigst. Das ist zu 
erkennen, wenn niemand dort hinein schaut.

Allerdings hast Du nicht Dein gesamtes Projekt mitgeschickt, so daß 
freiwillige mal schauen könnten, was Du da programmiert hast.

Läuft Dein Mega 32 sicher mit dem Takt, den Du im Programm eingestellt 
hast?
Wo stellst Du die I2C-Adresse ein?
Welche Taktfrequenz hat das TWI?
Hast Du die .h Dateien angepaßt?
Hast Du TWI-Interrupts frei gegeben. Steht irgendwo sei (); ?
Wird überhaupt Ack empfangen nach Übertragung der Adresse des Slaves.
Erkennst Du das ACK auf Deinem Oszilloskopbildschirm?
Hast Du verstanden, wie die Fleury-Lib funktioniert?

Anhand von dem main.c kann man keine Aussage treffen.

Natürlich hätte es auch direkt funktionieren können und jeder hätte sich 
gefreut...

Mit freundlichem Gruß

[Joe F. (easylife)]

Marcus M. schrieb:
> Abschlusswiderstände des Busses habe ich auch schon verändert. Mit dem
> Oszilloskop sehen die Signale mit 500Ohm sehr gut aus, mit 1k und 2k
> habe ich aber genauso wenig Erfolg.

2.2K ist vollkommend ausreichend. 500 Ohm bedeutet 10mA bei einem 5V Bus 
-> viel zu viel.

Welche Bitrate benutzt du? <=100 KHz? Am Oszi überprüfen!

Versorgungspannungen Display, uC?

[Peter D. (peda)]

Du mußt anfangen zu debuggen und nicht rumraten.
Dazu teilt man die Aufgaben auf. D.h. prüfe zuerst das I2C oder das LCD 
für sich, ob es läuft. Erst dann kannst Du beides verheiraten.

Wozu man für I2C Assembler braucht, ist mir ein Rätsel. Nimm besser ne 
C-Lib.

Bei 32 IO-Pins würde ich jetzt auch nicht so den Sinn darin sehen, 4 
Pins zu sparen und das LCD lieber direkt an 6 Pins anschließen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Marcus M. schrieb:
> Versuche ich einen String auszugeben ("Hi World"), geht die
> Hintergrundbeleuchtung aus. Die kann ich dann durch schreiben von 0x80
> wieder einschalten.

 Ohne deinen Program und Bibliotheken angeschaut zu haben:

 Hintergrundbeleuchtung einschalten und String ausgeben sind
 2 paar Schuhe.

 Noch einmal genau prüfen was du alles geändert hast.

[Einer K. (Gast)]

Äääähhhmmm....

Es gibt keine I2C Displays dieser Art.
Ist mir zumindest noch nicht untergekommen.

Aber es gibt I2C Huckepack Adapter, auf solchen LCDs.
Und von der Sorte gibts mindestens 4 verschiedene.
Mit mindestens 3 verschiedenen Belegungen.

Also ist zu klären:
Welcher Adapter ist es?
Oder besser: Welche Belegung hat dieser Adapter?

Siehe dazu: https://arduino-info.wikispaces.com/LCD-Blue-I2C


Marcus M. schrieb:
> Versuche ich einen String auszugeben ("Hi World"), geht die
> Hintergrundbeleuchtung aus.

Ein klares Indiz dafür, dass die Belegung anders ist, als erwartet.

[Marcus M. (marcusm)]

Vielen Dank für die zahlreichen Tips.

Ich werde, sowie ich kann mich damit beschäftigen und weitere fehlende 
Infos nachliefern.

Der ATmega steuert schlussendlich ein Roboterfahrzeug (Schulprojekt) und 
mit dessen Peripherie habe ich schon zu viele I/Os verbraucht, um das 
Display parallel anzuschließen.
Aktuell teste ich die Komponenten nacheinander auf dem Evaluationboard.

Der ATmega läuft tatsächlich mit 8Mhz (über FUSE-Binsgesamt eingestellt.
Die Adresse stelle ich in der i2slcd.h ein. Das ACK bekomme ich.
Die Taktrate werde ich messen. Offensichtlich weiß ich noch viel zu 
wenig, was die Fleury-Lib macht. In Assembler kenne ich leider noch 
nicht. Wenn Projekt rum ist, will ich mir das noch aneignen.

Die Versorgungsspannung sind jeweils 5V und die Widerstände werde ich 
entsprechend anheben.

Natürlich nutze ich die Displays mit der Huckepackplatine für i2c.
Im voraus habe ich die Huckepackplatine mit Fleury-Lib getestet und 
konnte z.b. die angesteuerten Ausgänge problemlos messen.
Das Display

Ich werde nochmal mit den originalen Libs neu anfangen.
Und entsprechende Informationen nachreichnen.

Vielen Dank
Marcus

[Joe F. (easylife)]

Marcus M. schrieb:
> Im voraus habe ich die Huckepackplatine mit Fleury-Lib getestet und
> konnte z.b. die angesteuerten Ausgänge problemlos messen.

Da bist du ja schon einen guten Schritt weiter.
Ich würde trotzdem zur Sicherheit nochmal die I2C Geschwindigkeit mit 
dem Oszi prüfen. >100KHz kann gut gehen, muss aber nicht.

Der Fehler liegt dann wohl eher nicht auf I2C Seite (wenn du die 
Huckepack-Platine erfolgreich ansteuern konntest), sondern in der 
Ansteuerung des Displays.
Manchmal fehlt nur ein bestimmtes Kommando, um z.B. einen 
Spannungsregler einzuschalten oder auf die passende Bias-Spannung 
einzustellen. Solange da was nicht stimmt, kann es sein, dass schon 
Zeichen auf dem Display landen, man sieht sie aber nicht.

Da wirst du dann wohl das Datenblatt des Displays studieren müssen, und 
gucken, was die Lib an Kommandos rausschickt.
Einfacher wird es, mit einem Logic-Analyzer die I2C Kommandos, oder den 
parallel-Bus des Displays abzugreifen und zu gucken, ob die übertragenen 
Daten dem Datenblatt zufolge Sinn machen.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Marcus M. schrieb:
> Ich werde nochmal mit den originalen Libs neu anfangen.

Du benutzt 'i2cmaster.S' wenn du einen AVR ohne TWI Interface benutzt 
oder Pins, die vom TWI abweichen.
Wenn du ein Hardware TWI im AVR hast und dessen Pins auch frei und 
benutzbar sind, kannst du 'twimaster.c' einbinden.
Das entsprechende File fügst du zu deinen Sourcefiles hinzu.

Bei der Benutzung des Soft-I2C denke daran, in i2cmaster.S die benutzten 
Pins und Ports zu definieren. Das ist bei twimaster.c nicht nötig, da 
die Pins ja klar sind.
Meiner Erfahrung nach sind die Libs narrensicher, wenn sie einmal 
richtig eingestellt sind.

[Christian S. (roehrenvorheizer)]

Hallo,

gut, den I2C-Portbaustein kannst Du ansteuern. Dann liegt es vermutlich 
nur noch an der Ansteuerung des LCDs.

Es besteht noch die Möglichkeit, die LCD-Routinen mittels Wartezyklen zu 
verlangsamen, falls das Display nicht schnell genug mit kommt. Evtl 
klappt die Ansteuerung der LCD-Lib nicht richtig. Dort müssen auch die 
Pins richtig zugeordnet sein.

Mit freundlichem Gruß

[Patrick J. (ho-bit-hun-ter)]

Hi

Hab's jetzt nur überflogen und denke, daß Du ein Problem mit der 
Ansteuerung des LCD hast.
Mein LCD wird per I²C auf der Adresse $27 angesprochen, das Display 
selber wird 4-bitig angesteuert, wobei die Datenbits die Bits 7-4 sind.
Bit 3 ist die Hintergrundbeleuchtung
Bit 2 E
Bit 1 RW
Bit 0 RS
und sollte folgender 'AddOn'-Platine entsprechen:
eBay: I2C Serielle Schnittstelle Modul für LCD Display 1602 IIC SPI TWI 
Arduino
eBay-Nr.: 221717504003
(gibt's dort auch zu besserem Preis)

Dafür passt folgende Lib:
// Get the LCD I2C Library here:
// https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads
// Move any other LCD libraries to another folder or delete them
// See Library "Docs" folder for possible commands etc.

Enthalten sind dann auch einige Beispiele ... hab ich eben gesehen :/
(bin mit dem Arduino noch nicht so grün ... )

MfG

[Marcus M. (marcusm)]

Guten Morgen zusammen,

vielen Dank für die Hilfen.
Letztendlich hat mir der Hinweis zu Software und Hardware TWI geholfen. 
Hatte bisher nicht gecheckt, dass man das auch nachbilden kann.
In der Fleury-Lib hatte ich PORT und PINs angepasst, so dass es zum 
Hardware-TWI passte. Hardware-TWI will ich ja benutzen.

Ich habe mich dann auf die Suche nach neuen Librarys gemacht und eine 
Kombi von Davide Gironi gefunden. Die beiden Libs entsprechend auf meine 
Adresse und Pin-Belegung angepasst und siehe da, die Ausgaben erscheinen 
auf dem Display...

Patrick J. schrieb:
> // https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads

Deinen Link kann ich nicht öffnen, sonst hätte ich das auch mal 
ausprobiert.

Den Bus werde ich morden trotzdem nochmal messen.
Ich verstehe nur noch nicht, warum ich beim testen der Huckepack-Platine 
keine Probleme hatte, mit Display aber schon.
Mit ein bisschen mehr Zeit werde ich mir das nochmal genauer ansehen.

Nochmal vielen herzlichen Dank

Gruß
Marcus

[Christian S. (roehrenvorheizer)]

Am nächsten Tag schon Erfolg!

MfG

[Patrick J. (ho-bit-hun-ter)]

Hi

Hmm, hatte extra das Gelump aus der Lib rauskopiert.

https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home

Das sollte dann aber passen - hab dieses Mal sogar draufgeklickt und es 
kam sogar was :)

MfG