Problem mit Typen

[Adrian W. (wuethria)]

Hallo

bin ein ziemlicher Newbie, was das Mikroc.-programmieren angeht. Die 
Probleme beziehen sich dementsprechende Themen. Vielleicht kann mir ja 
trotzdem jemand weiter helfen.

Auf meinem Board MCBSTR9 von Keil gibts ein A/D Wandler, dessen Wert ich 
auslesen möchte und auf dem LCD anzeigen lassen will.

Folgender Code ruft die Fehler hervor:

char * text1[50];
set_cursor(0,0);                   
sprintf(text1,"Analogwert %5d",AD_value); /*Zeile 98*/
lcd_print(text1);  /*Zeile 99*/

Die Definition von lcd_print:

void lcd_print (unsigned char const *string)
{
  while (*string)  {
    lcd_putchar (*string++);
  }
}

Blinky.c(98): error:  #167: argument of type "char **" is incompatible 
with parameter of type "char *restrict"
Blinky.c(99): error:  #167: argument of type "char **" is incompatible 
with parameter of type "const unsigned char *"

Wo muss ich hier ansetzten bzw. welche Werte muss ich wie umwandeln?

[Falk B. (falk)]

@ Adrian Wüthrich (Firma uni) (wuethria)

char * text1[50];

Das soll sicher heissen

char text1[50];

Ohne Sternchen! Denn du willst einen Vektor mit 50 Byte, keinen Vektor 
mit 5 Zeigern auf Char!

MFG
Falk

[Adrian W. (wuethria)]

Vielen Dank für die prompte Antwort. Jetzt gibts zwar nur noch 1 
Fehlermeldung, aber die verstehe ich auch nicht wirklich:

Blinky.c(99): warning:  #167-D: argument of type "char *" is 
incompatible with parameter of type "const unsigned char *"

[yalu (Gast)]

text1 ist char, lcd_print erwartet aber unsigned char.

Wenn du das unsigned in lcd_print weg lässt, sollte es gehen.

[Falk B. (falk)]

@  Adrian Wüthrich (Firma uni) (wuethria)

>Blinky.c(99): warning:  #167-D: argument of type "char *" is
>incompatible with parameter of type "const unsigned char *"

Der Typ stimmt nicht5 überein. Du hast einen Vektor vom Typ char, die 
Funktion will aber cont unsigned char. Ändere mal die Definition. Aber 
es kann auch sein, dass die Funktion nur mit konstanten Strings läuft, 
das ist jetze abhängig vom Compiler und Controller (ich kenn den nicht).

MfG
Falk

[Peter (Gast)]

Das "const" bringt vermutlich auch nix und kann gut weggelassen 
werden...

[Karl H. (kbuchegg)]

Peter wrote:
> Das "const" bringt vermutlich auch nix und kann gut weggelassen
> werden...

Na, ja.
Wenn wir mal Standard-C zugrunde legen, dann sollte das const
schon rein. Sofern nicht irgendeine µC-Spezialität da einen
Strich durch die Rechnung macht.

Ein String-Literal hat im Datentyp ein const stehen. Das es
momentan nicht weiter stört, wenn man so einen Pointer an
einen char* (anstatt an einen const char*) übergibt, dann
liegt das nicht daran, dass es richtig wäre, sondern daran
dass es extra für diesen Fall eine Ausnahmeregelung im Standard
gibt. Das wiederrum liegt daran, dass es bei Erweiterungen im
Standard (const ist ja erst relativ spät dazugekommen) eine
goldene Regel gibt: Alter Code muss weiter gültig sein.
Wenn es diese Ausnahme nicht gäbe, dann hätten Horden von
Programmierer alten Code durchschauen müssen und um das const
erweitern müssen (und dabei wahrscheinlich den einen oder
anderen Fehler gefunden :-). Aber das ist nicht im Sinne des
Standard-Komitees: Alter Code muss möglichst ohne Änderungen
weiter durch den Compiler laufen. Ergeo nimmt man so manche
Krücke dafür in Kauf.

[Adrian W. (wuethria)]

Vielen Dank nochmals für die Hilfe. Ich hab keine Ahnung woran es liegt. 
Habe mittlerweile alles versucht (const weglassen etc.). Es gibt aber 
immer Warnungen. Lasse es so sein, es funktioniert mittlerweile 
trotzdem.

Gruss
Adrian

[Karl H. (kbuchegg)]

Adrian Wüthrich wrote:
> Vielen Dank nochmals für die Hilfe. Ich hab keine Ahnung woran es liegt.
> Habe mittlerweile alles versucht (const weglassen etc.). Es gibt aber
> immer Warnungen. Lasse es so sein,

Solltest du nicht machen.
Warnungen werden am besten wie Fehler behandelt.
Das Problem: manche Warnungen sind tatsächlich harmlos.
Andere aber nicht!
Wenn man sich daher um Warnungen nicht kümmert, dann gehen
die wirklich wichtigen Warnungen in der Flut der harmlosen
Warnungen unter und man übersieht sie.
Die meisten Firmen arbeiten nach der Devise: Warnungen werden
wie Fehler behandelt und müssen beseitigt werden.

> es funktioniert mittlerweile
> trotzdem.

Auch das ist oft ein Trugschluss. Die Krux: Durch Testen
kann man nur das Vorhandensein von Fehlern nachweisen aber
nicht das Fehlen derselben.
Wenn dein Programm also nicht funktioniert, dann weist du
dass ein Fehler enthalten ist. Wenn es hingegen 'funktioniert'
dann kann man im Umkehrschluss daraus nicht ableiten, dass
kein Fehler enthalten ist.
Jeder der lange genug im Geschäft ist, kennt den Effekt:
Nach Jahren des Einsatzes eines Programmes taucht plötzlich
(unter bestimmten Umständen) ein Fehler auf, der schon von
Anfang an im Programm war.

> Ich hab keine Ahnung woran es liegt.
> Habe mittlerweile alles versucht (const weglassen etc.).

Der erste Schritt ist immer:
Die exakte Fehlermeldung lesen (die können manchmal auch
irreführend sein) und die exakte Stelle an der das ganze
passiert. In dieser Hinsicht war dein Eröffnungsposting
vorbildlich.