Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

pcflcd zweiter Versuch Kategorie: Programmierung (von Rolf - 26.08.2003 0:08)


Hallo André,
mir kommt es langsam so vor, als versuchtest Du genau das Gegenteil von dem durchzusetzen,
worauf ich Dich anspreche nur um Recht zu behalten und ja nicht meine Vorschläge aufzugreifen.
Ich finde so eine Haltung kindisch und dem Thema nicht angemessen und möchte die Diskusion
um den PCF-Treiber wieder auf eine sachliche und fachliche Ebene bringen. Ich beziehe mich nun
auf den neuen pcflcd-Treiber den Du heute gepostet hast.

In der Funktion  delline(byte line)

 for i=0...CharsperLine-1
 {
  i2c.write(0x25 or light);
  i2c.write(0x41 or light); //ist vermutlich hier ein Fehler/Tippfehler
  i2c.write(0x05 or light);
  i2c.write(0x01 or light);
 }

Es soll wohl das Zeichen ' ' geschrieben werden, bei fallender Flanke von E im ersten Nibble wird dort
jedoch 0x4 auf den Datenbus gelegt statt die 0x21 zu schalten. Der Fehler ist in den älteren Modulen
ebenfalls enthalten. Bitte korrigieren.

Weiterhin ist mir nicht klar, warum Du die zahl-Funktionen aus lcdext _nicht_ übernommen hast.
Sie benötigen deutlich weniger Rechenoperationen als die aus pcflcd und wären vereinheitlicht auch
leichter zu pflegen. Ich hatte dies angeregt und in dem umgeschrieben Treiber von mir auch so vorgestellt.
Bei dieser Gelegenheit kannst Du auch die Put-Funktionen statt _spc u.ä. einsetzen wie Du es in LCDEXT
auch gemacht hast.

Das Licht scheint jetzt besser steuerbar zu sein, die Lösung mit 16 Variablen wie in meinem Treiber dargestellt,
gefiel mir dann auch nicht und ich habe es bitweise in ein Int gepackt. Deine Lösung ähnelt da meiner etwas.

int light;

function setlight(byte pcfnr,byte state)
{
 if state
   light=light or (1 shl pcfnr); //bit setzen
 else
   light=light and (not (1 shl pcfnr)); // bit löschen
 i2c.cstart(Addr[pcfnr]);
 i2c.write((((light shr pcfnr)and 1)shl 3) or 0x1);
 i2c.stop();
}

Die Lösung mit dem Adressarray ist gut gelungen.

Bezüglich des Timings von tAS aud dem Datenblatt von Hitachi möchte ich es auf sich beruhen lassen.
Displayfehler die ich bisher sah, werden wohl eher durch den überrannten BF-Status erzeugt, wenn die Displays
zu langsam sind. So sehe ich jedenfalls derzeit die Geschichte.

Bezüglich der Funktion zum Lesen des Display... da haben wir offensichtlich beide mit 0x6 und 0x7 daneben
gelangt... und wäre die Geschichte mit Deinen hä�lichen Anfeindungen nicht passiert, hätten wir dies auch
friedlich klären können. Vieleicht erinnerst Du dich daran, wenn Du mir wieder mal Diletantismus an den Kopf
schmeiÃ?en willst und guckst erst mal in den Spiegel bevor Du wie in unserem ersten PCF-Thread lospolterst.

GruÃ? Karboom




    Antwort schreiben


Antworten:

Re: pcflcd zweiter Versuch (von Rolf - 26.08.2003 11:59)
    Re: pcflcd zweiter Versuch (von Rolf - 28.08.2003 2:53)