Comtrol eCos - Manual (Page 603)

Chapter 46. Generic Ethernet Device Driver
The device_instance entry here would point to the struct eth_drv_sc entry previously defined. This allows the
network driver setup to work with any class of driver, not just ethernet drivers. In the future, there will surely be
serial PPP drivers, etc. These will use the
NETDEVTAB_ENTRY() setup to create the basic driver, but they will most
likely be built on top of other high-level device driver layers.
To instantiate itself, and connect it to the system, a hardware driver will have a template (boilerplate) which looks
something like this:
#include < cyg/infra/cyg_type.h >
#include < cyg/hal/hal_arch.h >
#include < cyg/infra/diag.h >
#include < cyg/hal/drv_api.h >
#include < cyg/io/eth/netdev.h >
#include < cyg/io/eth/eth_drv.h >
ETH_DRV_SC(DRV _sc,
0, // No driver specific data needed
"eth0", // Name for this interface
HRDWR_start,
HRDWR_stop,
HRDWR_control,
HRDWR_can_send
HRDWR_send,
HRDWR_recv,
HRDWR_deliver,
HRDWR_poll,
HRDWR_int_vector
);
NETDEVTAB_ENTRY(DRV _netdev,
"DRV ",
DRV_HRDWR_init,
&DRV _sc);
This, along with the referenced functions, completely define the driver.
Note: If one needed the same low-level driver to handle multiple similar hardware interfaces, you would need
multiple invocations of the
ETH_DRV_SC() / NETDEVTAB_ENTRY() macros. You would add a pointer to some in-
stance specific data, e.g. containing base addresses, interrupt numbers, etc, where the
0, // No driver specific data
is currently.
Review of the functions
Now a brief review of the functions. This discussion will use generic names for the functions — your driver should
use hardware-specific names to maintain uniqueness against any other drivers.
499