structur von gcc auf eclipse konvertieren

#3503378
Lesenswert?

ich versuche den U-Radig stack für arm anzupassen. ide ist 
codeRed/eclipse. Änderungen sind wegen anderer Variablentypen 
erforderlich. Ich hänge zur Zeit an Structuren.

Original:
1
struct ARP_Header  {
2
    unsigned int ARP_HWType;    //Hardware Typ enthält den Code für Ethernet oder andere Link Layer
3
    unsigned int ARP_PRType;    //Protokoll Typ enthält den Code für IP o. anderes Übertragungsprotokoll
4
    unsigned char ARP_HWLen;    //Länge der Hardwareadresse enthält 6 für 6 Byte lange MAC Adressen
5
    unsigned char ARP_PRLen;    //Länge der Protocolladresse enthält 4 für 4 Byte lange IP Adressen
6
    unsigned int ARP_Op;      //Enthält Code der signalisiert ob es sich um eine Anfrage o. Antwort handelt
7
    unsigned char ARP_SHAddr[6];  //Enthält die MAC Adresse des Anfragenden  
8
    unsigned long ARP_SIPAddr;    //Enthält die IP Adresse des Absenders
9
    unsigned char ARP_THAddr[6];  //MAC Adresse Ziel, ist in diesem Fall 6 * 00,da die Adresse erst noch herausgefunden werden soll (ARP Request)
10
    unsigned long ARP_TIPAddr;    //IP Adresse enthält die IP Adresse zu der die Kommunikation aufgebaut werden soll 
11
};
12

13
//----------------------------------------------------------------------------
14

15
}

Fälschung:
1
struct ARP_Header  {
2
    uint16_t ARP_HWType;    //Hardware Typ enth?lt den Code f?r Ethernet oder andere Link Layer
3
    uint16_t ARP_PRType;    //Protokoll Typ enth?lt den Code f?r IP o. anderes ?bertragungsprotokoll
4
    unsigned char ARP_HWLen;    //L?nge der Hardwareadresse enth?lt 6 f?r 6 Byte lange MAC Adressen
5
    unsigned char ARP_PRLen;    //L?nge der Protocolladresse enth?lt 4 f?r 4 Byte lange IP Adressen
6
    uint16_t ARP_Op;      //Enth?lt Code der signalisiert ob es sich um eine Anfrage o. Antwort handelt
7
    unsigned char ARP_SHAddr[6];  //Enth?lt die MAC Adresse des Anfragenden  
8
    uint32_t ARP_SIPAddr;    //Enth?lt die IP Adresse des Absenders
9
    unsigned char ARP_THAddr[6];  //MAC Adresse Ziel, ist in diesem Fall 6 * 00,da die Adresse erst noch herausgefunden werden soll (ARP Request)
10
    uint32_t ARP_TIPAddr;    //IP Adresse enth?lt die IP Adresse zu der die Kommunikation aufgebaut werden soll
11
};

Beim Kopieren in diesen header mit
  arp      = (struct ARP_Header      *)&eth_buffer[ARP_OFFSET];
kommt es ab ARP_SIPAddr zu Verschiebungen.

Warum ist "uint32_t ARP_SIPAddr" ungleich
 "unsigned char ARP_SIPAddr[4]; "

mit unsigned char ARP_SIPAddr[4] geht es weiter, hängt dann aber an 
anderer Stelle.

Wie werden gcc-strukturen in eclipse umgesetzt?

Gibt es ein Umsetzungsscript, das man einfach abarbeiten kann?
Gast #3503392
Lesenswert?

Es gibt bei den GCC Compilerparameter noch sowas wie "packed struct" 
oder so ähnlich. Musst mal danach googlen.

Da wird angegeben, ob bei Struct-Teilen bei jeweils 32 Bit oder bei 8 
Bit ein Umbruch erfolgen soll. Daran könnte es liegen.
Gast #3503397
Lesenswert?

>Verschiebung insoweit, als die Werte des arrays eth_buffer in der
>structur ab ->ARP_SIPAddr nicht mehr stimmen. Die Felder sind um 1
>verschoben. Ich vermute, dass die Null in der IP-adresse (192.168.0.146)
>den structur-wert verändert.

Nein. Der Inhalt ist nicht entscheidend. Vielmehr sind der AVR und ARM 
Prozessoren, die am schnellsten auf 8/16 Bit (AVR) bzw. 32 Bit (ARM) 
zugreifen können. Daher ordnen Compiler die Strukturmitglieder, soweit 
möglich auf entsprechenden Grenzen (im Falle des ARM auf vielfachen von 
32 Bit) anzuordnen. Strukturen aber, die ursprünglich auf auf AVR 
zugeschnitten wurde und nicht das pragma pack verwendet, wird auf dem 
ARM Lücken enthalten, damit der günstige 32-Bit Zugriff erhalten bleibt.

