lcd_write Fehlersuche

[grundschüler (Gast)]

ich habe ein programm das alle 20sec Daten von einem controller auf 
einen anderen überträgt. Auf einem tft werden Text und Zahlenwerte 
angezeigt. Nach etwa einem Tag fällt die Übertragung des Textes aus - 
Zahlenwerte werden weiter angezeigt obwol Zahlen und text die gleiche 
Funktion benutzen. lcd_write("123test456"); wird nicht mehr angezeigt. 
Woran kann das liegen?

Das sind die Funktionen:

//==================================================
void lcd_write(uint8_t* str)
{
  uint8_t TempChar;
    do
    {
        TempChar = *str++;
        if(TempChar<' '||TempChar>130)return;

        lcd_char(TempChar);

           curposx =curposx+ f_width;
       if(frame)curposx++;
    }
    while ( *str != 0 );
}

//=============================================
void lcd_int3(uint16_t int1){
  uint8_t dum[4]={' ',' ',48,'\0'};
  u8 s1=0;

    if (int1>99){
        dum[0]=(int1/100+48);
    s1=1;
    }
        int1=int1%100;

    if (int1>9 || s1){
        dum[1]=(int1/10+48);
    }
        int1=int1%10;
        
        dum[2]=int1+48; 
   
        
     lcd_write(dum);
}
//==================================================

[Nop (Gast)]

grundschüler schrieb:

> void lcd_write(uint8_t* str)
> {
>   uint8_t TempChar;
>     do
>     {
>         TempChar = *str++;
>         if(TempChar<' '||TempChar>130)return;
>
>         lcd_char(TempChar);
>
>            curposx =curposx+ f_width;
>        if(frame)curposx++;
>     }
>     while ( *str != 0 );
> }

Was passiert, wenn diese Funktion jemals einen Leerstring übergeben 
bekommt?

[Thomas (Gast)]

Direkt in dem Code sehe ich keinen Fehler (abgesehen von den 
überflüssigen Zeilen mit curposx). Hast du irgendwo einen Überlauf, der 
sich erst nach einem Tag beobachtbar macht? Oder läuft der Speicher 
voll? Sind die Texte auch immer mit '\0' abgeschlossen?

[grundschüler (Gast)]

Thomas schrieb:
> Sind die Texte auch immer mit '\0' abgeschlossen?

Nein, das ist der einzige Unterschied zu Ziffernfolgen:

lcd_write("123test456");
./.
 uint8_t dum[4]={' ',' ',48,'\0'};
lcd_write(dum);

Aber durch '\' wird doch nur das Ende des strings angezeigt. Nach dem 
letzten Zeichen ist der string doch ohnehin zu Ende?




> Was passiert, wenn diese Funktion jemals einen Leerstring übergeben
> bekommt?

Weiß ich nicht, passiert eigentlich nicht.

[Nop (Gast)]

grundschüler schrieb:

> lcd_write("123test456");

Bei einem solchen String-Literal ist die Null am Ende automatisch mit 
drin.

> Nach dem letzten Zeichen ist der string doch ohnehin zu Ende?

Nein. In C sind Strings zuende, wenn eine Null kommt. Wenn keine Null 
kommt, liest die Routine solange zufällig im Speicher weiter, bis eine 
kommt. Der Cursor wird dann natürlich sonstwohin gestellt.

> > Was passiert, wenn diese Funktion jemals einen Leerstring übergeben
> > bekommt?
> Weiß ich nicht

Dann geh der Frage mal nach. Ein bißchen Knobelei muß für Dich ja auch 
noch übrig bleiben. :-)

[grundschüler (Gast)]

Nop schrieb:
> Bei einem solchen String-Literal ist die Null am Ende automatisch mit
> drin.

Das ist natürlich richtig, wusste ich früher auch mal.

Ich such ja erstmal eine Erklärung.

die lcd_write - Funktion müsste grundsätzlich in Ordnung sein.


"123test456" wird zur Laufzeit irgendwo in den RAM geschrieben. kann es 
sein dass sich der Ram dadurch verbraucht und irgendwann kein Platz für 
weiteren Text vorhanden ist?


Macht es Sinn, für solchen Text festen Speicher - u8 dum[] - anzulegen?

[grundschüler (Gast)]

habe jetzt auf

u8 tst[]="wzb vl  rl  t0  t1  thm  elt  az ";
    lcd_goto(25,1);lcd_write(tst);

geändert.

Der im Ram abgelegte String wird korrekt geschrieben.

Es ist also kein Problem mit der Funktion lcd_write, sondern ein 
Speicherüberlaufproblem. Durch das ständige Schreiben von Text aus dem 
Programmcode entsteht ein Speicherüberlauf. Ist das normal oder ein 
Fehler in meinem Programm???????

