Ich programmiere an einem ARM7 mit Eclipse unter Windows herum, jedoch kommt es mir so vor, als ob der Compiler Fehler macht. Um Compiler etc. hab ich mich noch nie gekümmert, daher hab ich da echt NULL Ahnung, aber der verwendete ist glaub nen 4.1.1, zumindest bediehnt er sich aus diesem Ordner. Der neueste, die ich zu dowmloaden gefunden habe, ist ja im Moment der 4.3.3 wenn ich richtig liege. Dazu habe ich mir dasnn auch so eine kleine 75MB-Datei heruntergeladen (gcc-4.3.3.tar.gz) ... wenn ich die entpacke bekomme ich einen 500MB-Ordner mit über 58.000 Dateien ... doch WAS muss ich jetzt damit anstellen ??? Der 4.1.1-er Ordner ist 5,7MB groß mit 120 Dateien, sieht alles ein "bischen" anders aus :-) In dem Ordner "INSTALL" in dem 4.3.3 hab ich eine Anleitung gefunden, dass ich das ganze erst noch selber anpssen und konfigurieren und compilieren müsste ... geht das auch einfacher ??? Gibts nicht irgendwo eine "fertige Version", die ich einfach installieren oder kopieren kann?
Haste zufällig den Quellcode runtergeladen? Das würde die abertausenden Dateine erklären. Wenn ja: Den musst du compilieren. Einfacher wärs allerdings, ein 'Binary' zu besorgen.
1. Nimm WinARM oder Yagarto. 2. Wo ist dein Problem? Wo ist der Zusammenhang zwischen GCC-Fehler und GCC-Paket? 3. toolchain only => codesourcery
Ich hab nen LPC2194 und des WINARM ehh schon auf meinem Rechner, da ist aber eben ein gcc 4.1.1 drin. << Wo ist der Zusammenhang zwischen GCC-Fehler und GCC-Paket? ... ähm ... in dem Ordner ...\WinARM\lib\gcc\arm-elf\4.1.1 ist doch der Compiler für meinen C-Code drin - oder irre ich mich ??? Ich suche einfach eine neuere Version von dem COmpiler, von mir aus auch das komplette Winarm-Paket ... hauptsache neuer ... in der Hoffnung, dass mein Programm dann besser läuft, bzw. der Compiler nicht so seltsame Sachen macht ...
> ... in der Hoffnung, dass mein Programm dann besser läuft ... :-/ Was berechtigt dich zu dieser Hoffung? >... als ob der Compiler Fehler macht ... Beschreib doch einfach mal dein Problem, nicht deinen Verdacht oder deine Versuche zur Umgehung desselben.
Ich habe z.B. die folgende Struktur:
typedef struct
{
unsigned short Temp1;
} struct_tmp;
Wenn ich im MAP-File nachschaue, legt er mir eine Variable dieses Typ's
mit 4 Byte Länge an. eine andere Struktur, die aus 15 einfachen
Variablem und 3 unions besteht, legt er mit 33 Byte an, obwohl sie
32Byte lang sein müsste. In der 2. Struktur gibt es 8, 16, 32 und 64 Bit
Variablen. Das System dahinter verstehe weder ich noch meine Kollegen
...
Da gibt es aber noch diverse andere, sehr schwer zu erklärende Probleme,
da das Programm etwas größer ist ... die komplett unlogisch sind ...
Gibt es denn eine andere, neuere WinARM-Version ??? Am liebsten wäre mir
direkte Links, nicht einfach nur Aussagen wie "JA, Google mal" ... da
tue ich nämlich schon seit 1h.
Jens Fischer wrote: > Ich habe z.B. die folgende Struktur: > > typedef struct > { > unsigned short Temp1; > } struct_tmp; > > Wenn ich im MAP-File nachschaue, legt er mir eine Variable dieses Typ's > mit 4 Byte Länge an. Mit dem Codefetzen da legt er überhaupt nichts an. Und wenner was anlegt, dann sind 4 Bytes vollkommen in Ordnung :-) > eine andere Struktur, die aus 15 einfachen > Variablem und 3 unions besteht, legt er mit 33 Byte an, obwohl sie > 32Byte lang sein müsste. In der 2. Struktur gibt es 8, 16, 32 und 64 Bit > Variablen. Das System dahinter verstehe weder ich noch meine Kollegen > ... Zeig her. Ansonsten: Der Compiler darf auffüllen, wenn er möchte. > Da gibt es aber noch diverse andere, sehr schwer zu erklärende Probleme, > da das Programm etwas größer ist ... die komplett unlogisch sind ... Welche?
>> typedef struct >> { >> unsigned short Temp1; >> } struct_tmp; >Mit dem Codefetzen da legt er überhaupt nichts an. Und wenner was >anlegt, dann sind 4 Bytes vollkommen in Ordnung :-) ... das ist mir auch klar, dass er damit noch nichts anlegt, die Variable legt er natürlich erst an mit: struct_tmp TMP_STRUCT; Wenn bei der Variablen "TMP_STRUCT" aber 4 Bytes OK sind, warum reserviert er dann bei den folgenden 3 Variablen nur jeweils 2 Byte? (extra 2 Byte weil Struct kann ned sein, siehe unteres Beispiel) unsigned short a, b ,c; ... und hier die andere Structur, die (nach entsprechendem Aufruf natürlich) 34Byte lang ist, obwohl ich beim duchzählen auf 33Byte komme: typedef unsigned char u8_t; typedef unsigned short u16_t; typedef unsigned int u32_t; typedef unsigned long long u64_t; typedef union { u8_t Byte; struct { u8_t b1 : 4; u8_t b2 : 1; u8_t b3 : 1; u8_t b4 : 1; u8_t b5 : 1; }Bits; }union_b1; typedef union { u8_t Byte; struct { u8_t b1: 7; u8_t b2: 1; }Bits; }union_b2; typedef union { u8_t Byte; struct { u8_t b1 : 1; u8_t b2 : 1; u8_t b3 : 1; u8_t b4 : 1; u8_t b5 : 1; }Bits; }union_b3; typedef struct { u16_t a1; u16_t a2; u16_t a3; u8_t a4; union_b1 u_b1; u8_t a5; u8_t a6; union_b2 u_b2; u8_t a7; u16_t a8; u16_t a9; u8_t a10; u8_t a11; u32_t a12; u8_t a13; u16_t a14; u8_t a15; union_b3 u_b3; u8_t a16; u8_t a17; u8_t a18; u8_t a19; u8_t a20; u8_t a21; } struct_test;
Jens Fischer wrote: > struct_tmp TMP_STRUCT; > > Wenn bei der Variablen "TMP_STRUCT" aber 4 Bytes OK sind, warum > reserviert er dann bei den folgenden 3 Variablen nur jeweils 2 Byte? Nun, die Variable selber ist mit ziemlicher Sicherheit nur 2 Byte groß. Aber nach der Variable sind dann 2 Füllbytes eingefügt, damit die dahinter liegende Variable (vermutlich 32 Bit groß) auf einer 32 Bit Grenze anfängt. Variablen, die mehrere Bytes umfassen, dürfen nicht an beliebigen Adressen beginnen. Der Zugriff ist dann je nach Architektur entweder deutlich langsamer, oder sogar gar nicht möglich. Also werden nach Bedarf Füllbytes eingefügt (nennt sich Padding).
Das Stichwort ist schon gefallen: Das nennt sich Padding. Und praktisch alle Compiler haben meistens ein #prama mit dem man das Padding bei Bedarf für eine einzelne Struktur abschalten kann.
ich glaube des Problems Lösung gefunden zu haben ... Nachdem ich die Stackgröße von 0x400 auf 0x800 erhöht habe, funktioniert alles einwandfrei, das hätte mir der Compiler aber auch gleich einfach sagen können, dass ich den Stack erhöhen muss ... ;-)
Eines noch: Schmeiß deinen 'typedef unsigned long ...'-Mist raus und benutz die <stdint.h>, da ist das alles idiotensicher definiert. Und:
1 | typedef union |
2 | {
|
3 | u8_t Byte; |
4 | struct
|
5 | {
|
6 | u8_t b1 : 4; |
7 | u8_t b2 : 1; |
8 | u8_t b3 : 1; |
9 | u8_t b4 : 1; |
10 | u8_t b5 : 1; |
11 | }Bits; |
12 | }union_b1; |
'Fast alles bei Bit-Feldern ist implementierungsabhängig. Ob ein Bitfeld eine Wortgrenze überschreiten kann, hängt von der Implementierung ab.' und 'Bitfelder dürfen auch nur als int vereinbart werden, zur Portabilität sollte jedoch explizit signed oder unsigned angegeben werden.' (K&R, 2. Auflage ANSI-C, Seite 144). Ich denke, dass ist dir bewusst. Man korrigiere mich, wenn sich da neuerdings wieder was geändert hat.
>Nachdem ich die Stackgröße von 0x400 auf 0x800 erhöht habe, funktioniert >alles einwandfrei, das hätte mir der Compiler aber auch gleich einfach >sagen können, dass ich den Stack erhöhen muss ... ;-) das kann der Compiler leider nicht wissen ...
Walter wrote: >>Nachdem ich die Stackgröße von 0x400 auf 0x800 erhöht habe, funktioniert >>alles einwandfrei, das hätte mir der Compiler aber auch gleich einfach >>sagen können, dass ich den Stack erhöhen muss ... ;-) > > das kann der Compiler leider nicht wissen ...
1 | #warning Bitte erhoehe den Stack von 0x400 auf 0x800.
|
SCNR
1 | #warning Bitte erhoehe den Stack von 0x400 auf 0x800.
|
... ja, genau so in etwa hatte ich mir das vorgestellt ;-)
Jens Fischer wrote:
>1 | #warning Bitte erhoehe den Stack von 0x400 auf 0x800.
|
> > ... ja, genau so in etwa hatte ich mir das vorgestellt ;-) Nur, dass der Compiler es nicht besser weiß. Sonst hätte er möglicherweise gar nicht die Einstellung der Stackgröße.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.