[lwip-users] Re: [lwip] lwIP in a non-OS environment

[Alexander Groß]

Hi Leon,

| Scrap the word "PLC" and replace "Keil MCB-167NET" with "custom self-made"
| and you want exactly what we have! (Well, OK, we use a Infineon C166 :)

I will develop a library that is a whole network interface. It can be linked
against all our projects (we do not only make PLCs) to enable any
application communicating over TCP/IP using a unified API (and not having to
deal with TCP-specifics like ACK-handling and retransmission).


| I've released a cs8900a driver which works fine (see the links on the lwIP
| page).

I tried to port lwIP 0.5.0 including your CS8900 driver to Keil. I got a lot
of compiler warnings, often caused by unreferenced parameters in lwIP
functions (I don't understand why there are so many parameters which are
never used). When trying to compile your driver there was an error in line
98:
static const struct eth_addr ethbroadcast =
{{0xffU,0xffU,0xffU,0xffU,0xffU,0xffU}};
Somebody changed the MAC address to 3 WORDs instead of 6 bytes. I don't know
why.

Also it seems very complicated to write an appropriate sys_arch-adaption to
a non-OS environment. Is it possible to share some information about the
architecture layer for C16x w/ Keil?
I talked to somebody who works with lwIP. They use lwIP with an OS because
for them it seemed lwIP without OS would be "nothing more than a crutch". I
don't know if that's true. Is it working good for you?


| Yes, you are responsible for calling two TCP functions on a regular
| interval.

That would be no problem. I am going to implement a state machine that is
called after the PLC (or another application) has completed its work. So
there are two main "tasks" on the chip: First, the PLC runtime and second
the network layer.


| Basically, we have a cyclic main() that call functions depending on
whether
| an according event flag has been raised. Round-robin cooperative
| "scheduling"
| if you wish. Our functions are state-machines (yuk! :).

Phew... to write main()-functions would not be my task. The aim is to
provide nothing more that a lib that includes the whole network interface.
Changes to applicatons are not acceptable. We want a network interface that
applies to the application and not an application that has to be changes to
work with the net lib.
This is also because there are some existing network layers (i.e. RS232 and
CANopen) that use our network API. We just want to expand the range of
available network layers to TCP/IP.


| > - How can I give lwIP CPU cycles that it can process enqueued packets?
| >
| Basically, each time a packet is received by the network interface, you
| call a lwIP function that processes the packet (or, this is done using the
| network interface vector routine, if you use that). It will then callback
| to your application so that it can process the packet.

And how about sending packets? Do I need to deal with packet retransmissons
and lost ACKs for instance? Thats very important to me, because I already
coded with another stack that supports some kind of "non-blocking"-ness too,
but there you have to handle _everything_ covering a correct TCP
transmission (e.g. retransmisson).


| I hope I have shared some useful experience,

Of course! :)


Best regards,

Alex

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