Module Relationships

Owned by Former user (Deleted)
Last updated: Jul 23, 2021 by WES Admin

Application

Your application layer needs to provide configuration information to µC/TCP-IP in the form of several C files: net_dev_cfg.c, net_cfg.h, net_dev_cfg.c and net_dev_cfg.h:

  • Configuration data in net_cfg.c/h consists of specifying tasks configuration, the number of timers to allocate to the stack, whether or not statistic counters will be maintained, the number of ARP cache entries, how UDP checksums are computed, and more. One of the most important configurations necessary is the size of the TCP Receive Window. In all, there are approximately 50 #define to set. However, most of the #define constants can be set to their recommended default value. 

  • net_dev_cfg.c consists of device-specific configuration requirements such as the number of buffers allocated to a device, the MAC address for that device, and necessary physical layer device configuration including physical layer device bus address and link characteristics. Each µC/TCP-IP-compatible device requires that its configuration be specified within net_dev_cfg.c.

µC/LIB Libraries

Given that µC/TCP-IP is designed for use in safety critical applications, all “standard” library functions such as strcpy(), memset(), etc. have been rewritten to conform to the same quality as the rest as the protocol stack. All these standard functions are part of a separate Micrium product called µC/LIB. µC/TCP-IP depends on this product. In addition, some data objects in the µC/TCP-IP stack are created at run-time which implies the use of memory allocation from the heap function  Mem_DynPoolAlloc().

BSD Socket API Layer

The application will interface with µC/TCP-IP using the BSD socket Application Programming Interface (API). The software developer can either write their own TCP/IP applications using the BSD socket API or, purchase a number of off-the-shelf TCP/IP components (Telnet, Web server, FTP server, etc.),for use with the BSD socket interface. Note that the BSD socket layer is shown as a separate module but is actually part of µC/TCP-IP.

Alternatively, the software developer can use µC/TCP-IP’s own socket interface functions (net_sock.*). net_bsd.* is a layer of software that converts BSD socket calls to µC/TCP-IP socket calls. Of course, a slight performance gain is achieved by interfacing directly to net_sock.* functions. Micrium network products use µC/TCP-IP socket interface functions.

TCP/IP Layer

The TCP/IP layer contains most of the CPU, RTOS and compiler-independent code for µC/TCP-IP. There are three categories of files in this section:

  1. TCP/IP protocol specific files include:

    1. Generic files:
      ICMP (net_icmp.*)
      IP (net_ip.*)
      TCP (net_tcp.*)
      UDP (net_udp.*)
    2. Files specific to IPv4:
      ARP (net_arp.*)
      IPv4 (net_ipv4.*)
      ICMPv4 (net_icmpv4.*)
      IGMP (net_igmp.*)
    3. Files specific to IPv6:
      NDP (net_ndp.*)
      IPv6 (net_ipv6.*)
      ICMPv6 (net_icmpv6.*)
      MLDP (net_mldp.*)
  2. Support files are:

    ASCII conversions (net_ascii.*)
    Buffer management (net_buf.*)
    TCP/UDP connection management (net_conn.*)
    Counter management (net_ctr.*)
    Statistics (net_stat.*)
    Timer Management (net_tmr.*)
    Other utilities (net_util.*).

  3. Miscellaneous header files include:

    Master µC/TCP-IP header file (net.h)
    File containing error codes (net_err.h)
    Miscellaneous µC/TCP-IP data types (net_type.h)
    Miscellaneous definitions (net_def.h)
    Debug (net_dbg.h)
    Configuration definitions (net_cfg_net.h)

Network Interface (IF) Layer

The IF Layer involves several types of network interfaces (Ethernet, Token Ring, etc.). However, the current version of µC/TCP-IP only supports Ethernet interfaces, wired and wireless. The IF layer is split into two sub-layers.

net_if.* is the interface between higher Network Protocol Suite layers and the link layer protocols. This layer also provides network device management routines to the application.

net_if_*.* contains the link layer protocol specifics independent of the actual device (i.e., hardware). In the case of Ethernet, net_if_ether.* understands Ethernet frames, MAC addresses, frame de-multiplexing, and so on, but assumes nothing regarding actual Ethernet hardware.

Network Device Driver Layer

As previously stated, µC/TCP-IP works with just nearly any network device. This layer handles the specifics of the hardware, e.g., how to initialize the device, how to enable and disable interrupts from the device, how to find the size of a received packet, how to read a packet out of the frame buffer, and how to write a packet to the device, etc.

In order for device drivers to have independent configuration for clock gating, interrupt controller, and general purpose I/O, an additional file, net_bsp.c, encapsulates such details.

net_bsp.c contains code for the configuration of clock gating to the device, an internal or external interrupt controller, necessary IO pins, as well as time delays, getting a time stamp from the environment, and so on. This file is assumed to reside in the user application.

Network Physical (PHY) Layer

Often, devices interface to external physical layer devices, which may need to be initialized and controlled. This layer is shown in Figure 2-1 asa “dotted” area indicating that it is not present with all devices. In fact, some devices have PHY control built-in. Micrium provides a generic PHY driver which controls most external (R)MII compliant Ethernet physical layer devices.

Network Wireless Manager

Often, wireless device may need to initialize a command and wait to receive the result (i.e. Scan). This layer manages specific wireless management commands. Micrium provides a generic Wireless Manager which should be able to controls most wireless module.

CPU Layer

µC/TCP-IP can work with either an 8, 16, 32 or even 64-bit CPU, but it must have information about the CPU used. The CPU layer defines such information as the C data type corresponding to 16-bit and 32-bit variables, whether the CPU is little or big endian, and how interrupts are disabled and enabled on the CPU.

CPU-specific files are found in the ...\uC-CPU directory and are used to adapt µC/TCP-IP to a different CPU, modify either the cpu*.* files or, create new ones based on the ones supplied in the uC-CPU directory. In general, it is much easier to modify existing files.

Real-Time Operating System (RTOS) Layer

µC/TCP-IP assumes the presence of an RTOS. An RTOS abstraction layer is also needed allowing µC/TCP-IP to be independent of a specific RTOS (See KAL Layer). µC/TCP-IP consists of three tasks. One task is responsible for handling packet reception, another task for asynchronous transmit buffer de-allocation, and the last task for managing timers. Depending on the configuration, a fourth task may be present to handle loopback operation.

As a minimum, the RTOS:

  1. Must be able to create at least three tasks (a Receive task, a Transmit De-allocation task, and a Timer task).
  2. Provide semaphore management (or the equivalent) and the µC/TCP-IP needs to be able to create at least two semaphores for each socket and an additional four semaphores for internal use.
  3. Provides queuing services.

Kernel Abstraction Layer (KAL)

KAL is a kernel abstraction layer employed by Micrium products to interact with the RTOS used. It can be found in the µC/Common directory. The KAL API is presented in the kal.h file. KAL comes with µC/OS-II and µC/OS-III ports. If a different RTOS is used, a new kal.c file must be develop to match the generic KAL API to the corresponding RTOS functionalities.