The USB-ethernet package is not tied to any specific hardware. It requires certain functionality: there must be USB-slave hardware supported by a device driver; there must also be two endpoints for bulk transfers between host and peripheral, one for each direction; there must also be a control endpoint, although of course that is implicit with any USB hardware.
However, USB-slave hardware may well provide more endpoints than the
minimum required for ethernet support. Some of those endpoints might
be used by other packages, while other endpoints might be used
directly by the application, or might not be needed for the peripheral
being built. There is also the possibility of a USB peripheral that
supports multiple configurations, with the ethernet support active in
only some of those configurations. The USB-ethernet package has no
knowledge about any of this, so it relies on higher-level code to tell
it which endpoints should be used and other information. This is the
purpose of the usbs_eth_init
function.
The first argument identifies the specific
usbs_eth
data structure that is affected. It
is expected that the vast majority of affected applications will only
provide a single USB-ethernet device to a single host, and the package
automatically provides a suitable data structure
usbs_eth0 to support this. If multiple
usbs_eth
structures are needed for some
reason then these need to be instantiated by other code, and each one
needs to be initialised by a call to
usbs_eth_init()
.
The next three arguments identify the endpoints that should be used
for USB communications: a control endpoint, a receive endpoint for
ethernet packets coming from the host to the peripheral, and a
transmit endpoint for ethernet packets going in the other direction.
Obviously all three endpoints should be provided by the same USB
hardware. The USB-ethernet package assumes that it has sole access to
the receive and transmit endpoints, subject to the use of
usbs_eth_disable
and
usbs_eth_enable
control functions. The package
also assumes that no other code is interested in USB state changes or
class control messages: it installs handlers
usbs_eth_state_change_handler
and
usbs_eth_class_control_handler
in the control endpoint. If any other code does need to handle USB
state changes or class control messages then replacement handlers
should be installed after the call to
usbs_eth_init
, and those replacements should
invoke the USB-ethernet ones when appropriate.
The final argument to usbs_eth_init
specifies
the MAC address (or Ethernet Station Address) that should be provided
to the host-side device driver. Since the USB-ethernet package does not
interact directly with a real ethernet device it cannot obtain the MAC
address from any hardware. Instead, it must be supplied by higher-level
code. The details depend on the scenario in which the
USB-ethernet package is being used.
The call to usbs_eth_init
should normally happen
after the enumeration data has been provided but before the underlying
USB device driver has been started. If the USB device were to be
started first then a connection between host and peripheral could be
established immediately, and the host-side device driver would attempt
to contact the USB-ethernet package for information such as the MAC
address.
int main(int argc, char** argv) { unsigned char host_MAC[6] = { 0x40, 0x5d, 0x90, 0xa9, 0xbc, 0x02 }; usbs_sa11x0_ep0.enumeration_data = &usb_enum_data; … usbs_eth_init(&usbs_eth0, &usbs_sa11x0_ep0, &usbs_sa11x0_ep1, &usbs_sa11x0_ep2, host_MAC); … usbs_start(&usbs_sa11x0_ep0); … } |