[lwip-users] Re: [lwip] Re: lwIP on DSPs

[Adam Dunkels]

On Monday 03 December 2001 21.17, you wrote:
> All of the other code in the stack is written expecting an 8 bit
> char.  The stuct definition I gave supplies that.  This saves
> problems with a stucture like:
>
> struct foo {
> u8_t  value1;
> u16_t value2;
> };
>
> If you packed everything into words (16 bit) then the high order
> byte of value2 would have to share a word location with value1.
>
> The method I used would create a stuct like:
>
> struct foo {
> u8_t value1;
> u8_t value2[2];
> };
>
> While this takes up more RAM, it uses the same number of chars
> as the original.  Not elegant, but it should work and be reasonably
> easy to implement.

I still don't quite follow you, I'm afraid :-)

I would expect the following to work: These are the first 32 bits of the IP 
header (taken from RFC791):

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For a system with an 8 bit type, it would translate to

struct iphdr32bits8 {
  u8_t v_hl;
  u8_t tos;
  u16_t totlen;
}

For a system without an 8 bit type, I would use the 16 bit type instead and 
just define:

struct iphdr32bit16 {
  u16_t v_hl_tos;
  u16_t totlen;
}

Is it anything in this that would break with your DSP? (Or am I just missing 
something?)

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]