Page Comparison

...

In transmission, the situation is different. The TCP/IP stack knows how much data is being transmitted. In addition to RAM being limited in embedded systems, another feature is the small amount of data that needs to be transmitted. For example, in the case of sensor data to be transmitted periodically, a few hundred bytes every second can be transferred. In this case, a small buffer can be used and save RAM instead of waste a large transmit buffer. Another example is the transmission of TCP acknowledgment packets, especially when they are not carrying any data back to the transmitter. These packets are also small and do not require a large transmit buffer. RAM is also saved.

Network Buffer Architecture

µC/TCP-IP uses both small and large network buffers:

• Network buffers
• Small transmit buffers
• Large transmit buffers
• Large receive buffers

A single network buffer is allocated for each small transmit, large transmit and large receive buffer. Network buffers contain the control information for the network packet data in the network buffer data area. Currently, network buffers consume approximately 200 bytes each. The network buffers’ data areas are used to buffer the actual transmit and receive packet data. Each network buffer is connected to the data area via a pointer to the network buffer data area, and both move through the network protocol stack layers as a single entity. When the data area is no longer required, both the network buffer and the data area are freed. The figure below depicts the network buffer and data area objects.

All transmit data areas contain a small region of reserved space located at the top of the data area address space. The reserved space is used for network protocol header data and is currently fixed to 134 bytes in length. In general, not all of this space is required. However, the network protocol header region has been sized according to the maximum network protocol header usage for TCP/IP Ethernet packets.

First, µC/TCP-IP copies application-specified data from the application buffer into the application data region before writing network protocol header data to the protocol header region. After that, depending on the type of the packet being sent, each required layers will add its own protocol headers in the Protocols Headers Region of the Data Area. Starting from the highest layer to the lowest layer, all required headers are stacked on top of each other.

Network Buffer Sizes (to review)

µC/TCP-IP requires that network buffer sizes configured in net_dev_cfg.c satisfy the minimum and maximum packet frame sizes of network interfaces/devices.

Assuming an Ethernet interface (with non-jumbo or VLAN-tagged frames), the minimum frame packet size is 64 bytes (including its 4-byte CRC). If an Ethernet frame is created such that the frame length is less than 60 bytes (before its 4-byte CRC is appended), frame padding must be appended by the network driver or the Ethernet network interface layer to the application data area to meet Ethernet’s minimum packet size. For example, the ARP protocol typically creates packets of 42 bytes and therefore 18 bytes of padding must be added. The additional padding must fit within the network buffer’s data area.

Ethernet’s maximum transmit unit (MTU) size is 1500 bytes. When TCP is used as the transport protocol, TCP and IP protocol header sizes are subtracted from Ethernet’s 1500-byte MTU. A maximum of 1460 bytes of TCP application data may be sent in a full-sized Ethernet frame.

In addition, the variable size of network packet protocol headers must also be considered when configuring buffer sizes. The following computations demonstrate how to configure network buffer sizes to transmit and receive maximum sized network packets.

For transmit buffer size configuration, each layer’s maximum header sizes must be assumed/included to achieve the maximum payload for each layer. The maximum header sizes for each layer are:

Max Ethernet header : 14 bytes (this is a fixed size w/o CRC)
Max ARP header : 28 bytes (this is a fixed size for Ethernet/IPv4)
Max IP header : 60 bytes (with maximum length IP options)
Max TCP header : 60 bytes (with maximum length TCP options)
Max UDP header : 8 bytes (this is a fixed size)

Assuming both TCP and UDP are available as transport layer protocols, TCP’s maximum header size is the value used as the maximum transport layer header size since it is greater than UDP’s header size. Thus, the total maximum header size can then be computed as:

Max Hdr Size = Interface Max Header (Ethernet hdr is 14 bytes)
             + Network Max Header (IP max hdr is 60 bytes)
             + Transport Max Header (TCP max hdr is 60 bytes)
             = 14 + 60 + 60 = 134 bytes 


µC/TCP-IP configures NET_BUF_DATA_PROTOCOL_HDR_SIZE_MAX with this value in net_cfg_net.h to use as the starting data area index for transmit buffers’ application data.

The next step is to define transmit buffers’ total data area size. The issue is that we used the maximum header size for the transport and network layers. However, most of the time, the network and transport layer headers typically do not have any options:

Typical IP header :  20 bytes (without IP options)
Typical TCP header : 20 bytes (without TCP options)

These header values are used to determine the maximum payload a Data Link frame can carry. Since a TCP header is larger than UDP headers, the following compares the TCP maximum payload, also known as TCP’s Maximum Segment Size (MSS), over an Ethernet data link:

