Initializing Interfaces

Initialize an Interface

Adding an Interface

Interfaces may be added to the stack by calling NetIF_Add(). Each new interface requires additional BSP. The order of addition is critical to ensure that the interface number assigned to the new interface matches the code defined within net_bsp.c. See section Network Interface Configuration for more information on configuring interfaces.

Starting an Interface

Interfaces may be started by calling NetIF_Start(). See section Starting and Stopping Network Interfaces for more information on starting interfaces.

Initialize an Ethernet Interface

Once µC/TCP-IP is initialized, each network interface must be added to the stack via NetIF_Add() function. NetIF_Add() validates the network interface arguments, initializes the interface, and adds it to the interface list of the TCP/IP stack. µC/TCP-IP uses a structure that contains pointers to API functions which are used to access the interface layer, and configuration structures are used to initialize resources needed by the network interface. You must pass the following arguments to the NetIF_Add() function:

Listing - NetIF_Add() arguments
NET_IF_NBR  NetIF_Add (void     *if_api,                               (1)
                       void     *dev_api,                              (2)
                       void     *dev_bsp,                              (3)
                       void     *dev_cfg,                              (4)
                       void     *ext_api,                              (5)
                       void     *ext_cfg,                              (6)
                       NET_ERR  *perr)                                 (7)


  1. The first argument specifies the link layer API pointers structure that will receive data from the hardware device. For an Ethernet interface, this value will always be defined as NetIF_API_Ether. This symbol is defined by µC/TCP-IP and it can be used to add as many Ethernet network interface’s as necessary. This API should always be provided with the TCP-IP stack which can be found under the interface folder (/IF/net_if_ether.*).

  2. The second argument represents the hardware device driver API pointers structure which is defined as a fixed structure of function pointers of the type specified by Micriµm for use with µC/TCP-IP. If Micriµm supplies the device driver, the symbol name of the device API will be defined within the device driver at the top of the device driver source code file. You can find the device driver under the device folder (/Dev/Ether/<controller>). Otherwise, the driver developer is responsible for creating the device driver and the API structure should start from the device driver template which can be found under the device folder (/Dev/Ether/Template).

  3. The third argument specifies the specific device’s board-specific (BSP) interface functions which is defined as a fixed structure of function pointers. The application developer must define both the BSP interface structure of function pointers and the actual BSP functions referenced by the BSP interface structure and should start from the BSP template provided with the stack which you can find under the BSP folder (/BSP/Template). Micriµm may be able to supply example BSP interface structures and functions for certain evaluation boards. For more information about declaring BSP interface structures and BSP functions device, see section Network Board Support Package for further information about the BSP API.

  4. The fourth argument specifies the device driver configuration structure that will be used to configure the device hardware for the interface being added. The device configuration structure format has been specified by Micriµm and must be provided by the application developer since it is specific to the selection of device hardware and design of the evaluation board. Micriµm may be able to supply example device configuration structures for certain evaluation boards. For more information about declaring a device configuration structure, see section Ethernet Device Configuration section.

  5. The fifth argument represents the physical layer hardware device API. In most cases, when Ethernet is the link layer API specified in the first argument, the physical layer API may be defined as NetPHY_API_Generic. This symbol has been defined by the generic Ethernet physical layer device driver which can be supplied by Micriµm. If a custom physical layer device driver is required, then the developer would be responsible for creating the API structure. Often Ethernet devices have built-in physical layer devices which are not (R)MII compliant. In this circumstance, the physical layer device driver API field may be left NULL and the Ethernet device driver may implement routines for the built-in PHY.

  6. The sixth argument represents the physical layer hardware device configuration structure. This structure is specified by the application developer and contains such information as the physical device connection type, address, and desired link state upon initialization. For devices with built in non (R)MII compliant physical layer devices, this field may be left NULL. However, it may be convenient to declare a physical layer device configuration structure and use some of the members for physical layer device initialization from within the Ethernet device driver. For more information about declaring a physical layer hardware configuration structure, see section Ethernet PHY Configuration.

  7. The last argument is a pointer to a NET_ERR variable that contains the return error code for NetIF_Add(). This variable should be checked by the application to ensure that no errors have occurred during network interface addition. Upon success, the return error code will be NET_IF_ERR_NONE.

