Probleme mit Code-Portierung von AVR nach ARM--> Zeigerumwandlung

[Stefan H. (stefan_h16)]

Hallo zusammen,

Ich versuche gerade den OpenMCP Code von AVR auf Cortex-M0 (LPC1115 um 
genau zu sein) zu portieren.

Dabei habe ich folgendes Problem:
Die Daten werden als char * buffer angeliefert (im einem konkreten 
Experiment Länge 149). Der Buffer ist auch in Ordnung ich kann in der 
Routine einen Dump davon ausgeben. Im IP Handler wird er dann 
konvertiert und macht Probleme:

//Zur Info
#define ETHERNET_HEADER_LENGTH    14
struct IP_header {
  uint8_t IP_Version_Headerlen;
  uint8_t IP_TOS;
  uint16_t IP_Totallenght;
  uint16_t IP_Identification;
  uint16_t IP_Flags_Fragmentoffset;
  uint8_t IP_TTL;
  uint8_t IP_Protocol;
  uint16_t IP_Headerchecksum;
  uint32_t IP_SourceIP;
  uint32_t IP_DestinationIP;
};
//Problemstelle
void ip( int packet_lenght ,  char *buffer )
  {
#ifdef PRINTF_DEBUG
int i;
printf("Ethernet buffer dump (size %d bytes):", packet_lenght);
for(i = 0;i<packet_lenght;i++)
  printf(" %d", buffer[i]);
printf("\n");
#endif

struct IP_header *IP_packet;
IP_packet = ( struct IP_header *)&buffer[ETHERNET_HEADER_LENGTH];
if ( IP_packet->IP_DestinationIP != myIP) //<-- Hier steigt das Programm reproduzierbar mit einem HardFault_Handler() aus
{
  #ifdef PRINTF_DEBUG
  printf("void ip (int, char *): Not for my IP\n");
  #endif
}
}

Kann mir jemand einen Hinweis geben woran das den liegt?

[Peter II (Gast)]

Stefan H. schrieb:
> IP_packet = ( struct IP_header *)&buffer[ETHERNET_HEADER_LENGTH];

das ergibt doch keinen sinn? Warum sollte der Header nach der 
ETHERNET_HEADER_LENGTH beginnen?

[Rufus Τ. F. (rufus)]

