Seltsamer "LCD Fehler"

[Teo D. (teoderix)]

Hi,

spiel hier grad mit nem PIC18F25K22 rum.
[laber]
Bei der Gelegenheit wollte ich der bisher hervorragend funktionierenden 
LCD-Routine, das dämliche 2ms warten austreiben. Ergebnis Display tot. 
Ziemlich dumm auf den wahrscheinlich funktionierenden Code gestarrt... 
OK alles retoure (Backup), noch mehr blöd guck... Als der Hamster wieder 
auf dem Rad war, hab ich das fehlende Häkchen im Codeconfigurator 
eindeckt... grr.. Erst mal'n Pfeif... ähh ne Zigarette angezündet.
So ab nu wird's lustig. Alles, bis auf eine Kleinigkeit, funktioniert 
alles wie vorher.
[/laber]

Folgender Code produziert nicht wie gehabt die Ausgabe:
"xx.x°C"
Sondern:
"xx.x°B"
Also ASCII+1. Alle anderen Ausgaben auf dem LCD, sind Korrektor.

Ich habe nicht die geringste Idee wo ich da den Fehler suchen sollte?

void Temp_LCD_Ausgabe(char tab) {
    char PBuff[5], buffer, n;

    temperatur = Temp_messen();
    utoa(PBuff, temperatur, 10);
    n = strlen(PBuff) - 1;
    buffer = PBuff[n];
    PBuff[n] = '.';
    PBuff[++n] = buffer;
    PBuff[++n] = 0xdf; // "°"
    PBuff[++n] = 'C';
    PBuff[++n] = NULL;
    LCD_Tab(tab);
    LCD_Print(PBuff);
}

[Jörg W. (dl8dtl) (Moderator)]

Teo D. schrieb:
> char PBuff[5]

Wie viele Zeichen möchtest du da gleich ausgeben, einschließlich
des terminierenden Nullzeichens?

> PBuff[++n] = NULL;

NULL ist per Konvention ein Zeiger, aber kein Nullzeichen.  Das heißt
entweder einfach 0, oder wenn du's kompliziert magst, '\0'.

[Teo D. (teoderix)]

Jörg W. schrieb:
> Wie viele Zeichen möchtest du da gleich ausgeben, einschließlich
> des terminierenden Nullzeichens?

3(char) + 2(.,C) + 1(NULL) = 6
...°
Naja, die Rechnung stimmt wenigstens :(
DANKE
(kann mich garnicht erinnern da rumgepfuscht zu haben. Zeiger... hat 
wahrscheinlich bisher nur zufällig funktioniert)

Jörg W. schrieb:
> NULL ist per Konvention ein Zeiger, aber kein Nullzeichen.  Das heißt
> entweder einfach 0, oder wenn du's kompliziert magst, '\0'.

Hmm... laut Manual vom XC8 ist das auch (?) der Nullterminator für 
"Strings"

[Jörg W. (dl8dtl) (Moderator)]

Teo D. schrieb:
> Hmm... laut Manual vom XC8 ist das auch (?) der Nullterminator für
> "Strings"

Dann benutz' das Manual zum Entzünden des nächsten Lagerfeuers.
Vielleicht eignet es sich ja wenigstens dafür. ;-)

[Karl H. (kbuchegg)]

Teo D. schrieb:

> Hmm... laut Manual vom XC8 ist das auch (?) der Nullterminator für
> "Strings"

Ja. Numerisch sind NULL, 0, '\0' alles dasselbe. Eine binäre 0.

Aber die Intention von NULL ist es, einen ungültigen Pointer Wert 
anzuzeigen. Die Betonung liegt auf Pointer. NULL wird also per 
Konvention im Umfeld von Pointern verwendet. Niemand klopft dir auf die 
Finger, wenn du es in einem anderen Umfeld benutzt. Aber die Verwirrung 
ist gross. Denn was hat denn der Inhalt einer char Variablen mit einem 
Pointer zu tun? Gar nichts.

Das ist ungefähr so, wie wenn du schreibst

  double radius = 'a';
  double umfang = 2 * radius * 3.1415926;

kannst du machen. Als Character hat 'a' einen Ascii Code, diese Codezahl 
wird zu einem double gewandelt und zugewiesen. Syntaktisch ist da nichts 
falsch drann.
Trotzdem ist es wohl in den meisten Fällen verwirrend.

