String Array

[markusj]

Danke für die Hilfe und dass Du da drüber schaust. Über die Deklaration uint8_t war ich schon gestolpert, als ich mir vorhin die Erklärungen zur Funktion im user manual angesehen hatte. Egal - auch ein uint8_t c; hatte nicht geholfen, es kommt dieselbe Warnung.

Nicht c ist das Problem. Dein Array! Statt "char SVdef [][6]" wünscht sich der GCC "uint8_t SVdef [][6]". Tatsächlich kannst du an dieser Stelle den Pointer von int8_t* auf uint8_t* umcasten, weil du im Endeffekt nur die rohen Daten aus dem EEPROM liest und der Typ hier in jeglicher Hinsicht keine Rolle spielt.

mfG
Markus

[oberallgeier]

Nicht c ist das Problem. Dein Array! ... wünscht sich der GCC "uint8_t SVdef [][6]". ...

Au au - danke für die Geduld. Noch ein paar Reste angepasst (Funktionsprototyp etc) - und das Kompilat wird ohne Fehler und Warnungen abgeliefert.

Danke allen, die mir geholfen haben

[oberallgeier]

Bitte helft mir wieder einmal. Mein rumblättern und scrollen hat nix geholfen.

Nicht c ist das Problem. Dein Array! ...

Gut, das mit dem EEPROM läuft problemlos - nur so EWIG langsam, bei meinen mittlerweile längeren Texten im EEPROM wirkt sich das fühlbar aus beim Umschalten von einem aufs andere Menue. Da ich aber im Flash Platz satt habe, wurde kurzerhand ein Array im Flash erzeugt - und schon kommt wieder mal ne Warnung.

Mal ein paar Codeschnippsel (hoffentlich die ausreichend und richtigen).

Im Definitionsheader:
typedef unsigned char  u8;
typedef   signed char  s8;

im LCD-Header:
void lcd_string(char *data);

in meinem Projekt-Header:
...
  s8 MNUnm2 [][ 17 ]    // Namen der einzelnen Menues STETS 16 char
           = {          "  menu   0      ",
                        "  menu   1      ",     " UART Verbindng ",     //  1    2
                        "Messung mit ADC3",     " rtLED      0/1 ",     //  3    4
...

im Code:
  LCR; lcd_string ( MNUnm2 [ 3 ] );

Und dann kommt die Warnung:

../SeTe_r5n20.c: In function 'menu_3':
../SeTe_r5n20.c:126: warning: pointer targets in passing argument 1 of 'lcd_string' differ in signedness 

Die Folge ist: ich steh im Wald und verstehe nur Bahnhof.

[Wsk8]

Ich bin jetzt kein C-Experte, aber für den Compiler gilt: char != signed char != unsigned char

Entweder Lcd-header + source ändern:

void lcd_string(signed char const *data);

oder:

lcd_string((char*)MNUnm2[3]);

EDIT:
Und mit "signed" arbeiten ist mir eig neu. Entweder "char" oder "unsigned char". Entferne am besten signed. Ein char ist schon ein signed char. Das unsigned verwendet man dann um den Bereich von -128 bis 127 auf 0 bis 255 zu verschieben.


mfg

[sternst]

Ein char ist schon ein signed char.

Nein, ist es nicht. Du hast doch selbst richtig geschrieben:

char != signed char != unsigned char

Klar muss sich letzten Endes ein "char" entweder genauso verhalten wie "signed char" oder "unsigned char". Aber was von beiden wird vom Compiler festgelegt.

Warum jemand Strings allerdings explizit als "signed" haben möchte, erschließt sich mir auch nicht.

- - - Aktualisiert - - -

Da ich aber im Flash Platz satt habe, wurde kurzerhand ein Array im Flash erzeugt - und schon kommt wieder mal ne Warnung.

Mal ein paar Codeschnippsel ...

Von "im Flash" kann ich da aber nichts sehen.

[Wsk8]

Nein, ist es nicht. Du hast doch selbst richtig geschrieben:

char != signed char != unsigned char


Klar muss sich letzten Endes ein "char" entweder genauso verhalten wie "signed char" oder "unsigned char". Aber was von beiden wird vom Compiler festgelegt.

Für den Compiler sind es natürlich 3 unterschiedliche, aber beim GCC ist das verhalten von signed char = char. Darauf will ich hinaus.

mfg

[sternst]

Für den Compiler sind es natürlich 3 unterschiedliche, aber beim GCC ist das verhalten von signed char = char.

Beim GCC kann das Verhalten über eine Option festgelegt werden, und viele Makefiles enthalten ein "-funsigned-char". Es ist schlicht ziemlich unklug im Code von "char = signed char" auszugehen. Wenn man unbedingt ein signed char möchte/braucht, dann schreibt man halt besser auch explizit "signed char".

[oberallgeier]

... Von "im Flash" kann ich da aber nichts sehen.

Ich dachte (hoffte, glaubte) diese Codesequenz

...
in meinem Projekt-Header:
...
  s8 MNUnm2 [][ 17 ]    // Namen der einzelnen Menues STETS 16 char
           = {          "  menu   0      ",
                        "  menu   1      ",     " UART Verbindng ",     //  1    2
                        "Messung mit ADC3",     " rtLED      0/1 ",     //  3    4
...

würde diese Texte im Flash ablegen ! ? ! ?

Na jedenfalls hatte Wsk8´s "lcd_string((char*)MNUnm2[3]);" meine Probleme beseitigt. Besser gesagt bekomme ich das Compilat ohne Warnungen. Ach so, hatte ich oben vergessen, die gewünschten Ausgaben erschienen trotz der Warnungen, der Compiler besitzt offensichtlich mehr Toleranz als ich C-Kenntnisse.

... Wenn man unbedingt ein signed char möchte/braucht, dann ... explizit "signed char".

Im Definitionsheader:
typedef unsigned char  u8;
typedef   signed char  s8;

Meine Fehler kommen einfach daher, dass ich solche Feinheiten nur ungefähr kenne und öfters mal die Konsequenzen nicht kenne/sehe/beachte. Deshalb erstmal und wieder mal vielen Dank allen für die Hilfe.

[Wsk8]

Beim GCC kann das Verhalten über eine Option festgelegt werden, und viele Makefiles enthalten ein "-funsigned-char". Es ist schlicht ziemlich unklug im Code von "char = signed char" auszugehen. Wenn man unbedingt ein signed char möchte/braucht, dann schreibt man halt besser auch explizit "signed char".

Naja, ich will hier jetzt nicht über irgendwelche Standards etc streiten.

Ich für meinen Teil benutzte "char" für strings und "unsigned char" wenn es wirklich Vorzeichenlos sein soll. Bei Zählern tendiere ich sowieso zu uint8_t. Damit komme ich immer ganz gut zurecht

Ach so, hatte ich oben vergessen, die gewünschten Ausgaben erschienen trotz der Warnungen, der Compiler besitzt offensichtlich mehr Toleranz als ich C-Kenntnisse.

Im Vergleich zu einem C++-Compiler ist der C-Compiler auch wirklich recht umsichtig. Diese Warnung soll auch keinen Fehler verdeutlich, sondern dir eher aufzeigen, dass hier evtl. etwas schief gehen könnte, da du z.b. einen negativen Wert an eine Funktion übergeben könntest, die nur positive Werte annimmt. Hier gibts dann einen Fehler.

würde diese Texte im Flash ablegen ! ? ! ?

http://www.nongnu.org/avr-libc/user-.../pgmspace.html

unsigned char mydata[11][10] PROGMEM = .....

Da ist auch beschrieben, wie man einen String-table ablegt.

mfg

[sternst]

würde diese Texte im Flash ablegen ! ? ! ?

Nein, sie liegen im RAM (gut, du wirst sie natürlich auch im Flash wiederfinden, denn von irgendwo her müssen sie ja ins RAM kommen).

Na jedenfalls hatte Wsk8´s "lcd_string((char*)MNUnm2[3]);" meine Probleme beseitigt.

Ja, fragt sich nur weiterhin, warum MNUnm2 überhaupt ein s8-Array sein soll, und nicht einfach ein char-Array.

- - - Aktualisiert - - -

Ich für meinen Teil benutzte "char" für strings und "unsigned char" wenn es wirklich Vorzeichenlos sein soll. Bei Zählern tendiere ich sowieso zu uint8_t. Damit komme ich immer ganz gut zurecht

Das ist ja auch unstrittig. Aber wenn man mal einen kleinen vorzeichenbehafteten Typ braucht (z.B. in einer Berechnung), dann sollte man halt tunlichst ein "signed char" oder ein "int8_t" nehmen, und niemals nur ein "char".