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

[Bill Knight]

Adam
  I've been doing some more thinking on the problem and it might not
be as bad as I originally thought.  My solution is similar to yours
with a change to the header structure definitions.  The problem with 16
bit chars if that only the lower 8 bits actually gets sent to the
network controller.  What is needed for sending to the network interface
is still an array (pbuf) of chars with only the lower 8 bits used in
each char. Also in <limits.h> there is a #define for CHAR_BIT
which is 16 on the processor I am working with.  So:

#if defined(CHAR_BIT) && (CHAR_BIT == 16)
// new struct for 16 bit chars
struct tcp_hdr {
  u8_t src[2], dest[2];
  u8_t seqno[4], ackno[4];
  u8_t offset_unused;
  u8_t flags;
  u8_t wnd[2];
  u8_t chksum[2];
  u8_t urgp[2];
};
#else
// existing struct for 8 bit chars
struct tcp_hdr {
  u16_t src, dest;
  u32_t seqno, ackno;
#ifdef HAVE_BITFIELDS
#if BYTE_ORDER == LITTLE_ENDIAN
  u8_t unused:4,
    offset:4;
#else
  u8_t offset:4,
    unused:4.
#endif
#else
  u8_t offset_unused;
#endif /* HAVE_BITFIELDS */
  u8_t flags;
  u16_t wnd;
  u16_t chksum;
  u16_t urgp;
};
#endif

Then in the code (wrapped with the appropriate #define's)

hdr->src[0] = src >> 8;
hdr->src[1] = src & 0xFF;

I have already rewritten th lower level of the chksum code.  It is:
static u32_t 
chksum(void *dataptr, int len)
{
  u32_t acc;
    
  for(acc = 0; len > 1; len -= 2) {
#if CHAR_BIT == 16
    acc += (u16_t)(*((u8_t *)dataptr)++) << 8;
    acc += (u16_t)(*((u8_t *)dataptr)++);
#else
    acc += *((u16_t *)dataptr)++;
  }

  /* add up any odd byte */
  if(len == 1) {
    acc += htons((u16_t)(*(u8_t *)dataptr) << 8);
    DEBUGF(INET_DEBUG, ("inet: chksum: odd byte %d\n", *(u8_t *)dataptr));
  }

  return acc;
}

The other headers and the code which reads and writes to them must be
changed appropriately.

Oh, one more thing.  Many compilers which have bit fields will not pack
bits into 8 bit values.  They will pack them into whatever size an int
is.  Be careful with the above existing struct definition.

Regards
-Bill

On Saturday 01 December 2001 17.05, you wrote:
> From what I found, the port of lwIP to a processor with 16 bits chars
> is a major undertaking.  It will take a very significant rewrite and
> the end result will be a lot different than the original.  If anyone
> plans to go though with it, my suggestion is to abandon efforts make
> the changes using #if's to switch between what is there now and what
> you will need to make it work.  You might use lwIP as a guide for
> what you need but much of it will have to be thrown out and
> re-written for the DSP.

I would be interested in hearing what your study has shown has to be 
rewritten. I haven't looked into the matter, but I would believe that only 
the structs that define protocol headers would be affected by the 16-bit 
u8_t. Also, the checksum calculation would have to be slightly modified. Have 
you found other places as well?

The fix would be a rewrite of the protocol implementations where the currect 
struct-based protocol header scheme would have to be replaced with something 
else. Perhaps by using #defines such as #define TCPH_FLAGS(x) to get the 
actual header fields. Those defines could then be tweaked to suite the 
particular architecture. For instance, on a systems with 16-bit chars, the 
TCP header could be defined as:

struct tcp_hdr {
  u16_t src, dest;
  u32_t seqno, ackno;
/*  u8_t offset; */
/*  u8_t flags; */
  u16_t offset_flags;
  u16_t wnd;
  u16_t chksum;
  u16_t urgp;
}

#define TCPH_SRC(hdr) (hdr)->src
#define TCPH_DEST(hdr) (hdr)->dest
#define TCPH_OFFSET(hdr) (ntohs((hdr)->offset_flags) >> 8)
#define TCPH_FLAGS(hdr) (ntohs((hdr)->offset_flags) & 0xff)
#define /* etc.*/

For a DSP with 32-bit chars, the equivalent (but a lot trickier) struct and 
#defines could be done. This way, the actual protocol code wouldn't have to 
be changed in any way. A single #define in arch/cpu.h or arch/cc.h would 
change they way the protocol headers are defined. 

Leon, your DHCP and ARP code used #defines in this way to extract header 
field values, perhaps you can comment on the above. Does your entire stack 
work this way? Were there any particular reson for doing it that way or for 
doing it the struct way (such as lwIP)?

In any case, this is a good thing to put into lwIP 0.6.

/adam


[This message was sent through the lwip discussion list.]