Druckbare Version
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.Zitat:
Zitat von oberallgeier
mfG
Markus
Au au - danke für die Geduld. Noch ein paar Reste angepasst (Funktionsprototyp etc) - und das Kompilat wird ohne Fehler und Warnungen abgeliefert.Zitat:
Zitat von markusj
Danke allen, die mir geholfen haben
Bitte helft mir wieder einmal. Mein rumblättern und scrollen hat nix geholfen.
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.Zitat:
Zitat von markusj
Mal ein paar Codeschnippsel (hoffentlich die ausreichend und richtigen).
Und dann kommt die Warnung:Code: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 ] );
Die Folge ist: ich steh im Wald und verstehe nur Bahnhof.PHP-Code:../SeTe_r5n20.c: In function 'menu_3':
../SeTe_r5n20.c:126: warning: pointer targets in passing argument 1 of 'lcd_string' differ in signedness
Ich bin jetzt kein C-Experte, aber für den Compiler gilt: char != signed char != unsigned char
Entweder Lcd-header + source ändern:
oder:Code:void lcd_string(signed char const *data);
EDIT:Code:lcd_string((char*)MNUnm2[3]);
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
Nein, ist es nicht. Du hast doch selbst richtig geschrieben:Zitat:
Zitat von Wsk8
Klar muss sich letzten Endes ein "char" entweder genauso verhalten wie "signed char" oder "unsigned char". Aber was von beiden wird vom Compiler festgelegt.Zitat:
char != signed char != unsigned char
Warum jemand Strings allerdings explizit als "signed" haben möchte, erschließt sich mir auch nicht.
- - - Aktualisiert - - -
Von "im Flash" kann ich da aber nichts sehen.Zitat:
Zitat von oberallgeier
Für den Compiler sind es natürlich 3 unterschiedliche, aber beim gcc ist das verhalten von signed char = char. Darauf will ich hinaus.Zitat:
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.
mfg
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".Zitat:
Zitat von Wsk8
Ich dachte (hoffte, glaubte) diese CodesequenzZitat:
Zitat von sternst
würde diese Texte im Flash ablegen ! ? ! ?Code:...
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
...
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.
Zitat:
Zitat von sternst
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.Code:Im Definitionsheader:
typedef unsigned char u8;
typedef signed char s8;
Naja, ich will hier jetzt nicht über irgendwelche Standards etc streiten.Zitat:
Zitat von sternst
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 ;)
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.Zitat:
Ach so, hatte ich oben vergessen, die gewünschten Ausgaben erschienen trotz der Warnungen, der Compiler besitzt offensichtlich mehr Toleranz als ich C-Kenntnisse.
http://www.nongnu.org/avr-libc/user-.../pgmspace.htmlZitat:
würde diese Texte im Flash ablegen ! ? ! ?
Da ist auch beschrieben, wie man einen String-table ablegt.
mfg
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).Zitat:
Zitat von oberallgeier
Ja, fragt sich nur weiterhin, warum MNUnm2 überhaupt ein s8-Array sein soll, und nicht einfach ein char-Array.Zitat:
Zitat von oberallgeier
- - - Aktualisiert - - -
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".Zitat:
Zitat von Wsk8