Hi, ich hab ein longarray, und möchte aber auf die longs byteweise zugreifen, so daß ich 4 einzelne bytes eines longwertes habe. ltoa gibts bei keil anscheinend nicht. und einen charzeiger darüberlaufen lassen geht nicht, da der kompiler nen fehler meldet. thnx SiO2
Hallo Sand, ..r darüberlaufen lassen geht nicht, da der kompiler nen fehler meldet. ... Dann wirst du es nicht richtig gemacht haben, in C sollte das auch gehen. In Assembler sowieso ;-)
SiO2 wrote: > Hi, > ich hab ein longarray, und möchte aber auf die longs byteweise > zugreifen, so daß ich 4 einzelne bytes eines longwertes habe. ltoa gibts > bei keil anscheinend nicht. ltoa() würde dir auch nichts nützen. Diese Funktion macht was ganz anderes. > und einen charzeiger darüberlaufen lassen > geht nicht, da der kompiler nen fehler meldet. Wenn du uns auch noch sagen würdest wie der Fehler lautet und den zugehörigen Code dazu (+ notwendige Umgebung um das Ganze verstehen zu können), dann könnte dir irgendwer erklären wo du die C-Regeln verletzt hast. Einen 'char- Pointer drüberlaufen lassen' ist eine der Möglichkeiten die du hast um dein Problem zu lösen. Eine weitere ist der Einsatz einer Union. Eine weitere ist der Einsatz von Shift und Maskieroperationen um die einzelnen Bytes zu extrahieren.
Arraydefinition: signed long par[ PAR_COUNT ]; code zum auslesen: char * p_array; p_array=&par[0]; Fehlermeldung: CParameter.cpp(226): error: a value of type "signed long *" cannot be assigned to an entity of type "signed char *" Irgendwas muss ich da übersehen.
@ SiO2 (Gast) >bei keil anscheinend nicht. und einen charzeiger darüberlaufen lassen >geht nicht, da der kompiler nen fehler meldet. Du brauchst einen Pointer cast. Ohne Gewähr. char *p_char; long tmp; p_char = (char*)&tmp; MFG Falk
Hmm, mit union klingt gut, hätte ich auch draufkommem müssen, gleich mal testen. Ist Keilcompiler fürn c166.
@Falk, geht mit dem cast auch nicht, der Keilcompiler hat sogar nen problem wenn ich ne fkt habe, die int als parameter nimmt aber ein volatile int übergebe.
SiO2 wrote: > @Falk, geht mit dem cast auch nicht, Ohne den Keil Compiler zu kennen: Das muss gehen. Mit einem cast überstimmst du immer das Typ-Prüfsystem des Compilers. > der Keilcompiler hat sogar nen > problem wenn ich ne fkt habe, die int als parameter nimmt aber ein > volatile int übergebe. völlig zu Recht.
@ SiO2 (Gast) >@Falk, geht mit dem cast auch nicht, der Keilcompiler hat sogar nen >problem wenn ich ne fkt habe, die int als parameter nimmt aber ein >volatile int übergebe. Zeig mal deinen Quellcode und die Fehlermeldung. MFG Falk
>> der Keilcompiler hat sogar nen >> problem wenn ich ne fkt habe, die int als parameter nimmt aber ein >> volatile int übergebe. >völlig zu Recht. Wieso? ich gebe mit volatile doch nur an, dass es nicht wegoptimiert werden soll. grübl
@Falk main.cpp(92): error: argument of type "volatile unsigned int *" is incompatible with parameter of type "unsigned int *" deklaration: void setBitI( unsigned int * where, char bit_nr, char value ); code: extern volatile unsigned int * io1_i; setBitI(io1_i,2,2);
@ SiO2 (Gast) Ich meinte eher das Problem mit dem Pointer cast. Und das mit dem volatile hat auch seinen Grund. Kann ich aber jetzt nicht wirklich begründen, bin da nicht so der C-Profi. MfG Falk
SiO2 wrote: >>> der Keilcompiler hat sogar nen >>> problem wenn ich ne fkt habe, die int als parameter nimmt aber ein >>> volatile int übergebe. > >>völlig zu Recht. > > Wieso? void foo( int* i ) { } int main() { volatile int j; foo( &j ); } Woher soll jetzt bitte der Code in foo() wissen, dass für j spezielle Regeln gelten? In main() teilst du dem Compiler mit: Mach keine Optimierungen mit der Variablen j und innerhalb von foo würde das alles nicht mehr gelten? > ich gebe mit volatile doch nur an, dass es nicht wegoptimiert > werden soll. Du spzifizierst mit volatile, dass eine Variable sich auf Wegen ändern kann, die der Compiler nicht einsehen kann. volatile ist ein Qualifizierer eines Datentyps, genauso wie const. Der komplette Datentyp von j ist 'volatile int'. foo() nimmt aber keinen 'volatile int*'. foo() nimmt einen 'int*'. Das ist aber ein anderer Datentyp! Stell dir einfach vor, hinter dem j würde sich in Wirklichkeit eine Hardwareuhr verbergen. In main() teilst du dem Compiler korrekterweise mit, dass er bei jedem Zugriff auf j auch wirklich die Uhr auslesen muss. Dann übergibst du die Uhr an foo() und innerhalb dieser Funktion darf der Compiler Zugriffe dann plötzlich cachen?
@ Karl heinz Buchegger Jetzt hab ich es verstanden. Besten Dank für die Erklärung.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.