3310 Software will nicht char* nehmen

Alexander Ljubizki schrieb:
> Hallo,
>
> ich hab das problem das der LCD nicht char* nimmt :S Es kommt kapputene
> sachen an kasten usw. nur nicht buchstaben :s Alles davor geht

http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F

aber noch viel dringender als diese Kurzzusammenfassung über 
Stringverarbeitung in C wäre endlich ein gutes C-Buch.

1

LcdFStr(FONT_1X,(unsigned char*)PSTR("MPC Startet...")); //Startet

und kurz danach ...

1

LcdFStr(FONT_1X,(unsigned char*)Text);

wobei „Text“ eine (falsch deklarierte, aber jedenfalls) Variable im SRAM 
ist.  Also wird genau dieselbe Funktion einmal für einen Pointer ins 
Flash und einmal ins SRAM verwendet.  Da ist einer der beiden Aufrufe 
verkehrt.

Fragt sich noch, wozu der Cast nach unsigned char nötig ist.  Mich 
beschleicht das Gefühl, dass hiermit eine sinnvolle Compiler-Warnung 
totgedrückt wird.

Hc Zimmerer schrieb:

> Fragt sich noch, wozu der Cast nach unsigned char nötig ist.  Mich
> beschleicht das Gefühl, dass hiermit eine sinnvolle Compiler-Warnung
> totgedrückt wird.

Mann muss kein Wahrsager sein um zu sagen: Die Wette würdest du sehr 
wahrscheinlich gewinnen.

Und noch ein Tip für den Threadstartet:

wenn eine Funktion einen Pointer übernimmt, so wie die hier

1

void foo( int * a )

2

{

3

  ...

dann heißt das nicht zwangsläufig, dass der Aufrufer eine 
Pointervariable bereitstellen muss

1

int main()

2

{

3

  int * b;

4

5

  foo( b );

ganz im Gegenteil! In den meisten Fällen will die Funktion eine Adresse 
haben, an der sie etwas findet oder auf die sie einen Wert schreiben 
kann

1

int main()

2

{

3

  int b;

4

5

  foo( &b );

6

}

wobei Arrays ein Sonderfall sind. Arrays werden beim Aufruf einer 
Funktion immer so übergeben, dass die Funktion die Startadresse des 
Arrays bekommt

1

int main()

2

{

3

  int b[20];

4

5

  foo( b );

6

}

All das, und noch viel mehr, all die kleinen und großen Feinheiten und 
Fallen, die es in der C Programmierung gibt, finden sich in jedem 
C-Lehrbuch.

Alexander Ljubizki schrieb:
> Ja ok ganz am nfang hatte ich char ohne * aber dann kommt diese meldung:
>
> ../main.c:37: warning: assignment makes integer from pointer without a
> cast
>
> Text[0] = "D";
> Text[1] = "\0";

Ich flehe dich an:
Kauf dir ein C Buch
oder lies zumindest den Link, den ich dir gegeben habe!

"D"   ist etwas anderes als  'D'

Ob das ein doppeltes oder ein einfaches Gänsefüsschen ist, macht einen 
Unterschied!

Alexander Ljubizki schrieb:

> ../main.c:102: warning: pointer targets in passing argument 2 of
> 'LcdFStr' differ in signedness

Es gibt 3 verschiedene Character Datentypen
  * signed char
  * unsigned char
  * char

signed   ... mit Vorzeichen
unsigned ... ohne Vorzeichen
char     ... der Compiler hat die Wahl ob er char als
             signed oder als unsigned auffassen will

Wann benutzt man was?

* signed char
  immer dann, wenn man einen 'kleinen Integer' mit Vorzeichen benötigt

* unsigned char
  immer dann, wenn man einen 'kleinen Integer' ohne Vorzeichen benötigt.
  Im speziellen ist das der Datentyp, den man für Bytebearbeitung
  benutzt

* char
  immer dann, wenn es um Textverarbeitung geht


> Hier der Befehl:

Du meinst Funktion.

> byte LcdFStr ( LcdFontSize size, const byte *dataPtr )

byte wird höchstwahrscheinlich ein typedef auf unsigned char sein.
Und dieser Datentyp (unsigned char) ist hier ein wenig zeifelhaft. Die 
Funktion suggeriert, dass man es hier mit Textverarbeitung (nämlich die 
Ausgabe eines Strings) zu tun hat. Von daher wäre ein stink normaler 
char Pointer angebracht.

> Das verstehe ich jetzt nicht alles sollte jetzt richtig sein oder nicht?

Es ist zumindest debattierbar ob der byte* hier eine glückliche Wahl 
darstellt.

Edit:  vergessen
Ein normales 'D' ist vom Datentyp char (weder signed char noch unsigned 
char, sondern einfach nur char)
Dementsprechend ist ein "Test" vom Datentyp "Array of const char" und 
ein Pointer auf das erste Zeichen hat den Datentyp "const char *"