TCP payload (max) = Interface Max (Ethernet 1514 bytes w/o CRC)
                  - Interface Header (Ethernet 14 bytes w/o CRC)
                  - Min IP Header (IP min hdr is 20 bytes) 
                  - Min TCP Header (TCP min hdr is 20 bytes)
                  = 1514 - 14 - 20 - 20 = 1460 bytes

When TCP is used in a system, it is recommended to configure the large buffer size to at least this size in order to transmit maximum size TCP MSS:

TCP Max Buf Size = Max TCP payload (1460 bytes)
                 + Max Hdr sizes (134 bytes)
                 = 1460 + 134 = 1594 bytes

If any IP or TCP options are used, it is possible that the payload must be reduced, but unfortunately, that cannot be known by the application when transmitting. It is possible that, when the packet is at the network layer and because the TCP or IP headers are larger than usual because an option is enabled, a packet is too large and needs to be fragmented to be transmitted. However, µC/TCP-IP does not yet support fragmentation; but since options are seldom used and the standard header sizes for TCP and IP are the ones supported, this is generally not a problem.

For UDP, the UDP header has no options and the size does not change – it is always 8 bytes. Thus, UDP’s maximum payload is calculated as follows:

UDP payload (max) = Interface Max (Ethernet 1514 bytes w/o CRC)
                  - Interface Header (Ethernet 14 bytes w/o CRC)
                  - Min IP Header (IP min hdr is 20 bytes)
                  - Min UDP Header (UDP hdr is 8 bytes)
                  = 1514 - 14 - 20 - 8 = 1472 bytes

So to transmit maximum-sized UDP packets, configure large buffer sizes to at least:

Max UDP Buf Size = Max UDP payload (1472 bytes)
                 + Max Hdr sizes (134 bytes)
                 = 1472 + 134 = 1606 bytes

ICMP packets which are encapsulated within IP datagrams also have variable-length header sizes from 8 to 20 bytes. However, for certain design reasons, ICMP headers are included in an IP datagram’s data area and are not included in the maximum header size calculation. (IGMP packets have a fixed header size of 8 bytes but are also included in an IP datagram’s data area.) Thus, ICMP’s maximum payload is calculated as follows:

ICMP payload (max) = Interface Max (Ethernet 1514 bytes w/o CRC)
                   - Interface Header (Ethernet 14 bytes w/o CRC)
                   - Min IP Header (IP min hdr is 20 bytes)
                   = 1514 - 14 - 20 = 1480 bytes

And to transmit maximum-sized ICMP packets, configure large buffer sizes to at least:

Max ICMP Buf Size = Max ICMP payload (1480 bytes)
                  + Max Hdr sizes (134 bytes)
                  = 1480 + 134 = 1614 bytes

Small transmit buffer sizes must also be appropriately configured to at least the minimum packet frame size for the network interface/device. This means configuring a buffer size that supports sending a minimum sized packet for each layer’s minimum header sizes. The minimum header sizes for each layer are:

Min Ethernet header : 14 bytes (this is a fixed size w/o CRC)
Min ARP header : 28 bytes (this is a fixed size for Ethernet/IPv4)
Min IP header : 20 bytes (with minimum length IP options)
Min TCP header : 20 bytes (with minimum length TCP options)
Min UDP header : 8 bytes (this is a fixed size)

For Ethernet frames, the following computation shows that both ARP packets and UDP/IP packets share the smallest minimum header sizes of 42 bytes:

ARP packet (min) = Interface Min Header (Ethernet 14 bytes w/o CRC)
                 + ARP Min Header (ARP min hdr is 28 bytes)
                 = 14 + 28 = 42 bytes

UDP packet (min) = Interface Min Header (Ethernet 14 bytes w/o CRC)
                 + IP Min Header (IP min hdr is 20 bytes)
                 + UDP Min Header (UDP min hdr is 8 bytes)
                 = 14 + 20 + 8 = 42 bytes

And since Ethernet packets must be at least 60 bytes in length (not including 4-byte CRC), small transmit buffers must be minimally configured to at least 152 bytes to receive the smallest payload for each layer:

Min Tx Pkt Size = Interface Min Size (Ethernet 60 bytes w/o CRC)
                + Max Hdr Sizes (134 bytes)
                - Min Pkt Size (42 bytes)
                = 60 + 134 - 42 = 152 bytes

The figure below shows transmit buffers with reserved space of 134 bytes/octets for the maximum protocol header sizes, application data sizes from 0 to 1472 bytes/octets, and the valid range of configured buffer data area sizes for Ethernet of 152 to 1614 bytes/octets. 

Note that the application data size range plus the maximum header sizes of 134 bytes do not exactly add up to the small or large transmit data area configuration total. This is due to certain protocols (e.g., ICMP) whose protocol headers are not included in the typical network protocol header region but start at index 134.

Also note that if no small transmit buffer data areas are available, a data area from the large transmit data area pool is allocated if both small and large transmit data areas are configured.

µC/TCP-IP does not require receive buffer data areas to reserve space for maximum header sizes but does require that each receive buffer data area be configured to the maximum expected packet frame size for the network interface/device. For Ethernet interfaces, receive buffers must be configured to at least 1514 bytes, assuming the interface’s Ethernet device is configured to discard and not buffer the packet’s 4-byte CRC, or 1518 bytes, if the device does buffer the CRC. Although network buffers may require additional bytes to properly align each buffer, µC/TCP-IP creates the buffers with the appropriate alignment specified in net_dev_cfg.c so no additional bytes need be added to the receive buffer size.

The following table shows how each network buffer should be configured to handle the majority of worst cases.

All μC/TCP-IP device drivers require a configuration structure for each device that must be compiled into your driver. You must place all device configuration structures and declarations within a pair of files named net_dev_cfg.c and net_dev_cfg.h.

Micrium provides sample configuration code free of charge; however, most sample code will likely require modification depending on the combination of compiler, processor, evaluation board, and device hardware used.

Memory Configuration

The first step in creating a device driver configuration for µC/TCP-IP begins with the memory configuration structure. This section describes the memory configuration settings for most device drivers, and should provide you an in-depth understanding of memory configuration. You will also discover which settings to modify in order to enhance the performances of the driver.

The listing below shows a sample memory configuration structurerequires that network buffer sizes configured in net_dev_cfg.c satisfy the minimum and maximum packet frame sizes of network interfaces/devices.

Assuming an Ethernet interface (with non-jumbo or VLAN-tagged frames), the minimum frame packet size is 64 bytes (including its 4-byte CRC). If an Ethernet frame is created such that the frame length is less than 60 bytes (before its 4-byte CRC is appended), frame padding must be appended by the network driver or the Ethernet network interface layer to the application data area to meet Ethernet’s minimum packet size. For example, the ARP protocol typically creates packets of 42 bytes and therefore 18 bytes of padding must be added. The additional padding must fit within the network buffer’s data area.

Ethernet’s maximum transmit unit (MTU) size is 1500 bytes. When TCP is used as the transport protocol, TCP and IP protocol header sizes are subtracted from Ethernet’s 1500-byte MTU. A maximum of 1460 bytes of TCP application data may be sent in a full-sized Ethernet frame.

In addition, the variable size of network packet protocol headers must also be considered when configuring buffer sizes. The following computations demonstrate how to configure network buffer sizes to transmit and receive maximum sized network packets.

Typical Buffers Size

The following table shows how each network buffer should be configured to handle the majority of worst cases.

Network Device Configuration

All μC/TCP-IP device drivers require a configuration structure for each device that must be compiled into your driver. You must place all device configuration structures and declarations within a pair of files named net_dev_cfg.c and net_dev_cfg.h.

Micriµm provides sample configuration code free of charge; however, most sample code will likely require modification depending on the combination of compiler, processor, evaluation board, and device hardware used.

Memory Configuration

The first step in creating a device driver configuration for µC/TCP-IP begins with the memory configuration structure. This section describes the memory configuration settings for most device drivers, and should provide you an in-depth understanding of memory configuration. You will also discover which settings to modify in order to enhance the performances of the driver.

The listing below shows a sample memory configuration structure.

const  NET_DEV_CFG  NetDev_Cfg_Dev1 = {
                           /* Structure member:                                           */
    NET_IF_MEM_TYPE_MAIN,  /*     .RxBufPoolType                                          */ (1)
    1518u,                 /*     .RxBufLargeSize                                         */ (2)
       9u,                 /*     .RxBufLargeNbr                                          */ (3)
      16u,                 /*     .RxBufAlignOctets                                       */ (4)
       0u,                 /*     .RxBufIxOffset                                          */ (5)

    NET_IF_MEM_TYPE_MAIN,  /*     .TxBufPoolType                                          */ (6)
    1606u,                 /*     .TxBufLargeSize                                         */ (7)
       4u,                 /*     .TxBufLargeNbr                                          */ (8)
      64u,                 /*     .TxBufSmallSize                                         */ (9)
       2u,                 /*     .TxBufSmallNbr                                          */ (10)
      16u,                 /*     .TxBufAlignOctets                                       */ (11)
       0u,                 /*     .TxBufIxOffset                                          */ (12)

    0x00000000u,           /*     .MemAddr                                                */ (13)
             0u,           /*     .MemSize                                                */ (14)

    NET_DEV_CFG_FLAG_NONE, /*     .Flag                                                   */ (15)
};