Deine Struktur ist nicht gepackt (#pragma pack), das aber ist bei 
Prozessorarchitekturen mit Wortbreiten > 8 Bit erforderlich, um ein 
bitgenaues Abbild Deiner Struktur zu erhalten.

Lass Dir mal sizeof (struct IP_header) ausgeben.

[Thomas S. (daimonion)]

Versuch mal

IP_packet = ( struct IP_header *)buffer;

Oder liegt der Start von dem Struct im Buffer an der 14. Stelle im 
Array?

Passen die Zielspeicherstellen von buffer und von IP_packet?

[Oliver S. (oliverso)]

Ich werf mal das Stichwort "alignment" in die Runde...

Oliver

[Stefan H. (stefan_h16)]

Rufus Τ. Firefly schrieb:
> Deine Struktur ist nicht gepackt (#pragma pack), das aber ist bei
> Prozessorarchitekturen mit Wortbreiten > 8 Bit erforderlich, um ein
> bitgenaues Abbild Deiner Struktur zu erhalten.
>
> Lass Dir mal sizeof (struct IP_header) ausgeben.

Vielen Dank. Das scheint das Problem ersteinmal gelöst zu haben.
Btw:

printf("IP Header size: %d \n", sizeof(struct IP_header)); //<-- gibt 28 aus

[Rolf M. (rmagnus)]

Peter II schrieb:
> Stefan H. schrieb:
>> IP_packet = ( struct IP_header *)&buffer[ETHERNET_HEADER_LENGTH];
>
> das ergibt doch keinen sinn? Warum sollte der Header nach der
> ETHERNET_HEADER_LENGTH beginnen?

Weil es sich um einen IP_header handelt, und der IP-Header halt nach 
dem Ethernet-Header kommt.

Rufus Τ. Firefly schrieb:
> Deine Struktur ist nicht gepackt (#pragma pack), das aber ist bei
> Prozessorarchitekturen mit Wortbreiten > 8 Bit erforderlich, um ein
> bitgenaues Abbild Deiner Struktur zu erhalten.

Man beachte, daß nicht jeder Prozessor mit Zugriffen auf Variablen mit 
falschem Alignment zurecht kommt.

[... (Gast)]

>printf("IP Header size: %d \n", sizeof(struct IP_header)); //<-- gibt 28 aus

siehste, und die struktur ist eigentlich nur 20Bytres groß. Das sind die 
zusätzlichen Padding-Bytes.. und die haben das Problem verursacht.


>Man beachte, daß nicht jeder Prozessor mit Zugriffen auf Variablen
>mit falschem Alignment zurecht kommt.
Mit so einem Kommentar macht man sich zwar wichtig, aber...... aach 
herje.
Bei ordnungsgemäßer Struktur-deklaration (packed) weiß der Compiler was 
er tut. Das missalginment ist dem Compiler doch bekannt....... und er 
kennt auch die Zielplatform...

[Rolf M. (rmagnus)]

... schrieb:
> Bei ordnungsgemäßer Struktur-deklaration (packed) weiß der Compiler was
> er tut. Das missalginment ist dem Compiler doch bekannt....... und er
> kennt auch die Zielplatform...

In diesem speziellen Fall ist es dem Compiler vielleicht bekannt, aber 
allgemein gilt das erstmal nicht. Daß der Compiler jetzt extra für ein 
paar Spezialfälle entsprechenden Code generiert, darauf würde ich mich 
nicht verlassen. Ich hatte jedenfalls schon auf ARM-Prozessoren 
entsprechende Exceptions beim Versuch von Zugriffen mit falschem 
Alignment.

[Daniel A. (daniel-a)]

Rolf Magnus schrieb:
> Ich hatte jedenfalls schon auf ARM-Prozessoren
> entsprechende Exceptions beim Versuch von Zugriffen mit falschem
> Alignment.

Der compiler weiss, was er tut. Das kann nur pasieren wenn man einen 
structmember mit falschem alignement referenziert, da dann die info des 
falschen alignements verloren geht.

Beim struct IP_header, wo und warum sind dort diese 6 bytes padding? Ich 
sehe nicht wo diese notwendig werden...

[Peter II (Gast)]

Daniel A. schrieb:
> Beim struct IP_header, wo und warum sind dort diese 6 bytes padding? Ich
> sehe nicht wo diese notwendig werden...

 uint8_t IP_Version_Headerlen;
 uint8_t IP_TOS;

nach jeden Byte, wenn die CPU nur auf Gerade Adresse zugreifen kann.

[(prx) A. K. (prx)]

... schrieb:
>>Man beachte, daß nicht jeder Prozessor mit Zugriffen auf Variablen
>>mit falschem Alignment zurecht kommt.
> Mit so einem Kommentar macht man sich zwar wichtig, aber...... aach
> herje.

Der Kommentar war zutreffend, da ...

> Bei ordnungsgemäßer Struktur-deklaration (packed)

... dies nicht erfolgte und der Cortex M0 bei misalignten Zugriffen 
aussteigt ...

> Das missalginment ist dem Compiler doch bekannt.......

... weil es dem Compiler ohne "packed" eben nicht bekannt ist. Ganz zu 
schweigen von der falschen Adresse.

Erschwerend kommt hinzu, dass auch "packed" nicht in jedem Fall hilft. 
Das sorgt nämlich nur dafür, dass er bei Inhalten, die ihm nun innerhalb 
der Structur als misaligned bekannt sind, entsprechend vorgeht. Auf 
innerhalb der Struktur korrekt alignte Komponenten kann auch bei 
"packed" normal zugegriffen werden.

Wenn also die gesamte Struktur schon misaligned ist, dann hilft auch 
"packed" nicht unbedingt. Und genau das kann hier der Fall sein, da ein 
Ethernet-Header kein Vielfaches von 4 lang ist und die Struktur per Cast 
aus einem Byte-Array an Offset 14 gefischt wird.

Manche Leute platzieren den Ethernet-Frame deshalb so, dass er bei
  (addr % 4) == 2
beginnt, weil dann die TCP/IP Header aligned sind. Bei PC-Prozessoren 
kann das sogar einen beträchtlichen Unterschied in der Performance 
ausmachen, da denen das Alignment zwar formal egal ist, aber misalingte 
Schreibzugriffe aufgrund der Arbeitsweise der CPU sehr langsam sein 
können.