Description of the Ethernet Device Driver API

All device drivers must declare an instance of the appropriate device driver API structure as a global variable within the source code. The API structure is an ordered list of function pointers utilized by µC/TCP-IP when device hardware services are required.

A sample Ethernet interface API structure is shown below.

const  NET_DEV_API_ETHER  NetDev_API_<controler> = { NetDev_Init,                (1)
                                                     NetDev_Start,               (2)
                                                     NetDev_Stop,                (3)
                                                     NetDev_Rx,                  (4)
                                                     NetDev_Tx,                  (5)
                                                     NetDev_AddrMulticastAdd,    (6)
                                                     NetDev_AddrMulticastRemove, (7)
                                                     NetDev_ISR_Handler,         (8)
                                                     NetDev_IO_Ctrl,             (9)
                                                     NetDev_MII_Rd,             (10)
                                                     NetDev_MII_Wr              (11)
                                                    };

(1) Device initialization/add function pointer

(2) Device start function pointer

(3) Device stop function pointer

(4) Device Receive function pointer

(5) Device transmit function pointer

(6) Device multicast address add function pointer

(7) Device multicast address remove function pointer

(8) Device interrupt service routine (ISR) handler function pointer

(9) Device I/O control function pointer

(10) Physical layer (PHY) register read function pointer

(11) Physical layer (PHY) register write function pointer

It is the device driver developers’ responsibility to ensure that all of the functions listed within the API are properly implemented and that the order of the functions within the API structure is correct.

Note: µC/TCP-IP device driver API function names may not be unique. Name clashes between device drivers are avoided by never globally prototyping device driver functions and ensuring that all references to functions within the driver are obtained by pointers within the API structure. The developer may arbitrarily name the functions within the source file so long as the API structure is properly declared. The user application should never need to call API functions by name. Unless special care is taken, calling device driver functions by name may lead to unpredictable results due to reentrancy.

The following figure describes the call path from the application layer through the Core, Interface and Controller layers.