lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: leon . woestenberg
Subject: [lwip-users] Re: [lwip] lwIP in a non-OS environment
Date: Thu, 09 Jan 2003 01:30:16 -0000

Hello Alexander,

> I have some questions concering the usage of the lwIP-stack in an
> environment where no operating system could be used. We would like to
> integrate TCP/IP support to our PLC solutions, so the whole applications
is
> very time-critical.
> I didn't find much about lwIP w/o OS on raw API in the documentation I
hope
> you can help me to reach a decision if I could use lwIP.

> For developement purposes I'll use the Keil MCB-167NET Board. It is
equipped
> with an Infineon 167 and the Crystal CS8900 ethernet controller. We can't
> support an OS since we just want to build a network layer that can be
used
> with any of our existing applications (which are not only PLCs). The
network
> layer has to be called cyclic from the application to make sure that CPU
> time is shared between application and network layer. It is also
> unacceptable for us to wait for some kind of processing (i.e. semaphores)
> since we have time-critical applications with a maximum time per cyle
(i.e.
> PLC).
>
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've released a cs8900a driver which works fine (see the links on the lwIP
page).

> There are some missing information:
> - Does lwIP support an environment decribed above (no OS, no wait
timers)?
>
Yes, you are responsible for calling two TCP functions on a regular
interval.
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! :).

> - 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.

You can decide whether you want to process directly or act on the packet
later (using a flag).

I hope I have shared some useful experience,

Best regards,

Leon Woestenberg.


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]