Das Problem ist insbesondere das in C die lückenlose Anordnung nicht 
zugesichert ist. Deswegen gibt es das pragma. Lies am besten mal 
gründlich über Strukturen im C99 Standard nach und guck Dir die 
entsprechenden Abschnitte in den Compilerdokumentationen an. Es lohnt 
sich.
Gast #3503398
Lesenswert?

>Gibt es eine Anleitung zur Umsetzung von avr-gcc in eclipse-gcc?

Das haben hier schon zwei oder drei Leute geschrieben: Es gibt kein 
eclipse-gcc. Eclipse ist eine IDE. Der für Dich relevante Unterschied 
liegt in den Prozessoren und damit in den unterschiedlichen Wortbreiten 
und Compilerverhalten. Was Du Dir ansehen musst, sind die verschiedenen 
gcc-Varianten. Mit Eclipse hat das überhaupt nichts zu tun.
#3506028
Lesenswert?

1
//myip: C0.A8.00.92  -  destIP: C0.A8.00.7C
2
u32 test,test1,test2;
3
test=(dest_ip & (*((uint32_t *)&netmask[0])));//=>A8.00.7C
4
test1=((*((uint32_t *)&myip[0]))&(*((uint32_t *)&netmask[0])));//=A8.CO
5
test2=(*((uint32_t *)&myip[0]));//92.00.A8.C0

Wer kann mir das erklären?
Durch (*((uint32_t *)&myip[0])) wird die Reihenfolge des arrays 
umgekehrt!

aus  C0.A8.00.92  wird  92.00.A8.C0
Gast #3506030
Lesenswert?

karl k. schrieb:
>
1
//myip: C0.A8.00.92  -  destIP: C0.A8.00.7C
2
> u32 test,test1,test2;
3
> test=(dest_ip & (*((uint32_t *)&netmask[0])));//=>A8.00.7C
4
> test1=((*((uint32_t *)&myip[0]))&(*((uint32_t *)&netmask[0])));//=A8.CO
5
> test2=(*((uint32_t *)&myip[0]));//92.00.A8.C0
6
>
>
> Wer kann mir das erklären?
> Durch (*((uint32_t *)&myip[0])) wird die Reihenfolge des arrays
> umgekehrt!
>
> aus  C0.A8.00.92  wird  92.00.A8.C0

Das kommt von Little/Big Endian
#3506101
Lesenswert?

karl k. schrieb:
>
1
//myip: C0.A8.00.92  -  destIP: C0.A8.00.7C
2
> u32 test,test1,test2;
3
> test=(dest_ip & (*((uint32_t *)&netmask[0])));//=>A8.00.7C
4
> test1=((*((uint32_t *)&myip[0]))&(*((uint32_t *)&netmask[0])));//=A8.CO
5
> test2=(*((uint32_t *)&myip[0]));//92.00.A8.C0
6
>

Das macht man nicht so. Dafür gibt es Funktionen:
http://www.beej.us/guide/bgnet/output/html/multipage/htonsman.html
#3506260
Lesenswert?

der header sieht bei UR/avr so aus:
1
struct  __attribute__ ((__packed__))  ARP_Header  {
2
uint16_t ARP_HWType;    //Hardware Typ enth�lt den Code f�r Ethernet oder andere Link Layer
3
uint16_t ARP_PRType;    //Protokoll Typ enth�lt den Code f�r IP o. anderes �bertragungsprotokoll
4
uint8_t  ARP_HWLen;    //L�nge der Hardwareadresse enth�lt 6 f�r 6 Byte lange MAC Adressen
5
uint8_t  ARP_PRLen;    //L�nge der Protocolladresse enth�lt 4 f�r 4 Byte lange IP Adressen
6
uint16_t ARP_Op;      //Enth�lt Code der signalisiert ob es sich um eine Anfrage o. Antwort handelt
7
uint8_t  ARP_SHAddr[6];  //Enth�lt die MAC Adresse des Anfragenden
8
uint32_t ARP_SIPAddr;    //Enth�lt die IP Adresse des Absenders
9
uint8_t  ARP_THAddr[6];  //MAC Adresse Ziel, ist in diesem Fall 6 * 00,da die Adresse erst noch herausgefunden werden soll (ARP Request)
10
uint32_t ARP_TIPAddr;    //IP Adresse enth�lt die IP Adresse zu der die Kommunikation aufgebaut werden soll
11
};

das Problem tritt - bislang - nur bei den IPadressen auf, die 6byte 
Werte werden als Arrays eingegeben, die 16bitter mit htons geladen. Wie 
löse ich das Problem IP am Besten? mit htonl oder mit u8-IP[4]?

Es scheint ja nur ein Problem der Umsetzung Netzwerkdaten/MC-Daten zu 
sein.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren