lcd_write Fehlersuche

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?

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?

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.

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. :-)

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?

habe jetzt auf

1

u8 tst[]="wzb vl  rl  t0  t1  thm  elt  az ";

2

    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???????

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. schrieb:
> immer eine while- und
> keine do-while-Schleife nehmen.

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

1

void lcd_write(uint8_t* str)

2

{

3

  while(*str>31)

4

    {

5

        lcd_char(*str++);

6

        curposx =curposx+ f_width;

7

    if(frame)curposx++;

8

    }

9

}

Bin gespannt, ob der Fehler jetzt weg ist.

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

und was soll das bitte abfangen?

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.

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

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

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

1

void test(u8 *str){

2

u8 tmp[]="xxx ";

3

u8 i;

4

5

for(i=0;i<3;i++){

6

  tmp[i]=*str++;

7

}

8

9

lcd_write(tmp);

10

}

11

12

.....

13

14

    lg(21,20);test("vl ");

15

    lcd_int4(owx_rx_buffer[17]);

16

17

    lg(22,20);lw("elt ");

18

    lcd_int4(kw_elt);

19

20

    lg(23,20);lw(thm);//u8 thm[]="thm ";

21

    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. schrieb:
> wildgewordenen Pointer

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

1

in der main:

2

...

3

while(1){

4

//================= owx polling ======================

5

6

if(owx_signal){//

7

led1_on;

8

//sub_owx_slave_polling();

9

u8 ret=  owx_empfangen(owx_rx_buffer);

10

...

11

12

13

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};

14

//-------------------------------------------

15

uint8_t  owx_rx_byte(void){

16

uint8_t dat=0,i=0,abfr;

17

//u32 timeout;

18

  for(i=0;i<8;i++){

19

    dat=dat<<1;

20

    dly_med;

21

      if(owx_signal)

22

        abfr=0;

23

        else

24

        abfr=1;

25

    dly_short;

26

      if(owx_signal){

27

        if(abfr)dat++;

28

        while(owx_signal);

29

      }

30

      /*

31

      else{

32

      //???? error

33

      return;

34

      }

35

      */  

36

  }

37

return(dat);

38

}

39

40

41

42

43

//-------------------------------------------

44

uint8_t owx_empfangen(  

45

  uint8_t *buff    /* Pointer to data buffer */

46

){

47

uint8_t len,adr=0;

48

uint8_t  crc=0;

49

while(owx_signal);//Anfangssynchronisierung durch Master

50

dly_short;

51

 //adr

52

  *buff = owx_rx_byte();

53

  adr=*buff;

54

  crc=crc+1+*buff;

55

  *buff++;

56

57

//len

58

  *buff = owx_rx_byte();

59

  len=*buff-2;

60

  crc=crc+1+*buff;

61

  *buff++;

62

63

//4xheader + payload

64

do{

65

  *buff = owx_rx_byte();

66

  crc=crc+1+*buff;

67

  *buff++;

68

  } while (--len);

69

70

//crc

71

  *buff = owx_rx_byte();

72

73

 return crc;

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.

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. 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...

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 ...

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.

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 :-)

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

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

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.