Ethernet Device Configuration

const  NET_DEV_CFG_ETHER  NetDev_Cfg_Dev1_0 = {
                           /* Structure member:                                           */
    NET_IF_MEM_TYPE_MAIN,  /*     .RxBufPoolType                                          */ (1)
    1518u,                 /*     .RxBufLargeSize                                         */
      10u,                 /*     .RxBufLargeNbr                                          */
       4u,                 /*     .RxBufAlignOctets                                       */
       0u,                 /*     .RxBufIxOffset                                          */

    NET_IF_MEM_TYPE_MAIN,  /*     .TxBufPoolType                                          */
    1606u,                 /*     .TxBufLargeSize                                         */
       4u,                 /*     .TxBufLargeNbr                                          */
      64u,                 /*     .TxBufSmallSize                                         */
       4u,                 /*     .TxBufSmallNbr                                          */
       4u,                 /*     .TxBufAlignOctets                                       */
       0u,                 /*     .TxBufIxOffset                                          */

    0x00000000u,           /*     .MemAddr                                                */
             0u,           /*     .MemSize                                                */

    NET_DEV_CFG_FLAG_NONE, /*     .Flag                                                   */

             6u,           /*     .RxDescNbr                                               */ (2)
             6u,           /*     .TxDescNbr                                               */ (3)
    0x40028000u,           /*     .BaseAddr                                                */ (4)
             0u,           /*     .DataBusSizeNbrBits                                      */ (5)
   "00:50:C2:25:61:00",    /*     .HW_AddrStr                                              */ (6)
};

const  NET_DEV_CFG_WIFI  NetDev_Cfg_WiFi_0 = {
                                           /* Structure member:                           */
    NET_IF_MEM_TYPE_MAIN,                  /*     .RxBufPoolType                          */ (1)
    1518u,                                 /*     .RxBufLargeSize                         */
       9u,                                 /*     .RxBufLargeNbr                          */
      16u,                                 /*     .RxBufAlignOctets                       */
       0u,                                 /*     .RxBufIxOffset                          */

    NET_IF_MEM_TYPE_MAIN,                  /*     .TxBufPoolType                          */
    1606u,                                 /*     .TxBufLargeSize                         */
       4u,                                 /*     .TxBufLargeNbr                          */
      64u,                                 /*     .TxBufSmallSize                         */
       2u,                                 /*     .TxBufSmallNbr                          */
      16u,                                 /*     .TxBufAlignOctets                       */
       0u,                                 /*     .TxBufIxOffset                          */

    0x00000000u,                           /*     .MemAddr                                */
             0u,                           /*     .MemSize                                */

    NET_DEV_CFG_FLAG_NONE,                 /*     .Flag                                   */

    NET_DEV_BAND_DUAL,                     /*     .Band                                    */ (2)

      25000000L,                           /*     .SPI_ClkFreq                             */ (3)
    NET_DEV_SPI_CLK_POL_INACTIVE_HIGH,     /*     .SPI_ClkPol                              */ (4)
    NET_DEV_SPI_CLK_PHASE_FALLING_EDGE,    /*     .SPI_ClkPhase                            */ (5)
    NET_DEV_SPI_XFER_UNIT_LEN_8_BITS,      /*     .SPI_XferUnitLen                         */ (6)
    NET_DEV_SPI_XFER_SHIFT_DIR_FIRST_MSB,  /*     .SPI_XferShiftDir                        */ (7)

   "00:50:C2:25:60:02",                    /*     .HW_AddrStr                              */ (8)
};

const  NET_IF_CFG_LOOPBACK  NetIF_Cfg_Loopback = {

    NET_IF_MEM_TYPE_MAIN,                             (1)
    1518,                                             (2)
      10,                                             (3)
       4,                                             (4)
       0,                                             (5)

    NET_IF_MEM_TYPE_MAIN,                             (6)
    1594,                                             (7)
       5,                                             (8)
      64,                                             (9)
       5,                                            (10)
       4,                                            (11)
       0,                                            (12)

    0x00000000,                                      (13)
             0,                                      (14)

    NET_DEV_CFG_FLAG_NONE                            (15)
};