[lwip-users] Re: [lwip] lwIP ported to C166

[Adam Dunkels]

Hi!

Wow, the good news just keeps pouring in!

On Tuesday 09 October 2001 12:09, Jason Morgan wrote:
> As you know (Adam) I mentioned some time ago that I was going to do a low
> level Ethernet interface driver and ARP for lwIP.
> Well, I've finally got round to it.....
>
> The platform is an Infineon C166 (aka ST10) and the Ethernet MAC/PHY is a
> SMsC LAN91C96 (or LAN91C94)
> in porting the code into the Keil compiler, I've tried to keep changes to
> lwIP to a minimum, anyway so far
> its going well.

I'll add this to the news section of the lwIP homepage! Would you be willing 
to contribute your code back to lwIP? Are you using any OS or are you running 
lwIP on the bare bones hardware?

Regarding ARP: a few people have asked me if ARP will be included in lwIP, 
and a few have rolled their own implementations (such as Jason). I have began 
writing a small ARP that may be included in the next lwIP version. I have 
also been sent an ARP implementation specifically written for lwIP, but I 
haven't looked at it yet.

> I've come across some porting issues, I'll cover those later when I've
> fully understood their implications.

Ok!

> Are you gong to put lwIP on CVS, that way we can keep track of changes to
> it?

I have given it a few thoughts, yes. Currently, the lwIP development is 
version controlled with CVS but the repository is not public. I don't have 
any experience with setting up an anoncvs server, but I will talk with my 
local systems administrators and see if they have any ideas.

> Here are a list of 'bugs' or porting issues that I know of so
> far....(V0.4.1)


> In ip_addr.h and ip.c the macro ip_addr_isbroadcast has unbalanced brackets
> - delete one off the end.
> Its inference in ip.c in ip_input() is missing a corresponding bracket.

Oops! Quite surprising bug, since the compiler didn't complain. I gather you 
noticed it when using the ip_addr_isbroadcast for other purposes (in the ARP 
code, perhaps)?

> Keil does not like array sizes of 0, this is used in icmp_echo_hdr.data and
> tcp_hdr.options if I recall late array sizing
> is a C++ extension to C, C166 is not C++ :(  For now, I've put a suitable
> value in, but perhaps it should be a globaldef?

In fact, neither the icmp_echo_hdr.data nor the tcp_hdr.options fields are 
used in the code, so they can be deleted from the .h-files.

> in loop_if.c loopif_init() a cast is needed when the address of the function
> is got.

Ok! I changed the loopif_output() function to return "err_t" instead, and the 
"return 0" was changed to "return ERR_OK", and the "return 1" into "return 
ERR_MEM".

> in generic/cc.h the globaldef HAVE_BITFIELDS has an extra I between the T
> and the F.

Ok!

Thanks for your bug report!

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