LwIP port using directly RTEMS semaphores and message queues

[Pavel Pisa]

Hello Gedare and others,

as I have already informed some offlist, Premysl Houdek
is working on TMS570 Ethernet driver and because we have
other OS LwIP port of it we decided to test LwIP on RTEMS
before possible attempt to port driver to RTEMS integrated
TCP/IP stack.

I have found some work on RTEMS LwIP port already done

git://github.com/ragunath3252/lwip-app.git

and

git://github.com/ragunath3252/lwip-nodrv

Is there some newer code?

Both of these ports looks to me as not directly mapping
LwIP services to RTEMS. The ports seems to build own
system constructs again based on mutex system service only.
I did not liked that too much and Premysl Houdek has
prepared new port which is based on direct mapping to RTEMS
services. His whole driver repository is still much work in
progress and includes branches of our other TMS570 drivers
and code from other non RTEMS projects for industrial partners
is included so until code is clean and fully rebased on RTEMS
headers etc. files and other stuff cannot be made public.

But I want to share and discuss the OS adaptation part which
is in shape now. The code is included in our LwIP repo primary
prepared to build LwIP under OMK make infrastructure for our
system less environment. We use same build infrastructure
for RTEMS so when code is included in RTEMS OMK template then
next configuration options are enough to build it

CONFIG_LWIP_LIB=y
CONFIG_LWIP_OS_PORT=rtems
CONFIG_LWIP_NO_SYS=0

There are no actual drivers (selectable by CONFIG_LWIP_DEVICE_DRIVERS
option) ported to RTEMS yet in our repo. Repo is available

git://git.code.sf.net/p/ulan/lwip-omk

Actual files specific for RTEMS (cc.h, perf.h, sys_arch.c, sys_arch.h)
can be found in 

http://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/ports/os/rtems/arch/

These files should be directly usable in other build system based
RTEMS projects. lwipopts.h for configuration are controlled
by CONFIG_* defines, so other variant has to be used for other builds

http://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/ports/os/lwipopts.h

The port has been tested to work/communicate with DHCP server and obtain
address and configure network. We have some TMS570 HW specific problems
with spurious interrupts (VIM resets it pending IRQ TMS570_VIM.IRQINDEX
index for EMAC interrupts when Flash instruction fetch bypassing (bit VE
in SCTLR) is enabled. But that problem is fully unrelated to RTEMS
port generic part.

I think that this port with direct mapping of services to RTEMS is
a cleaner approach and has generally smaller overhead.
There are things to consider still. We use counting semaphore as
per LwIP sys port specification. But I expect that it is used
in most (all?) cases to notify other party about new work and if the
other side is capable to do more consecutive work without need to
call sys function then simple binary only semaphore would eliminate
abundant loops.

The approach with self build object based on mutex and semaphores
has little less overhead in case of message queues.
LwIP stores only pointer size into them and RTEMS provides
queues which can be allocated for larger message size and store
size of data put into message in addition to the content.
So for some really memory constrained environment own specialized
queue object would take less memory and there is some code execution
overhead to store and check size as well.

But in general, I think code is clean and right way to go.
When we finish and clean other parts, we prepare complete
example for our RTEMS  application template.

As for LwIP and RTEMS integration in general, does exists some
idea/implementation how to make LwIP sockets the fist class RTEMS
citizens/objects - i.e. to get file descriptor compatible with RTEMS
read, write etc. calls same as for native RTEMS stack?

I would like to see select() supporting socket objects together
with notification from character drivers as well one day
to port applications waiting for more event sources in one thread
possible. But I think that select() is not compatible with
drivers even in RTEMS integrated stack. It it?

Best wishes,

              Pavel