The following sections provide an overview of how the port is structured regarding the interface between eCos and the core lwIP implementation.
The normal lwIP approach of the “user” supplying
a lwipopts.h header file that provides
manifests to override the standard
lwIP opt.h header file is used to
configure the main stack features. For eCos
the lwipopts.h is provided as part of
CYGPKG_NET_LWIP package along with the lwIP generic
sources. Note: For eCos the lwipopts.h
also contains definitions for some lwIP features that do not yet have defaults
defined within opt.h.
The eCos lwipopts.h implementation itself sets the majority of the lwIP feature control options based on the standard eCos CDL (.ecc) configuration world.
CYGPKG_NET_LWIP package provides some eCos specific
functionality in the src/ecos/ directory.
This source file provides two functions that are normally called by the application. The function cyg_lwip_init is needed to initialize the lwIP network stack, and cyg_lwip_netif_print_info can optionally be called to output network interface address information.
CYGINT_IO_ETH_DRIVERS_PHY_EVENTSis configured to provide PHY event notification support then the functions cyg_net_eth_phy_ctx_acquire and cyg_net_eth_phy_dsr are available for network device drivers to manage per-interface event notification between the driver and lwIP TCP/IP stack layers.
This source file implements the majority of the run-time support needed by lwIP to execute under eCos, which mainly covers:
Mailbox support, mapping lwIP
Semaphore support, mapping lwIP
Thread support, mapping lwIP
Mutex support, mapping lwIP
Some serial I/O utility routines for SLIP and PPPoS support.
Only a single serial interface is support and is accessed via a named serial I/O device (either
CYGDAT_LWIP_PPP_DEVfor PPPoS, or
CYGDAT_LWIP_SLIP_DEVfor SLIP). The I/O device is configured with non-blocking RX, and blocking TX as per the requirements of the lwIP APIs. The lwIP package CDL does not enforce any specific serial configuration (due to the varied differences between architectures and driver feature sets), so the developer is responsible for ensuring a suitable serial I/O driver configuration.
The lwIP network stack is mostly thread-safe for sockets and the sequential API,
but not for the raw API. The most important caveat is that even for the
sequential API it is NOT thread-safe to access
the same BSD-style socket,
netconn, from multiple threads.
The default for eCos is for the run-time support to provide the TCP/IP
helper thread, which is enabled via the
NO_SYS=0 manifest definition. The lwIP API
thread will be created even if
CYGFUN_LWIP_SEQUENTIAL_API option is not
enabled, unless over-ridden by
Note: Disabling the “sequential” API option does not disable the TCP/IP helper thread for backwards compatibility with previous eCos configurations where the helper thread is expected even if the option
When the TCP/IP helper thread is required, the eCos lwIP run-time
support will call the lwIP
as part of the initialization sequence. The created eCos thread is
named with the
and with the priority as configured
Providing this thread allows simple raw API applications to interact with the eCos ethernet device drivers.
Note: The, mutually exclusive, SLIP and PPPoS features require the
CYGFUN_LWIP_SEQUENTIAL_APIsupport, and hence cannot be used with a
If the option
If SLIP support is configured then a handler thread is also created during the system initialization. As with the main lwIP thread the name and the priority of the thread can be set in the eCos configuration.
The current PPPoS implementation does not use a seperate helper thread, with the required RX work being done as part of the normal TCP/IP helper thread.
Note: At some points within the lwIP network stack the eCos scheduler is locked. Whilst this is only for short sections of code, this could disrupt real-time behaviour.
Thread-safety considerations regarding lwIP:
the network stack is thread-safe in general
However, individual sockets should not be shared between different eCos threads simultaneously (e.g. two threads doing overlapping
So priority inversion is possible.
coarse locking granularity
The whole lwIP network stack can remain locked for a long time whilst an operation is processed. This could exacerbate any priority inversion issues.
core lwIP code (and hence the raw API) is not thread-safe
mailboxes are used extensively
Mailboxes are used to funnel all threads' API requests into the lwIP context to avoid synchronisation problems, but this can cause priority inversion.
Also the effects of
CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZEshould be considered, since a very shallow mailbox depth could lead to client threads blocking waiting to post requests.
For eCos the timer support has been extended to provide absolute
timeout functionality to provide consistent timeout behaviour. The
enforced for eCos builds. If the previous lwIP functionality is
SYS_TIMEOUT_DELTA=1 should be manually
configured in the lwipopts.h
If the older