Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.

Ethernet Device Driver Implementation
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. Ethernet interface API

Note: 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.

      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

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.

    1. Call path of controller functions
  • No labels