Solche Dinge fallen unter den Oberbegriff der 'aktiven 
Arbeitsplatzsicherung'.

[Teo D. (teoderix)]

Da hab ich wohl zu sehr den Ausdruck "null terminated" mit "#define NULL 
'\0'" assoziiert :)

OK, also lieber "=0" oder "='\0'".

[Karl H. (kbuchegg)]

Teo D. schrieb:
> Da hab ich wohl zu sehr den Ausdruck "null terminated" mit "#define NULL
> '\0'" assoziiert :)
>
> OK, also lieber "=0" oder "='\0'".

Probier mal, ob dein System ein #define für NUL (mit 1 L) hat. Das wäre 
dafür gedacht, den 0-Character auszudrücken.

[Teo D. (teoderix)]

Nö, hat er nich. Egal, schreib den Mist ja eh nur für mich.

Momentan nervt mich mehr daß mir das,

bool LCD_Bussy(void) {
    bool x;
    LCD_D3_SetDigitalInput();
    LCD_RS_LAT = 0;
    LCD_RW_LAT = 1;
//        __delay_us(25);
    x = LCD_D3_PORT;
    LCD_D3_SetDigitalOutput();
    return (x);
  }

scheinbar kein BussyFlag aus dem LCD entlockt. Liest ständig Hi ein!
Nicht mein Tag Heute, steh sicher wiedermal nur auf'm Schlauch :(

PS:Dabla nach Besonderheiten der Pins durchforstet! Nix.
Morgen mal den "Code Configurator" überprüfen, ob der auch wirklich 
alles so wie gewollt generiert hat. Wär nicht das erste mal das nicht.

[neuer PIC Freund (Gast)]

Müsste es nicht

3(char) + 3(.,C,°) + 1(NULL) = 7

heißen?

[Teo D. (teoderix)]

neuer PIC Freund schrieb im Beitrag #4295017:
> Müsste es nicht
>
> 3(char) + 3(.,C,°) + 1(NULL) = 7
>
> heißen?

Jup und dank Jörg W. ist's mir auch aufgefallen das da was fehlt.
Lustig ist halt, das das mehrere Tage problemlos funktioniert hat (trotz 
ständigen Programmänderungen).

[Karl H. (kbuchegg)]

Teo D. schrieb:

> Jup und dank Jörg W. ist's mir auch aufgefallen das da was fehlt.
> Lustig ist halt, das das mehrere Tage problemlos funktioniert hat (trotz
> ständigen Programmänderungen).

Merke.
Nicht jeder Fehler führt sofort zu einem Problem.
Durch Testen kann man immer nur die Anwesenheit von Fehlern feststellen. 
Nie die Abwesenheit.

[beric (Gast)]

Teo D. schrieb:
> Hmm... laut Manual vom XC8 ist das auch (?) der Nullterminator für
> "Strings"

Ich wette da steht "NUL" und nicht "NULL".

Teo D. schrieb:
> Momentan nervt mich mehr daß mir das,
>   bool LCD_Bussy(void) {
>     bool x;
>     LCD_D3_SetDigitalInput();
>     LCD_RS_LAT = 0;
>     LCD_RW_LAT = 1;
>   //        __delay_us(25);
>     x = LCD_D3_PORT;
>     LCD_D3_SetDigitalOutput();
>     return (x);
>   }
> scheinbar kein BussyFlag aus dem LCD entlockt. Liest ständig Hi ein!

Busy schreibt mal üblicherweise mit nur einem s.

Funktioniert es wenn das 25us Delay NICHT ausgeklammert ist? Ich kenne 
zwar dein uC nicht, aber kann mir vorstellen das er sich ein bisschen 
Zeit nehmen möchte um die Port-Richtung zu ändern.

[Teo (Gast)]

beric schrieb:
> Busy schreibt mal üblicherweise mit nur einem s.
Ubs, (danke)


Klar hab ich das getestet, deshalb steht das ja auch noch da. Kommt zum 
weiter testen aber wieder rein. Hab kein original Dabla, nur 
Pinbelegung, Spannungen und "kompatibel mit HD47...". Pollin Zeugs halt. 
Wer weiß wie lang das teil zum umladen der Gatekapazität braucht.