Note: If an error occurs during the call to NetIF_Add(), the application may attempt to call NetIF_Add() a second time for the same interface but unless a temporary hardware fault occured, the application developer should observe the error code, determine and resolve the cause of the error, rebuild the application and try again. If a hardware failure occurred, the application may attempt to add an interface as many times as necessary, but a common problem to watch for is a µC/LIB Memory Manager heap out-of-memory condition. This may occur when adding network interfaces if there is insufficient memory to complete the operation. If this error occurs, the configured size of the µC/LIB heap within lib_cfg.h must be increased.

Once an interface is added successfully, the next step is to configure the interface with one or more network layer protocol addresses.

For a thorough description of the µC/TCP-IP files and directory structure, see section Directories and Files.

When the network interface is added without error, it must be started via the NetIF_Start() function to be available and be used by the µC/TCP-IP. The following code example shows how to initialize µC/TCP-IP, add an interface, configure the IP address and start it:

Listing - Ethernet interface initialization example
#include  <Source/net.h>
#include  <net_dev_dev1.h>
#include  <net_bsp.h>
#include  <net_phy.h>


CPU_BOOLEAN  App_InitTCPIP (void)
{
    NET_IF_NBR     if_nbr;
    NET_ERR        err;
 
    err = Net_Init(p_rx_task_cfg,                               
                   p_tx_task_cfg,
                   p_tmr_task_cfg);
    if (err != NET_ERR_NONE) {
        return (DEF_FAIL);
    }
    if_nbr  = NetIF_Add((void    *)&NetIF_API_Ether
                        (void    *)&NetDev_API_Etherxxx,
                        (void    *)&NetDev_BSP_API,
                        (void    *)&NetDev_Cfg_Ether_0,
                        (void    *)&NetPhy_API_Generic,
                        (void    *)&NetPhy_Cfg_0,
                        (NET_ERR *)&err);
    if (err != NET_IF_ERR_NONE) {
        return (DEF_FAIL);
    }

    NetIF_Start(if_nbr, &err);
    if (err != NET_IF_ERR_NONE) {
        return (DEF_FAIL);
    }
 
	return (DEF_OK);
}


Initialize an Wireless Interface

Once µC/TCP-IP is initialized each network interface must be added to the stack via the NetIF_Add() function which validates the network interface arguments, initializes the interface and adds it to the interface list. µC/TCP-IP uses a structure that contains pointers to API functions which are used to access the interface layer and configuration structures are used to initialize resources needed by the network interface. You must pass the following arguments to the NetIF_Add() function:

