Problem mit LCD-Display (HD44780)

Hallo! Habe ein Powertip LCD-Display, 4x20 Zeichen und einen C167 µC. Wenn ich das Display anschließe, leuchten überhaupt nur die erste und dritte Zeile (Kontrast läßt sich hier regeln), die anderen beiden bleiben weiß. Jeder Versuch, dem Display einige Zeichen zu entlocken, schlug bisher fehl. Hat vielleicht zufälligerweise jemand einen C++ Sourcecode für den den C167er für ein solches oder ähnliches Display mit HD44780-Controller? Danke, Harry

Reply to
Harald Laufner
Loading thread data ...

Harald Laufner schrieb im Beitrag ...

Welches ist die haeuftigste gestellte Frage in dieser NG ? Mit welchem Thema befassen sich die absolut meisten von Hobbyelektronikern erstellten WebSeiten ? Warum liest man nicht erst die FAQ und folgt dann dem darin enthaltenen Link

formatting link
(Handbuch für alfanumerische) wenn man Problem mit dem Zeug hat ?

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
 Click to see the full signature
Reply to
MaWin

alfanumerische)

Das Dokument kenne ich, allerdings hat es mir nicht wirklich weitergeholfen. LG Harry

Reply to
Harald Laufner

Ja. Um das Busy-Flag nicht abfragen zu müssen, warte ich lang genug.

5ms zB sollten ausreichend sein.

Zuerst im 8-Bit Modus an Port 6 die Daten und an Port 2 RS, RW und E. Dann im 4-Bit Modus alles an Port 6.

"cooles" C++

Freilich, warum auch nicht? C++ wurde schließlich, so wie die meisten anderen höheren Programmiersprachen auch, erfunden, um nicht alles in Assembler coden zu müssen. Wenn Du lieber in Assembler schreibst, sei Dir das freigestellt. Aber bitte räume anderen die Freiheit ein, in C++ zu programmieren. Für konstruktive Hilfe bin ich übrigens dankbar. LG Harry

Reply to
Harald Laufner

Wie hast Du das Display denn an den C167 angeschlossen? Direkt am Bus ist der C167 wohl zu fix für das Display... Wenn Du den Zugriff per Port-Bit-Bangig machst, dann solltest Du Dir die Timingdiagramme mal genau ansehen und nachbilden (falls Dich C++ nicht daran hindert).

MaWin hat Dir ja schon ein Dokument genannt, da solltest Du Kapitel 2.2.2. mal ganz genau durchlesen und die in den Diagrammen angegebenen Zeit sklavisch (eher etwas länger) einhalten, denn bei der Initialisierung ist der HD44780 sehr pingelig. Hilfreich ist hier ein Scope um das ganze auch mal direkt nachzuprüfen. Ich kenne Deine Software-Entwicklungsumgebung nicht und weiß daher nicht "wie nahe Du an der HW" programmieren kannst und wie Du exakte Timings abschätzen/einhalten kannst.

Da ich den C167 nicht in C/C++ programmiere gibts auch keine Code von mir sondern nur einen freundlichen Gruß und lass den Kopf nicht hängen, das Datenblatt vom HD44780 haben wir alle fressen müssen ;-)

Ingolf

PS: Irgendwo in der PC-Welt wird der HD44780 doch auch für die Case-Modder und PC-Videorecorder-Bauer mit C/C++ betan, oder?

--
Ingolf Pohl
Reply to
Ingolf Pohl

Ich hab da was, das hier auf einem M16C läuft (2x20 Zeichen). In initDipslay() wird voher noch der D/A-Wandler für die Kontrasspannung eingestellt. Im Grunde mußt Du nur die beiden letzten Funktionen ReadDevice() und WriteToDevice() an Deine Ports anpassen. Vorraussetzung ist natürlich, dass Dein Timing funktioniert. P0 ist der Datenbus, P1_1 ist E, P2_1 ist RS und P2_0 ist R/W. pdXX sind die Direction register und puXX sind pull-up register.

Tschö Dirk

Display.h

----------------------------------------------------------------------------------------------- #ifndef BT22008_H #define BT22008_H

#include #include

/* constants for initialising and controlling the lcd */ #define INSTRUCTION 0x00 #define DATA 0x01 #define FUNCTION_SET 0x38 #define DISPLAY_CLEAR 0x01 #define ENTRY_MODE 0x06 #define DISPLAY_ON 0x0F #define DISPLAY_SHIFT 0x1C #define BUSY_FLAG 0x80 #define FIRST_LINE 0x80 #define SECOND_LINE 0xC0

/* "Lcd_Status" options */ #define LCD_OK 0x01 #define LCD_UPDATE 0x02 #define LCD_BUSY 0x04 #define LCD_INITIALISE 0x08 #define LCD_QUEUE 0x10

#define HEX(d) (d < 10 ? 48 + d : 55 + d)

void initDipslay( void); void writeDipslay( void); void WriteToDevice( unsigned char, unsigned char ); char ReadDevice( unsigned char ); void CheckIfBusy( void );

#endif

----------------------------------------------------------------------------------------------------

Display.c

---------------------------------------------------------------------------------------------------- #include "sfr62.h" #include "Display.h"

