Implementation

The following sections provide an overview of how the port is structured regarding the interface between eCos and the core lwIP implementation.

System Configuration

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

System Source

The CYGPKG_NET_LWIP package provides some eCos specific functionality in the src/ecos/ directory.

  • lwip_ecos_init.cxx

    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.

    If CYGINT_IO_ETH_DRIVERS_PHY_EVENTS is 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.

  • sys_arch.cxx

    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 sys_mbox_t to eCos Cyg_Mbox objects.

    • Semaphore support, mapping lwIP sys_sem_t to eCos Cyg_Counting_Semaphore objects.

    • Thread support, mapping lwIP sys_thread_t to eCos Cyg_Thread objects.

    • Mutex support, mapping lwIP sys_mutex_t to eCos Cyg_Mutex objects.

    • Timer conversion support for converting between real-time-clock and millisecond ticks. The cyg_lwip_tick_to_msec and cyg_lwip_msec_to_tick functions may be useful to applications.

  • sio.c

    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_DEV for PPPoS, or CYGDAT_LWIP_SLIP_DEV for 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.

Threads

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, or 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 lwIP NO_SYS=0 manifest definition. The lwIP API thread will be created even if the CYGFUN_LWIP_SEQUENTIAL_API option is not enabled, unless over-ridden by the CYGFUN_LWIP_NO_SYS option.

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 CYGFUN_LWIP_SEQUENTIAL_API is disabled.

When the TCP/IP helper thread is required, the eCos lwIP run-time support will call the lwIP tcpip_init() function as part of the initialization sequence. The created eCos thread is named with the configured CYGDAT_LWIP_TCPIP_THREAD_NAME value, and with the priority as configured by CYGNUM_LWIP_NETWORK_THREAD_PRIORITY.

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_API support, and hence cannot be used with a CYGFUN_LWIP_NO_SYS configuration.

Caution

If the option CYGFUN_LWIP_NO_SYS is enabled then the system overhead required for suitably configured raw API applications will be minimised. It is the responsibility of the application to implement the necessary thread or polled model as desired for its specific, required, functionality.

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 recv()s).

  • uses semaphores

    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_SIZE should 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 manifset setting SYS_TIMEOUT_ENDTIME=1 is enforced for eCos builds. If the previous lwIP functionality is required then SYS_TIMEOUT_ENDTIME=0 and SYS_TIMEOUT_DELTA=1 should be manually configured in the lwipopts.h header file.

Caution

If the older SYS_TIMEOUT_DELTA=1 support is enabled then be aware that the default lwIP sources do not work on absolute times, and as such the lwIP idea of what time is will go wrong if the single lwIP thread is pre-empted for too long. In this case the lwIP code should really be executed in a high priority thread, but this is not enfored by default, as there may be application threads in the system which must run at a higher priority. This laxness of time management within lwIP can lead to problems with some sub-systems. For example, accuracy of DHCP lease-time renewal requests

2017-02-09
Documentation license for this page: eCosPro License