[Karl H. (kbuchegg)]

beric schrieb:

Ich weis ja nicht, welches LCD du benutzt, aber das kommt mir komisch 
vor

bool LCD_Bussy(void) {
    bool x;
    LCD_D3_SetDigitalInput();
    LCD_RS_LAT = 0;
    LCD_RW_LAT = 1;
//        __delay_us(25);
    x = LCD_D3_PORT;
...

kein Übernahmepuls? Oder sonst irgendeine Benachrichtigung nach dem 
Muster 'jetzt gilts'?
Einfach nur R/S auf 0 setzen, RW auf 1 und das wars?
Kann ich mir nicht vorstellen.

[Karl H. (kbuchegg)]

Karl H. schrieb:
> beric schrieb:
>
> Ich weis ja nicht, welches LCD du benutzt, aber das kommt mir komisch
> vor
>

> bool LCD_Bussy(void) {
>     bool x;
>     LCD_D3_SetDigitalInput();
>     LCD_RS_LAT = 0;
>     LCD_RW_LAT = 1;
> //        __delay_us(25);
>     x = LCD_D3_PORT;
> ...
>

>
> kein Übernahmepuls? Oder sonst irgendeine Benachrichtigung nach dem
> Muster 'jetzt gilts'?
> Einfach nur R/S auf 0 setzen, RW auf 1 und das wars?
> Kann ich mir nicht vorstellen.

Schaun wir mal, wie Grossmeister Fleury das macht

static uint8_t lcd_waitbusy(void)

{
    register uint8_t c;
    
    /* wait until busy flag is cleared */
    while ( (c=lcd_read(0)) & (1<<LCD_BUSY)) {}

ok. also die Funktion lcd_read macht das.

static uint8_t lcd_read(uint8_t rs) 
{
    uint8_t data;
    
    
    if (rs)
        lcd_rs_high();                       /* RS=1: read data      */
    else
        lcd_rs_low();                        /* RS=0: read busy flag */
    lcd_rw_high();                           /* RW=1  read mode      */

bla bla bla
    
        lcd_e_high();
        lcd_e_delay();        
        data = PIN(LCD_DATA0_PORT) << 4;     /* read high nibble first */
        lcd_e_low();

...

AHA!!!
Also doch einmalig mit dem E-Pin wackeln.
Ist auch logisch so.
Woher soll denn das LCD wissen, wann du fertig bist mit dem Einstellen 
der Steuerleitungen.

[Jörg W. (dl8dtl) (Moderator)]

Karl H. schrieb:
> Ich weis ja nicht, welches LCD du benutzt

Er schrob: „kompatibel mit HD44780“, dann wird es schon einen Impuls
an E brauchen.

[Teo D. (teoderix)]

Karl H. schrieb:
> AHA!!!
> Also doch einmalig mit dem E-Pin wackeln.

Davon steht aber in meinem Dabla nix :(
OK, sorry, ist kein original HD47... Hat wohl etwas gelitten, beim 
abschreiben und übersetzen. Sieht aber dem Original zum verwechseln 
ähnlich. Werd das mal genauer vergleichen.

Werd's später mal wackeln lassen :)


> Ist auch logisch so.
> Woher soll denn das LCD wissen, wann du fertig bist mit dem Einstellen
> der Steuerleitungen.

Ich dachte, das hat wohl nichts direkt mit dem Prozessor zu tun, sondern 
da antwortet ein einfaches Logikgatter.

[Teo D. (teoderix)]

Ach ja....

beric schrieb:
> Ich wette da steht "NUL" und nicht "NULL".

VERLOREN ;P
Da steht was von "Nullterminator, null terminated" und '\0'. "NUL" oder 
"NULL" wird da nirgends erwähnt.

"NUL" ist im xc8 nicht definiert.

[Jörg W. (dl8dtl) (Moderator)]

Teo D. schrieb:
> Ich dachte, das hat wohl nichts direkt mit dem Prozessor zu tun, sondern
> da antwortet ein einfaches Logikgatter.

Das Datenblatt ist da etwas seltsam.  Zum einen suggeriert es das,
was du da rausgelesen hast, andererseits siehe Bild, die read operation
bekommt in den Timing-Diagrammen ganz normal ihre Timing-Werte.

Ich hab' sie jedenfalls bisher auch immer als kompletten Buszyklus
(mit E-Impuls und allem) behandelt, und das hat funktioniert. ;-)

[W.S. (Gast)]

Ach, ihr streitet euch mal wieder um des Kaisers Bart.
Offenbar geht es darum, daß der TO eine Art Dezimalpunkt in seine 
Zeichenfolge haben möchte, aber sich scheut, deswegen auf float 
umzusteigen. Nun ja, dann eben so:

void CharInsert (char* Buffer, int maxlen, int pos, char was)
{ int i;
  char a, b;
  i = 0;
  while (i<pos)
  { if (Buffer[i]==0) return;
    ++i;
  }
  a = was;
  while (i<maxlen)
  { b = Buffer[i];
    Buffer[i] = a;
    if (a==0) return;
    a = b;
    ++i;
  }
}

Hab's mal aus einem steinalten Projekt herausgekramt.

Aber nochwas: Der Titel des Threads ist voll daneben. Sowas hat mit 
LCD's überhaupt nichts zu tun, sondern nur mit des TO's Problem beim 
Einfügen eines Zeichens. Besser: "wie füge ich ein Zeichen in eine 
Zeichenkette ein?"

W.S.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> Offenbar geht es darum, daß der TO eine Art Dezimalpunkt in seine
> Zeichenfolge haben möchte, aber sich scheut, deswegen auf float
> umzusteigen.

Nein, das war geklärt.  Mittlerweile geht's um das Busy-Flag eines
HD44780.

[Teo D. (teoderix)]

W.S. schrieb:
> Ach, ihr streitet euch mal wieder um des Kaisers Bart.
Äh.. NÖ
> Offenbar geht es darum, daß der TO eine Art Dezimalpunkt in seine
> Zeichenfolge haben möchte,
Nein, ging es NIE!
> aber sich scheut, deswegen auf float umzusteigen.
NUR um da einen Dezimalpunkt zu erhalten und dann doch noch die zwei 
extra Zeichen dazu pfuschen? NEIN, da stell ich mich doch lieber 
neben's LCD und pinsle das mit der Hand drauf ;)

W.S. schrieb:
> Aber nochwas: Der Titel des Threads ist voll daneben.
Ämmm... JA.

> Besser: "wie füge ich ein Zeichen in eine
> Zeichenkette ein?"
NEIN, darum ging's hier NIE



Jörg W. schrieb:
> Teo D. schrieb:
>> Ich dachte, das hat wohl nichts direkt mit dem Prozessor zu tun, sondern
>> da antwortet ein einfaches Logikgatter.
>
> Das Datenblatt ist da etwas seltsam.  Zum einen suggeriert es das,
> was du da rausgelesen hast, andererseits siehe Bild, die read operation
> bekommt in den Timing-Diagrammen ganz normal ihre Timing-Werte.

Dazu kommt noch die Angabe von 0µs als Antwortzeit!? Ist aber sicher 
ein Fehler in meinem Ausdruck, da hat sich wohl ne Zahl verflüchtigt 
:)

Alles wackeln am Enable-Pin, auf die eine o. andren Art, hat erst mal 
nix genutzt.

Werde da erstmal ein vertrauenswürdigeres LCD dranhängen.

[Teo D. (teoderix)]

Hier das verwendete Display:
http://www.pollin.de/shop/dt/NzczOTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_C0802_04.html
Falls da einer Erfahrung damit hat und es eventuell doch Abweichungen 
zum HD4780 gibt. Glaub ich zwar nicht, der eigentliche Fehler hat sich 
sicher über die Tastatur eingeschlichen aber die Hoffnung stirbt 
zuletzt. Da wird's sicher noch einen geben, dem ich das in die Schuhe 
schieben kann :)

[Teo D. (teoderix)]

Hab obiges noch im Original gefunden.
Ergibt bei mir sicher >7µs. Da bisher nicht beachtet, haut das natürlich 
in meinem Progrämmchen nicht hin (höchstens 2-4µs).

Übrigens lässt mich der Original Dabla wieder glauben das da nicht am 
Enable gewackelt werden muss. Da ist noch ein Blockschaltbild zu sehen, 
in dem die Enable-Funktion als gesonderter Block dargestellt wird!?
http://www.alldatasheet.com/datasheet-pdf/pdf/63673/HITACHI/HD44780.html

[Jörg W. (dl8dtl) (Moderator)]

Teo D. schrieb:
> Hab obiges noch im Original gefunden.

Das ist aber nur der Update des Adresszählers, falls du ihn
abfragen willst.

Eine Seite davor ist die interessante Stelle (ich bin jetzt gerade
anderweitig drüber gestolpert):

Table 6       Instructions
                                                                                     Execution Time
                                 Code                                                (max) (when f cp or
Instruction RS  R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0  Description                     f OSC is 270 kHz)
…
Read busy    0    1  BF  AC  AC  AC  AC  AC  AC  AC  Reads busy flag (BF)            0 µs
flag &                                               indicating internal operation
address                                              is being performed and
                                                     reads address counter
                                                     contents.

Das heißt, dass das Lesen des Busy-Flags (und des Adresszählers)
ein ganz normaler Befehl wie jeder andere ist, also RS = 0 (da Befehl
und nicht Daten), R/W = 1 (da gelesen werden soll).  Implizit ist
dabei wie bei jeder anderen Aktion ein Impuls an E.  Wesentlicher
Unterschied gegenüber allen anderen Befehlen ist, dass er keine
eigene Ausführungszeit benötigt, d. h. es darf sofort danach ein
neuer Befehl gesendet werden.

Aber einfach nur RW auf 1 setzen und RS auf 0 genügt nicht.

[Jörg W. (dl8dtl) (Moderator)]

So, inzwischen läuft meine eigene Implementierung auch auf dem SAMD20.

Da ich sowieso zum Vergleich noch das Diagramm meiner älteren
AVR-Implementierung auf dem LA hatte, hier dieses mal zur Illustration.
Es wird zuerst das Zeichen 'A' (0x41) ausgegeben, jeweils beide
Halbbytes.  Danach werden immer zwei Halbbytes gelesen, die das Busyflag
sowie den aktuellen Adresszähler beinhalten.  Man sieht gut, wie das
von anfangs 0x84 auf danach 0x05 weitergeht.

[Teo D. (teoderix)]

Danke für die Infos :)

Hatte bisher keinen Bock mich mit dem Mist zu beschäftigen.
Tabelle 6 klärt fast alles auf. Auf Grund meiner bisherigen 
Versuche, stellt sich mir noch die Frage:
Welches Nibble purzelt den da zuerst raus?
Ich bin bisher davon ausgegangen das es das Hi-Nbble ist. Das Dabla 
schweigt sich darüber leider aus.

[Jörg W. (dl8dtl) (Moderator)]

Teo D. schrieb:
> Ich bin bisher davon ausgegangen das es das Hi-Nbble ist.

Wenn du dir den LA-Trace oben ansiehst, kannst du recht gut erkennen,
dass es genau so auch ist.  Da kommt eine 4 gefolgt von einer 1 (0x41
für den Buchstaben 'A'), danach 8 - 4, 8 - 4, 0 - 5.

Ich hab' nochmal rote Striche an die relevanten Zeitpunkte gezeichnet.

[Teo D. (teoderix)]

Jörg W. schrieb:
> Da kommt eine 4 gefolgt von einer 1 (0x41
> für den Buchstaben 'A'), danach 8 - 4, 8 - 4, 0 - 5.

Jup, Danke.
(Die 1 dazwischen kommt sicher von deinem Prozi (letztes Write))

So, genug gelöchert, nu wird's Zeit mich da mal wieder selber zu 
bemühen. Hab schon einen Verdacht, wo noch so ein "ich dachte", 
zugeschlagen hat. Aber was will man sonst auch tun, wenn das Dabla nicht 
mehr hergibt :(
Muss nur noch alle größeren Werkzeuge, explizit die Hämmer, verräumen :)

[Jörg W. (dl8dtl) (Moderator)]

Teo D. schrieb:
> (Die 1 dazwischen kommt sicher von deinem Prozi (letztes Write))

Ja, der schaltet ja anschließend die Pins wieder auf Ausgang, damit
sie nicht „in der Luft hängen“.  In dem Moment wird dann wieder das
auf den Bus gelegt, was als letztes ausgegeben worden war.

Entscheidend ist immer nur, was zum Zeitpunkt des E-Impules passiert.