Große Konstante im ROM..

[Manuel Fegerl (Gast)]

Hi erstmal :)

Ich habe folgendes Problem.. ich will zu Testzwecken eine sehr große
Konstante in den ROM schreiben.. dies mach ich mit

char code daten[] = { .. 40k hexwerte };

der Controller hat 64k Ram, geht sich also Problemlos aus.. sind auch
richtig im ROM.

nun will ich aber auf einzelne Bytes zugreifen.. der erste Versuch war
ein direkter Zugriff also über daten[ziffer].. ein korrekter Zugriff
war so nicht möglich?

genauer: ich verwendete if(daten[1533]==0xFF) ....
das Programm springt trotz richtigem Inhalt nicht in die Schleife

Somit versuchte ich es über einen Pointer

char *test;
test=test+1533;
if(*test==0xFF) ....

das selbe.. springt nicht in die schleife, obwohl eindeutig 0xFF dort
steht.. (zur Kontrolle wurden alle Mittel des Keil debuggers
verwendet).

dann gings weiter..

char *test;
char space;
test=test+1533;
space=*test;      --> in space steht nun definitiv 0xFF laut debugger!
if(space==0xFF) ... --> springt NICHT in diese schleife ?!

Ich hoffe ihr habt ne idee, ich bin echt am verzweifeln.. falls es eine
bessere möglichkeit gibt auf diese Datenmenge zuzugreifen bin ich gerne
offen für Vorschläge..

bei den Daten handelt es sich übrigens um ein MP3-File welches später
über zu Testzwecken über den internen MP3-Dekoder ausgegeben werden
soll (AT89C51SND1C)..

Danke für eure Hilfe
Grüße
Manuel

[Michael Wilhelm (Gast)]

Wird char als signed char oder unsigned char interpretiert?

MW

[Manuel Fegerl (Gast)]

Beiliegend das Testprojekt.. ist ein Keil Projekt (main.c ist der
source)

[Manuel Fegerl (Gast)]

Hallo Michael

Danke für deine Antwort.. war ein guter Denkanstoss :)

ich weiß zwar ehrlichgesagt den unterschied zwischen signed und
unsigned char nicht.. (vielleicht kann mir das wer erklären :), aber
nachdem ich jetzt den pointer test als unsigned definiert habe,
funktioniert das so.. :)

Danke,
Schöne Grüße
Manuel

[dicky (Gast)]

signed geht von -127 bis +128. unsigned von 0...255. daher konnte deine
bedingung (==255) nie erfüllt werden. manche compiler meckern da
übrigens...wie heisst der prozessor eigentlich ?

[dicky (Gast)]

manuel: schäm dich. sowas muss man unbedingt wissen ! 10 mal vaterunser
aufsagen und einmal auf knien ums haus !

[Manuel Fegerl (Gast)]

:)

@dicky: ist ein Atmel AT89C51SND1C
Kompiliert wurde mit Keil (7.10 compiler).. ohne warnung :(

übrigens ich höre tatsächlich zum ersten mal heute dass es unsigned
char gibt.. find ich auch komisch.. naja wieder was gelernt :)

[dicky (Gast)]

ja mensch das ist total wichtig ! siehe auch int und unsigned int, long
und unsigned long. wenn man das nicht weiss kommt man schnell in
teufels küche. egal ob globale variable, array usw... nur bei float,
double und bool gibt es die unterscheidung nicht. ein typisches problem
sind z.b. char (signed) in for/next schleifen wenn die variable über 128
kommen kann...wer von (ältere versionen) basic kommt, weiss das manchmal
nicht. auch in asm sieht man zunächst alles wie unsigned char oder
unsigned int, allerdings gibt es wohl keinen asm-anwender der das nicht
zumindest theoretisch weiss.

merken: wenn irgendwo char,int oder long steht, ist immer die
"signed-version" gemeint. die unsigned version muss immer explizit
angegeben werden. wenn irgendwo aber nur "unsigned" steht, ist
stillschweigend "unsigned int" gemeint. ist leider anfangs etwas
verwirrend.

[Manuel Fegerl (Gast)]

bei integer wars mir immer klar.. da machts ja auch sinn (negative
zahlen..)

aber bei char find ichs etwas seltsam.. natürlich ist ein char auch nur
ein byte, is ja auch ne zahl.. macht also genauso sinn

gut zu wissen auf jedenfall :)

[dicky (Gast)]

ja und auf 8-bittern will man ja auch mal mit negativen zahlen was
machen...

[Manuel Fegerl (Gast)]

was mir immer noch komisch vorkommt ist halt das ich ja trotzdem nur
hexwerte vergleiche.. und die warn ja trotzdem gleich.. für was sie
stehen sollte ja egal sein bei so etwas..

[Hannes Hering (Gast)]

@Manuel: Das der Compiler in dem Fall den (signed) char Wert (der
natürlich maximal 128 groß sein kann) nicht als 0xFF erkennt liegt
daran, das der Wert, der in der char-Variablen gespeichert ist, als -1
angesehen wird, dagegen wird die 0xFF als vorzeichenbehaftete (also
positive) int Zahl interpretiert und (char)-1 == 255 ist nunmal falsch!
;)

[Manuel Fegerl (Gast)]

klingt logisch :)

danke nochmal