[Pete K. (pete77)]

Du könntest ja mal das ganze Programm zeigen..

[Nop (Gast)]

grundschüler schrieb:

> Ist das normal oder ein Fehler in meinem Programm???????

Wenn auch nur ein einziges mal irgendwo durch Umkopieren oder so ein 
Leerstring übergeben wird, knallt es sowieso, weil lcd_write das nicht 
abfängt.

[Frank M. (ukw) (Moderator)]

grundschüler schrieb:
> do
>     {
>         ....
>     }
>     while ( *str != 0 );

Das Problem mit dem Leerstring lässt sich leicht lösen, indem man 
stattdessen schreibt:

  while ( *str != '\0' )
  {
    ....
  }

Man sollte beim "Durchwandern" eines C-Strings immer eine while- und 
keine do-while-Schleife nehmen.

[grundschüler (Gast)]

Frank M. schrieb:
> immer eine while- und
> keine do-while-Schleife nehmen.

Danke für den Hinweis. Habe jetzt stark vereinfacht:

void lcd_write(uint8_t* str)
{
  while(*str>31)
    {
        lcd_char(*str++);
        curposx =curposx+ f_width;
    if(frame)curposx++;
    }
}

Bin gespannt, ob der Fehler jetzt weg ist.

[ui (Gast)]

grundschüler schrieb:
> while(*str>31)

und was soll das bitte abfangen?

[grundschüler (Gast)]

ui schrieb:
> grundschüler schrieb:
>> while(*str>31)
>
> und was soll das bitte abfangen?

lcd_char holt Daten aus einem font. Der Font fängt mit ' '=32 an. Unter 
32 findet lcd_char im font nichts.

[Frank M. (ukw) (Moderator)]

grundschüler schrieb:
> Unter 32 findet lcd_char im font nichts.

Trotzdem würde ich da nicht abbrechen. Daher:

void lcd_write (uint8_t * str)
{
    while (*str)
    {
        if (*str >= ' ') // printable character?
        {
            lcd_char (*str);
            curposx = curposx + f_width;

            if (frame)
            {
                curposx++;
            }
        }
        str++;           // next character
    }
}

[grundschüler (Gast)]

Wenn im String ein Zeichen <' ' ist, ist irgendwas schief gelaufen. Dann 
ist der Abbruch gewollt. Kann aber eigentlich nicht passieren.

[Harry L. (mysth)]

grundschüler schrieb:
> Wenn im String ein Zeichen <' ' ist, ist irgendwas schief gelaufen. Dann
> ist der Abbruch gewollt. Kann aber eigentlich nicht passieren.

Wieso?
Hast du dir mal das Character-Set eines HD44780 angeschaut?

[grundschüler (Gast)]

Wenn es mit dem Speicherplatz knapp wird kannst du aus den Fonts jede 
Menge Code herauslöschen der ohnehin nicht gebraucht wird.

[grundschüler (Gast)]

Bin - trotz geänderter lcd_write() - immer noch auf der Fehlersuche:

void test(u8 *str){
u8 tmp[]="xxx ";
u8 i;

for(i=0;i<3;i++){
  tmp[i]=*str++;
}

lcd_write(tmp);
}

.....

    lg(21,20);test("vl ");
    lcd_int4(owx_rx_buffer[17]);
    
    lg(22,20);lw("elt ");
    lcd_int4(kw_elt);
    
    lg(23,20);lw(thm);//u8 thm[]="thm ";
    lcd_int4(kw_therm);

nach ca. 2h wird nur noch die Variante thm angezeigt. Ich kann den code 
jetzt entsprechend ändern, würde aber gerne wissen, was falsch läuft.

[Peter D. (peda)]

grundschüler schrieb:
> nach ca. 2h wird nur noch die Variante thm angezeigt.

Du hast ein Speicherproblem, z.B. einen wildgewordenen Pointer, der Dir 
Teile des SRAM überschreibt.
Das Umstellen des Codes ändert nur die Stelle, wo Du den Fehler 
bemerkst.

Den Code, der den Fehler enthält, hast Du bisher nicht gezeigt.

[grundschüler (Gast)]

Peter D. schrieb:
> wildgewordenen Pointer

das muss es sein. Kann eigentlich nur die onewire-empfangsroutine sein:

