Another element which combines the CPU and data moves and which is frequently used in the stack is the checksum mechanism. Providing checksum assembly routines, replacing the C equivalent functions is another optimization strategy that is effective.
As we are discovering, the IP protocol family is composed of several protocols. However, when developing an embedded system, ask yourself if you need them all. The answer is, probably not.
Another important question is: Is it possible to remove certain unused protocols from the stack? If the TCP/IP stack is well written, it should be possible to exclude protocols that are not required. Because an embedded system is often used in a private network, the embedded developer may decide not to implement protocols that are required on the public Internet. At this point, understanding each protocol's capabilities, as you will see in subsequent chapters, will help in deciding if that protocol is required for the application.
For any of the protocols listed below, if the feature is not required by the system, we may want to remove it from the target’s build (assuming that this is allowed by the TCP/IP stack architecture). The figures provided are only an estimate based on μC/TCP-IP. Other TCP/IP stacks may have different footprints depending on how closely they follow RFCs and how many of the specification’s features are actually included in each module.
The following are candidate protocols that can be removed from a TCP/IP stack if allowed by the stack software architecture:
The footprints (code size) for the protocols are approximations and can thus vary from one TCP/IP stack to another. Some of these protocols are not part of μC/TCP-IP and therefore show that a TCP/IP stack can work without them. Current μC/TCP-IP limitations include:
Without introducing all of the μC/TCP-IP modules and data structures, the following sections provide an estimate of the μC/TCP-IP code and data footprint. The complete list of files required to build μC/TCP-IP is provided in Chapter 12, “Directories and Files” on page 265.
3-2-4 μC/TCP-IP CODE FOOTPRINT
Memory footprints were obtained by compiling the code on a popular 32-bit CPU architecture. Compiler optimization was set to maximum optimization for size or speed as indicated. μC/TCP-IP options are set for most disabled or all enabled. The numbers are provided as orders of magnitude for design purposes.
The table excludes NIC, PHY, ISR and BSP layers since these are NIC and board specific.
3-2-5 μC/TCP-IP ADD-ON OPTIONS CODE FOOTPRINT
As seen in Layers 5-6-7 – The Application, services and standard application software modules found at the Application layer can be used in the product design to provide certain functionalities. Such application modules are offered as options for μC/TCP-IP. Although an in-depth discussion of memory footprint is outside the scope of this book, the memory footprint for the optional modules is included below for planning purposes. Chapter 9, “Services and Applications” on page 223 describes what some of these applications and services do and how they do it.
The footprints below were obtained by compiling the code on a popular 32-bit CPU architecture. The numbers are provided as orders of magnitude for design purposes.
Next: μC/TCP-IP DATA FOOTPRINT
Chapters of "µC/TCP-IP, the embedded protocol" are provided to UBM for users download and consultation, not for resale. Users wanting to know more about TCP/IP and Micrium can visit Micrium.