LCD-Lib von P. Fleury für Display mit 2 Controllern

[pyr0skull]

Hallo,

ich benutze in einem Projekt ein 4x40 Zeilen Display von Electronic Assembly (W404B) welches in Bascon zwar funktioniert, sich in C aber nicht richtig zum Laufen bringen ließ (fehlende Unterstützung für 2 Controller, falsche Timings). Ich habe jetzt die Lib von Peter Fleury umgestrickt, so dass das Display funktioniert. Die Frage ist jetzt:

Hat schonmal jemand sowas gemacht und den Code zur Verfügung gestellt? Wenn ja gut, wenn nein, würde ich die gröbsten Grausamkeiten aus dem Code entfernen und diesen hier zur Verfügung stellen.

Weiß da jemand was?

[thewulf00]

Tja, das Display scheint relativ teuer zu sein, so dass es nicht sehr verbreitet sein wird. Daher wäre es sher nett, wenn Du Deinen Code veröffentlichst, dann haben auch zukünftige Sucher einen Anhaltspunkt.

[pyr0skull]

Hi,

ich hab gestern noch etwas rumgeschrieben und dabei folgendes festgestellt: Eigentlich kann der Code bei einigen AVRs nie richtig funktioniert haben, wenn dann eher aus Zufall. Bei der Displayinitialisierung wurden die Ausgänge nämlich vorher in einen undefinierten Zustand versetzt, was entweder funktioniert (weil Ports nach einem Setzen des Ausgangsregisters auf 0 stehen) oder nur so ein bisschen (weil die Ports vor der Displayinitialisierung schonmal genutzt wurden, sei es durch einen Reset mit Flashvorgang oder durch eine vorherige Nutzung der Ports).
Deswegen lief das Display auch ewig nicht, aufgefallen ist mir das dann gestern, nachdem ich die Library schon halb umgekrempelt habe. Damit sollten die Probleme nicht nur bei meinem (zugegebenermaßen recht teuren aber -> ich bezahls ja nicht) Display sondern auch bei einigen anderen behoben sein.

Deshalb werde ich die Library auch so schnell wie möglich hier zum Download anbieten, ich muss das nur noch einigermaßen dokumentieren und konfigurierbar machen.

[thewulf00]

Das solltest Du unbedingt dem Peter mitteilen!

[pyr0skull]

Gute Idee, ich hab ihm deshalb gerade mal eine E-Mail geschrieben. Wär ja klasse, wenn er das in die nächste Version mit aufnimmt ;)

[sternst]

Bei der Displayinitialisierung wurden die Ausgänge nämlich vorher in einen undefinierten Zustand versetzt,

Erklär doch mal, was du damit genau meinst. Bei AVRs existiert für die IOs kein "undefinierter" Zustand.

[pyr0skull]

Undefiniert ist vielleicht unglücklich ausgedrückt. Die Ports werden nach dem Aktivieren nicht auf den Status geprüft, es werden einfach Bits nach und nach gesetzt. Bei der Displayinitialisierung werden z.B. die Bits für DB4 & DB5 auf High gesetzt. Da beim Atmega die Ports nach Aktivierung alle auf High stehen, liegt auf DB6 und DB7 auch ein High-Signal an, obwohl das nicht sein darf.

[sternst]

Da beim Atmega die Ports nach Aktivierung alle auf High stehen

Und was meinst du jetzt mit "Aktivierung"?
Nach einem Reset ist der Inhalt der Register 0.

[pyr0skull]

Ich meine damit die Konfigurierung der Ports als Ausgang..

[sternst]

Wenn vorher nichts in das PORT-Register geschrieben wurde, dann ist der Ausgang Low.

[fhs]

Hallo,


... es werden einfach Bits nach und nach gesetzt. Bei der Displayinitialisierung werden z.B. die Bits für DB4 & DB5 auf High gesetzt.
OK, so geht man doch immer beim Initialisieren vor, oder?


Da beim Atmega die Ports nach Aktivierung alle auf High stehen, liegt auf DB6 und DB7 auch ein High-Signal an, obwohl das nicht sein darf.
Evtl. meinst Du den initialen "High-Z-Zustand"? Ich verstehe nicht, was Du unter "Aktivierung" verstehst.

Wenn Du "High-Z" für die kurze Zeit zwischen Anlegen der Betriebsspannung und Initialisierung vermeiden willst, bleiben Dir nur externe Pull-Up bzw. Pull-Down-Widerstände, die meist nur dann nötig sind, wenn man direkt (Leistungs-)MOSFETs schaltet.

Gruß

Fred

[pyr0skull]

Ich glaub wir kommen auf keinen grünen Zweig.. Ich weiß nicht wie ich es richtig ausdrücken soll, so dass es jeder versteht. Wichtig ist: Vorher hat es nicht funktioniert, jetzt klappt alles.

Werde den Code nachher trotzdem hier hochladen, sollte mal jemand auf ähnliche Probleme stoßen, kann er damit hoffentlich was anfangen..

[sternst]

Ich weiß nicht wie ich es richtig ausdrücken soll