in der main:
...
while(1){
//================= owx polling ======================

if(owx_signal){//
led1_on;
//sub_owx_slave_polling();
u8 ret=  owx_empfangen(owx_rx_buffer);
...


volatile uint8_t owx_rx_buffer[30]={0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9};
//-------------------------------------------
uint8_t  owx_rx_byte(void){
uint8_t dat=0,i=0,abfr;
//u32 timeout;
  for(i=0;i<8;i++){
    dat=dat<<1;
    dly_med;
      if(owx_signal)
        abfr=0;
        else
        abfr=1;
    dly_short;
      if(owx_signal){
        if(abfr)dat++;
        while(owx_signal);
      }
      /*
      else{
      //???? error
      return;
      }
      */  
  }
return(dat);
}




//-------------------------------------------
uint8_t owx_empfangen(  
  uint8_t *buff    /* Pointer to data buffer */
){
uint8_t len,adr=0;
uint8_t  crc=0;
while(owx_signal);//Anfangssynchronisierung durch Master
dly_short;
 //adr
  *buff = owx_rx_byte();
  adr=*buff;
  crc=crc+1+*buff;
  *buff++;
  
//len
  *buff = owx_rx_byte();
  len=*buff-2;
  crc=crc+1+*buff;
  *buff++;

//4xheader + payload
do{
  *buff = owx_rx_byte();
  crc=crc+1+*buff;
  *buff++;
  } while (--len);

//crc
  *buff = owx_rx_byte();
  
 return crc;

[Nop (Gast)]

Sicher, daß Du *buff++ meinst und nicht (*buff)++?

*buff++ liefert das zurück, worauf buff zeigt (was dann aber nicht 
verwendet wird) und erhöht dann den Zeiger buff.

Außerdem ist die Schleife bei 4xheader + payload schon wieder 
fußgesteuert und wird nicht klappen, wenn die empfangene Länge 0 ist.

[grundschüler (Gast)]

Nop schrieb:
> Sicher, daß Du *buff++ meinst und nicht (*buff)++?

Das werd ich in Ruhe prüfen. Allerdings werden die Daten ja korrekt 
übertragen. Da ist es unwahrscheinlich, dass der Fehler in der 
Berechnungsroutine steckt. Eher pointer - aber ich finde keinen 
undefinierten.

[Peter D. (peda)]

Wenn Du len = 2 empfängst, muß buff mindestens 258 Byte groß sein, ist 
das der Fall?
Wenn nicht, dann mußt Du len abtesten, damit buff nicht überläuft.

[Stefan E. (sternst)]

Nop schrieb:
> Sicher, daß Du *buff++ meinst und nicht (*buff)++?

Nein, er meint eigentlich nur buff++.

grundschüler schrieb:
> Kann eigentlich nur die onewire-empfangsroutine sein:

In die Funktion würde ich auf jeden Fall mal einen Überlaufschutz 
einbauen. In ihrer jetzigen Form ist die in den Puffer geschriebene 
Menge von äußeren Einflüssen abhängig. Was ist z.B. wenn das Paket 
defekt ist und die Längeninfo im Paket daher zu groß ist?

[grundschüler (Gast)]

Peter D. schrieb:
> len = 2

Das könnte der Fehler sein. len ist das 2.Feld und gibt die Anzahl der 
zu übertragenden bytes an. len-2 weil 2 bytes schon gelesen sind. Wenn 
da durch Übertragungsfehler ein Überlauf und damit ein Wert größer als 
der buffer steht, kann es zu Fehlern kommen. Ich werde da einen Abbruch 
einbauen für den Fall, dass len größer als der buffer wird.

Wer denkt denn an so was...

[Dieter F. (Gast)]

grundschüler schrieb:
> Wer denkt denn an so was...

Rate mal mit Rosenthal :-)

Die Salami-Taktik beim Code-Zeigen hat sich wieder mal bewährt ...

[grundschüler (Gast)]

Stefan E. schrieb:
> einen Überlaufschutz einbauen

über 24h ohne Fehler, das wars dann wohl. Alleine hätte ich das nicht 
gefunden. Danke für alle Beiträge.

[Dieter F. (Gast)]

grundschüler schrieb:
> Danke für alle Beiträge.

Dieter F. schrieb:
> Die Salami-Taktik beim Code-Zeigen hat sich wieder mal bewährt ...

Gerne :-)

[grundschüler (Gast)]

Dieter F. schrieb:
> Die Salami-Taktik beim Code-Zeigen

naja, ohne Eingrenzug des Problems wärs bei umfangreichem Code 
wahrscheinlich auch nicht gegangen.

[Dieter F. (Gast)]

grundschüler schrieb:
> naja, ohne Eingrenzug des Problems wärs bei umfangreichem Code
> wahrscheinlich auch nicht gegangen.

Eingrenzung ja - auf lauffähigen Minimal-Code, der den Fehler beinhaltet 
und nicht auf irgendwelche Fragmente - aber nur irgendwelche Teile 
zeigen ist nicht nett.