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

[Bill Knight]

Congratulations!  And whoopee too.  I had to drop the port a couple
of weeks ago and go back to fixing a commercial stack because of
project time constraints.  Even at this point we only have UDP
working.  TCP is still producing incorrect checksums on received
packets.

I have pondered more on your approach of packing everything into 16
bit words (and/or chars in this case) instead of just the lower 8
bits of the 16 bit chars of the DSP.  If you have been able to prod
the stack itself into accepting this, great!  It uses less memory and
probably less code space too.  The user is going to have to be very
careful in the manner in which data are submitted to and retrieved
from the stack.  It looks like it is going to have to be packed as it
goes in and sorted as it comes out.  I've been doing it the other way
around with the implementation I'm using (only the lower 8 bits of 16
bit chars).  A for instance of this is, given the following:
  char string[] = "This is a test string.";
the compiler only uses the lower 8 bits of each 16 bit word.  Or to
be more exact, it uses 1 char per character, just as it should.  If
this string were directly submitted and sent to a "normal" stack, it
would be received with NULLs placed between each ASCII character.
While I haven't downloaded and looked at the new version, I hope
issues like this are addressed.  Thinking out loud - maybe it is
possible to place a packed/not-packed flag in the pbuf header to
provide a signal to the stack as to the data format.  Or maybe a pair
of pack/unpack routines to assist in submitting and retrieving data
to and from the stack.  -- just thoughts.

I will try to find some time to try the new version.  With one
deadline this week and two more projects stacked up and waiting, they
don't give me much time to play with (err, explore more viable
solutions).

-Bill


On Tue, 11 Dec 2001 08:39:28 +0100, Adam Dunkels wrote:

>Hi Bill!
>
>On Friday 30 November 2001 20:49, you wrote:
>>   I'm new to this list and saw a post in the archives asking about
>> attempts to port lwIP to a TMS320 DSP.  Well, I just stopped work on
>> a port of it to a TMS320LF2407.  By far the most significant problem
>> (the one that stopped me) is that at least this particular DSP has a
>> 16 bit char.  That specifically means that u16_t and u8_t are the
>> same size.  Consequently the assumption that two successive u8_t's
>> can be singularly accessed and combined into a single u16_t is false.
>> lwIP (and most other stacks) seem to rely upon this assumption pretty
>> heavily.
>>   As an aside, the only stack I have found so far which seems to
>> operate without major rework is CMX MicroNet.
>
>It seems that the latest version of lwIP now works with a 16-bit u8_t type. I 
>haven't tested it thuroughly, only verified that it works with u8_t typedef'd 
>to a 16-bit "unsigned short". I think this would be a sufficient to say that 
>it works, but since I have no access to an actual system with an 8-bit char, 
>I cannot test it further. Does anyone have suggestion for testing it, or is 
>it enough to typedef the u8_t as a short?
>
>There was surprisingly few changes that needed to be made. The protocol 
>headers need to be fixed so that all fields was of the 16-bit u16_t type, and 
>macros was added to access the fields. This applies to the ARP, IP and TCP 
>headers. Of course, the code that accessed the headers also had to be 
>modified. A small change to the IP checksum function was also needed.
>
>You can download it from the homepage to review it, it you'd like. I'd very 
>much like to hear your comments on it.
>
>/adam
>-- 
>Adam Dunkels <address@hidden>
>http://www.sics.se/~adam
>
>[This message was sent through the lwip discussion list.]
>




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