Listing - NetIF_Add() arguments
NET_IF_NBR  NetIF_Add (void     *if_api,                               (1)
                       void     *dev_api,                              (2)
                       void     *dev_bsp,                              (3)
                       void     *dev_cfg,                              (4)
                       void     *ext_api,                              (5)
                       void     *ext_cfg,                              (6)
                       NET_ERR  *perr)                                 (7)


  1. The first argument specifies the link layer API pointers structure that will receive data from the hardware device. For a wireless interface, this value will always be defined as NetIF_API_WiFi. This symbol is defined by µC/TCP-IP and it can be used to add as many wireless network interfaces as necessary. This API should always be provided with the TCP-IP stack which can be found under the interface folder (/IF/net_if_wifi.*).

  2. The second argument represents the hardware device driver API which is defined as a fixed structure of function pointers of the type specified by Micriµm for use with µC/TCP-IP. If Micriµm supplies the device driver, the symbol name of the device API will be defined within the device driver at the top of the device driver source code file. You can find the device driver under the device folder (/Dev/WiFi/<device>). Otherwise, the driver developer is responsible for creating the device driver and the API structure should start from the device driver template which can be found under the device folder (/Dev/WiFi/Template).

  3. The third argument specifies the specific device’s board-specific (BSP) interface functions which are defined as a fixed structure of function pointers. The application developer must define both the BSP interface structure of function pointers and the actual BSP functions referenced by the BSP interface structure and should start from the BSP template provided with the stack which you can find under the BSP folder (/BSP/Template). Micrium may be able to supply example BSP interface structures and functions for certain evaluation boards. For more information about declaring BSP interface structures and the BSP functions device, see Network Board Support Package for further information about the BSP API.

  4. The fourth argument specifies the device driver configuration structure that will be used to configure the device hardware for the interface being added. The device configuration structure format has been specified by Micriµm and must be provided by the application developer since it is specific to the selection of device hardware and design of the evaluation board. Micriµm may be able to supply example device configuration structures for certain evaluation boards. For more information about declaring a device configuration structure, see Wireless Device Configuration

  5. The fifth argument represents the extension layer device API. In most cases, when wireless is the Wireless Manager layer API specified in the first argument, the Wireless Manager layer API may be defined as NetWiFiMgr_API_Generic. This symbol has been defined by the generic Wireless Manager layer which can be supplied by Micriµm. If a custom Wireless Manager layer is required, then the developer would be responsible for creating the API structure.

  6. The sixth argument represents the extension layer configuration structure. This structure is specified by the application developer. For devices which use the generic Wireless Manager this field should be left NULL. However, it may be convenient to declare a Wireless Manager layer device configuration structure and use some of the members for Wireless Manager layer initialization from within the wireless device driver or a custom Wireless Manager.

  7. The last argument is a pointer to a NET_ERR variable that contains the return error code for NetIF_Add(). This variable should be checked by the application to ensure that no errors have occurred during network interface addition. Upon success, the return error code will be NET_IF_ERR_NONE.

Note: If an error occurs during the call to NetIF_Add(), the application may attempt to call NetIF_Add() a second time for the same interface but unless a temporary hardware fault occurred, the application developer should observe the error code, determine and resolve the cause of the error, rebuild the application and try again. If a hardware failure occurred, the application may attempt to add an interface as many times as necessary, but a common problem to watch for is a µC/LIB Memory Manager heap out-of-memory condition. This may occur when adding network interfaces if there is insufficient memory to complete the operation. If this error occurs, the configured size of the µC/LIB heap within app_cfg.h must be increased.

Once an interface is added successfully, the next step is to configure the interface with one or more network layer protocol addresses.

For a thorough description of the µC/TCP-IP files and directory structure, see Directories and Files.

Once a network interface is added without error, it must be started via the NetIF_Start() function to be seen as available and to be used by µC/TCP-IP. The following code example shows how to initialize µC/TCP-IP, add an interface, add an IP address and start the interface:


Listing - Wireless interface initialization example
#include  <net.h>
#include  <net_dev_rs9110n2x.h>
#include  <net_bsp.h>
#include  <net_phy.h>


CPU_BOOLEAN  App_InitTCPIP (void)
{
    NET_IF_NBR   if_nbr;
    NET_ERR      err;
 
    err = Net_Init();
    if (err != NET_ERR_NONE) {
        return (DEF_FAIL);
    }
    if_nbr  = NetIF_Add((void    *)&NetIF_API_WiFi
                        (void    *)&NetDev_API_RS9110N2x,
                        (void    *)&NetDev_BSP_SPI_API,
                        (void    *)&NetDev_Cfg_WiFi_0,
                        (void    *)&NetWiFiMgr_API_Generic,
                        (void    *) 0,
                        (NET_ERR *)&err);
    if (err != NET_IF_ERR_NONE) {
        return (DEF_FAIL);
    }

    NetIF_Start(if_nbr, &err);
    if (err != NET_IF_ERR_NONE) {
        return (DEF_FAIL);
    }
	
	return (DEF_OK);
}