Schreib doch einfach auf, welche Codezeilen du zu beanstanden hast, und dazu dann noch, wie sie deiner Meinung nach aussehen müssten. Ich denke nämlich, du bist da auf einem Holzweg, weil ...

Da beim Atmega die Ports nach Aktivierung alle auf High stehen
... dieses schlicht falsch ist.

[pyr0skull]

Das ist die Codepassage in der die Ports als Ausgänge konfiguriert werden (lcd.c):


DDR(LCD_RS_PORT) |= _BV(LCD_RS_PIN);
DDR(LCD_RW_PORT) |= _BV(LCD_RW_PIN);
DDR(LCD_E_PORT) |= _BV(LCD_E_PIN);
DDR(LCD_E2_PORT) |= _BV(LCD_E2_PIN);
DDR(LCD_DATA0_PORT) |= _BV(LCD_DATA0_PIN);
DDR(LCD_DATA1_PORT) |= _BV(LCD_DATA1_PIN);
DDR(LCD_DATA2_PORT) |= _BV(LCD_DATA2_PIN);
DDR(LCD_DATA3_PORT) |= _BV(LCD_DATA3_PIN);

Danach habe ich das eingefügt:


LCD_DATA0_PORT &= ~_BV(LCD_DATA0_PIN);
LCD_DATA1_PORT &= ~_BV(LCD_DATA1_PIN);
LCD_DATA2_PORT &= ~_BV(LCD_DATA2_PIN);
LCD_DATA3_PORT &= ~_BV(LCD_DATA3_PIN);

Seitdem funktioniert die Library bei mir.

[fhs]

Hi,

das steht auch in der P. Fleury Bibliothek und wird dann durchgeführt, wenn die Bedingung

( (&LCD_DATA0_PORT == &LCD_DATA1_PORT) && (&LCD_DATA1_PORT==&LCD_DATA2_PORT) && (&LCD_DATA2_PORT == &LCD_DATA3_PORT)
&& (LCD_DATA0_PIN == 0) && (LCD_DATA1_PIN == 1) && (LCD_DATA2_PIN == 2) && (LCD_DATA3_PIN == 3) )

nicht zutrifft. Wie sieht es denn damit bei Dir aus?

Gruß

Fred

[sternst]

Wenn diese 4 Zeilen bei dir den Unterschied funktioniert ja/nein machen, dann hast du in deinem Code vor dem LCD-Init einen Fehler. Irgendwo setzt du dann eines (oder mehrere) der Port-Bits versehentlich auf 1.

[jwsk]

gibt es denn jetzt eigentlich eine Veröffentlichung der angepassten lcd.h und lcd.c? Habe leider vor dem Kauf des Displays nicht nachgesehen
ob ein oder zwei Controller das Display steuern, wäre für den gesamten
Code äußerst dankbar ;)

[pyr0skull]

Zur Info, jwsk hat den Code als Betatester erhalten und sobald er ihn zum Laufen gebracht hat, werde ich ihn hier hochladen ;)

[jwsk]

... hat sich erledigt!!!!

[jwsk]

jetzt läuft es. als änderung schlage ich vor
XTAL anstatt F_CPU zu nehmen, da diese bereits
innerhalb der fleury defines definiert ist.
bei mir fehlte der f_cpu, mein compiler hat
sich aber nicht beschwert!!

ansonsten gute arbeit.
ich werde noch eine erweiterung einpflegen
und mich dann melden!

lcd_clrscr() für beide
sowie ein gotoxy(x,y) welches
automatisch auf den 2. controller
wechselt.

[jwsk]

hier die versprochenen Erweiterungen (lcd_c):

1. Controller1 wählen dann Display clearen, Controller2 wählen
dann Display clearen und wieder auf Controller1 wechseln.


void clrscr(){ __lcd=0;lcd_clrscr();
__lcd=1;lcd_clrscr();
__lcd=0;}


2. y=0 oder y=1 ersten Controller ansprechen,
y=2 oder y=3 zweiten Controller ansprechen



int goxy(int x, int y){


switch (y) {
case 0:
__lcd=0;
lcd_gotoxy(x,y);
break;

case 1:
__lcd=0;
lcd_gotoxy(x,y);
break;

case 2:
__lcd=1;
y=0;
lcd_gotoxy(x,y);
break;

case 3:
__lcd=1;
y=1;
lcd_gotoxy(x,y);
break;
}


return 0;

}


3. Controller1 wählen dann Initialisieren, Controller2 wählen
dann Initialisieren und wieder auf Controller1 wechseln.



void lcdinit (void){
__lcd=0;
lcd_init(LCD_DISP_ON);
__lcd=1;
lcd_init(LCD_DISP_ON);
__lcd=0;}

[thewulf00]

Achte bitte darauf, dass auch die lcd_puts-Funktion (also die zum Schreiben eines Strings auf das Display) diesen Controllerwechsel beinhalten muss, für 2 Fälle:
- Word/Linewrap aktiv
- Verarbeitung von \n

[jwsk]

halte ich für überflüssig,
wenn man alles absolut adressiert ist das doch tutti :)

um unfälle zu vermeiden kann man alternativ ja auch
den automatischen umsprung rauswerfen aus dem qt!