//declare memory mapped variables extern unsigned char ucTextBuf[2][20]; extern void delay_ms( unsigned int delay);

void initDipslay( void) { unsigned char i; unsigned int j; const unsigned char InitialiseTable[] = {FUNCTION_SET,FUNCTION_SET,FUNCTION_SET, FUNCTION_SET, DISPLAY_ON, DISPLAY_CLEAR, DISPLAY_SHIFT, ENTRY_MODE};

pd9_3 = 1; /* Port 9_3 set to output (D/A channel 0) */ da0 = 255; /* init D-A value to 0 */ da0e = 1; /* enable d-a converter 0 */

delay_ms(15); WriteToDevice( InitialiseTable[0], INSTRUCTION ); delay_ms(4); for ( i=1; i

Reply to
Dirk Ruth

Es gibt aber noch andere Timings außer das BUSY-Flag. z.B Müssen bestimmte SETUP und HOLD Zeiten eingehalten werden.

Sollte beides gehen...

Aber gerade bei embedded Systeme oder auch uC-Schaltungen wird der Speicherbedarf enorm durch den C++ overhead strapaziert.

Ich verwende Assembler nur für die LOW LEVEL TREIBER wie z.B. für die Treiber um das LCD-Display anzusteuern. Da kann ich mir das Timing (mit dem Du höchst wahrscheinlich Probleme hast) aus den Taktzyklen zusammen rechnen und brauche nicht irgendwelche delay() oder wait() Funktionen aufrufen....

Du darfst gerne in C++ programmieren. Nur manchmal wird C++ auch überbewertet. Da werden sämtliche Funktionen gekapselt hier ein Objekt erstellt das dann wiederum als Vorlage für eine Abstraktion genommen wird weil doch nicht alle Memberfunktionen das Richtige Verhalten haben ....

Du kannst natürlich auch sagen das Du in C++ programmierst und letztlich doch nur C-Standard(einfache Funktionen, keine Objekte (außer "strucs")) verwendest.

In meinen Augen macht C++ bei Datenbanken und grafischen Oberflächen (KDE, Windows) einem das programmieren leichter aber bei kleinen uC-Schaltungen (und hierzu zähle ich auch einen 16Bitter) ist es meiner Meinung nach vollkommen übertrieben.

Natürlich darf jeder in der Sprache programmieren die er für Richtig hällt. Egal ob es BASIC, C, C++, Fortran, Pascal, Delphi oder auch Assembler ist. Ich werde z.B. auch öfters ausgelacht weil ich einen AVR z.T. in C programmiere (bis auf LOW LEVEL Funktionen) nur weil andere meinen C ist vollkommen übertrieben. Ich habe aber keine lust mich Stundenlang damit zu beschäftigen wie ich die Speicheraufteilung und wie ich die Register verwende. Das überlasse ich dann doch lieber dem Compiler ... und der AVR-GCC macht das meiner Meinung nach recht Ordentlich.

Also, mein Tipp schau Dir das Timing am LCD am besten mal mit einem Oszi an und vergleiche das gemessene mit dem gedruckten.

Viele Grüße,

Artur

Reply to
Artur Pundsack

Ich habe nie behauptet das ich C/C++ Programmierer bin. Ich habe lediglich versucht darzustellen das C++ in vielen Fällen vollkommener Blödsinn ist.

Aber laß es mich anders versuchen:

Assembler Programmierer sind die besseren C Programmierer und C Programmierer sind die besseren C++ Programmierer...

.. weil bei jeder nächst höheren Abstraktionsstufe das Wissen (und die Kenntniss) von der Hardware verlohren geht und vom Programmierer auf den Comiler übertragen wird.

Gut, für Datenbanken brauche ich nicht zu wissen welches IC wie funktioniert. Aber es ging hier um die Ansteuerung eines LCDs und das ist nunmal Hardware pur.

Viel Spaß beim Abstrahieren

Artur

Reply to
Artur Pundsack

Das habe ich auch gar nicht gemeint.

Und hier gebe ich Dir sofort Recht. ;-)

--
J"org Wunsch					       Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j/
Reply to
Joerg Wunsch

Das war mal so, aber bei den heutigen Compilern und großer Hardware ist es schon verdammt schwer, optimierteren Assemblercode zu schreiben als ein guter Compiler.

VLIW kann man fast gar nicht mehr im Kopf optimieren.

Das ist zwar noch Big Iron im Vergleich zu uCs, aber die Technik wird ja durchgereicht.

Ansteuerung eines LCD ist auch eigentlich schon weit weg von Hardware. LCD-Displays selbstbauen wäre Hardware... Ok, sag ich als Physiker ;)

Grüße,

--
Jan C. Bernauer
Reply to
Jan C. Bernauer

Hallo,

Google 'c167+hd44780' eingeben, gleich der erste Treffer...? Wenns wirlich nicht klappen sollte mail an mich, ich hab noch irgendwo einen source rumliegen (der IMO aber nicht so elegant über den Adressbus geht, dafür aber keine zusätzliche Hardware braucht).

MfG, Johannes

Reply to
Johannes Schöller

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.