|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
eCos Support for Developing USB-ethernet Peripherals
|
eCos Support for Developing USB-ethernet Peripherals
|
|
|
|
|
|
|
|
|
|
|
Introduction
|
Introduction
|
|
|
|
|
Introduction
|
Introduction
|
eCos support for developing USB ethernet peripherals
|
eCos support for developing USB ethernet peripherals
|
|
|
|
|
Introduction
|
Introduction
|
|
|
The eCos USB-ethernet package provides additional support for USB
|
The eCos USB-ethernet package provides additional support for USB
|
peripherals that involve some sort of ethernet-style network. This can
|
peripherals that involve some sort of ethernet-style network. This can
|
be a traditional ethernet, or it can involve some other networking
|
be a traditional ethernet, or it can involve some other networking
|
technology that uses ethernet frames as a unit of transfer. It
|
technology that uses ethernet frames as a unit of transfer. It
|
provides functions to transfer ethernet frames over the USB bus,
|
provides functions to transfer ethernet frames over the USB bus,
|
handles certain control messages from the host, and optionally it can
|
handles certain control messages from the host, and optionally it can
|
provide a network device driver for use by the eCos TCP/IP stack.
|
provide a network device driver for use by the eCos TCP/IP stack.
|
The package comes with an example host-side device driver.
|
The package comes with an example host-side device driver.
|
|
|
|
|
The USB-ethernet package is not tied to any specific hardware. It
|
The USB-ethernet package is not tied to any specific hardware. It
|
requires the presence of USB hardware and a suitable device driver,
|
requires the presence of USB hardware and a suitable device driver,
|
but not all USB peripherals involve ethernet communications. Hence the
|
but not all USB peripherals involve ethernet communications. Hence the
|
configuration system cannot load the package automatically for
|
configuration system cannot load the package automatically for
|
specific targets, in the way that a USB device driver or an ethernet
|
specific targets, in the way that a USB device driver or an ethernet
|
driver can be loaded automatically. Instead, the package has to be
|
driver can be loaded automatically. Instead, the package has to be
|
added explicitly. When using the command line tools this will involve
|
added explicitly. When using the command line tools this will involve
|
an operation like the following:
|
an operation like the following:
|
|
|
|
|
$ ecosconfig add usbs_eth
|
$ ecosconfig add usbs_eth
|
|
|
|
|
Typically, this will automatically cause the USB device driver to
|
Typically, this will automatically cause the USB device driver to
|
become active. Loading the USB-ethernet package automatically provides
|
become active. Loading the USB-ethernet package automatically provides
|
functionality for initialization,
|
functionality for initialization,
|
data transfer, and the handling of
|
data transfer, and the handling of
|
control messages and state
|
control messages and state
|
changes. If the current configuration includes the eCos TCP/IP stack
|
changes. If the current configuration includes the eCos TCP/IP stack
|
then the network device driver
|
then the network device driver
|
support will be enabled as well by default, allowing the stack to
|
support will be enabled as well by default, allowing the stack to
|
exchange ethernet frames over the USB bus.
|
exchange ethernet frames over the USB bus.
|
|
|
|
|
There is a USB standard for a class of communication devices including
|
There is a USB standard for a class of communication devices including
|
ethernet. The package does not implement this standard, due to
|
ethernet. The package does not implement this standard, due to
|
limitations in the hardware for which the package was first developed.
|
limitations in the hardware for which the package was first developed.
|
Instead, the package uses its own
|
Instead, the package uses its own
|
linkend="usbseth-protocol">protocol between USB
|
linkend="usbseth-protocol">protocol between USB
|
host device driver and the
|
host device driver and the
|
peripheral.
|
peripheral.
|
|
|
|
|
|
|
Usage Scenarios
|
Usage Scenarios
|
|
|
The USB-ethernet package can be used several different scenarios. In
|
The USB-ethernet package can be used several different scenarios. In
|
a simple scenario, the peripheral serves only to connect the USB host
|
a simple scenario, the peripheral serves only to connect the USB host
|
to a suitable network:
|
to a suitable network:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After initialization, and once the USB connection between host and
|
After initialization, and once the USB connection between host and
|
peripheral has been established, higher-level code needs to detect
|
peripheral has been established, higher-level code needs to detect
|
packets that are intended for the host, and to forward these. This can
|
packets that are intended for the host, and to forward these. This can
|
be achieved by the low-level usbs_eth_start_tx
|
be achieved by the low-level usbs_eth_start_tx
|
function. Similarly, higher-level code needs to detect packets coming
|
function. Similarly, higher-level code needs to detect packets coming
|
from the host, using usbs_eth_start_rx, and to
|
from the host, using usbs_eth_start_rx, and to
|
forward these using the real network. As far as the host is concerned
|
forward these using the real network. As far as the host is concerned
|
it is connected directly to the network. In this scenario there is no
|
it is connected directly to the network. In this scenario there is no
|
confusion about addresses: there is a single MAC address for the
|
confusion about addresses: there is a single MAC address for the
|
host/peripheral combination, corresponding to the connection to the
|
host/peripheral combination, corresponding to the connection to the
|
real network, and it is this address which should be supplied during
|
real network, and it is this address which should be supplied during
|
initialization.
|
initialization.
|
|
|
|
|
In a more complicated scenario, there is a TCP/IP stack running inside
|
In a more complicated scenario, there is a TCP/IP stack running inside
|
the peripheral.
|
the peripheral.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This involves the USB-ethernet package providing a service both to the
|
This involves the USB-ethernet package providing a service both to the
|
host and to the eCos TCP/IP stack. It achieves the latter by acting as
|
host and to the eCos TCP/IP stack. It achieves the latter by acting as
|
an eCos network device. Typically, the TCP/IP stack will be configured
|
an eCos network device. Typically, the TCP/IP stack will be configured
|
to act as a network bridge. The USB peripheral needs to examine the
|
to act as a network bridge. The USB peripheral needs to examine the
|
packets arriving over the real network. Some of these packets will be
|
packets arriving over the real network. Some of these packets will be
|
intended for the host, while others will be intended for the
|
intended for the host, while others will be intended for the
|
peripheral itself. To distinguish between these two scenarios, two
|
peripheral itself. To distinguish between these two scenarios, two
|
distinct MAC addresses are needed: one for the host, and one for the
|
distinct MAC addresses are needed: one for the host, and one for the
|
peripheral. Similarly, packets sent by the host may have to be
|
peripheral. Similarly, packets sent by the host may have to be
|
forwarded via the real network, or they may be intended for the TCP/IP
|
forwarded via the real network, or they may be intended for the TCP/IP
|
stack inside the peripheral. Packets generated inside the peripheral's
|
stack inside the peripheral. Packets generated inside the peripheral's
|
TCP/IP stack may need to be sent via the real network or over the USB
|
TCP/IP stack may need to be sent via the real network or over the USB
|
bus. The network bridge software will have to take care of all these
|
bus. The network bridge software will have to take care of all these
|
possibilities. Unusually for a network bridge, one of the network
|
possibilities. Unusually for a network bridge, one of the network
|
segments being bridged will only ever have one machine attached.
|
segments being bridged will only ever have one machine attached.
|
|
|
|
|
There are other possible usage scenarios. For example, the peripheral
|
There are other possible usage scenarios. For example, the peripheral
|
might not be attached to a real network at all. Instead it could be
|
might not be attached to a real network at all. Instead it could be
|
the USB host that acts as a network bridge, allowing a TCP/IP stack
|
the USB host that acts as a network bridge, allowing a TCP/IP stack
|
inside the peripheral to communicate with the outside world. The
|
inside the peripheral to communicate with the outside world. The
|
various details will depend on the exact type of peripheral being
|
various details will depend on the exact type of peripheral being
|
developed.
|
developed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initializing the USB-ethernet Package
|
Initializing the USB-ethernet Package
|
|
|
|
|
usbs_eth_init
|
usbs_eth_init
|
Initializing the USB-ethernet Package
|
Initializing the USB-ethernet Package
|
|
|
|
|
|
|
|
|
|
|
#include <cyg/io/usb/usbs_eth.h>
|
#include <cyg/io/usb/usbs_eth.h>
|
|
|
|
|
void usbs_eth_init
|
void usbs_eth_init
|
usbs_eth* usbeth
|
usbs_eth* usbeth
|
usbs_control_endpoint* ep0
|
usbs_control_endpoint* ep0
|
usbs_rx_endpoint* ep1
|
usbs_rx_endpoint* ep1
|
usbs_tx_endpoint* ep2
|
usbs_tx_endpoint* ep2
|
unsigned char* mac_address
|
unsigned char* mac_address
|
|
|
|
|
|
|
|
|
Description
|
Description
|
|
|
The USB-ethernet package is not tied to any specific hardware. It
|
The USB-ethernet package is not tied to any specific hardware. It
|
requires certain functionality: there must be USB-slave hardware
|
requires certain functionality: there must be USB-slave hardware
|
supported by a device driver; there must also be two endpoints for
|
supported by a device driver; there must also be two endpoints for
|
bulk transfers between host and peripheral, one for each direction;
|
bulk transfers between host and peripheral, one for each direction;
|
there must also be a control endpoint, although of course that is
|
there must also be a control endpoint, although of course that is
|
implicit with any USB hardware.
|
implicit with any USB hardware.
|
|
|
|
|
However, USB-slave hardware may well provide more endpoints than the
|
However, USB-slave hardware may well provide more endpoints than the
|
minimum required for ethernet support. Some of those endpoints might
|
minimum required for ethernet support. Some of those endpoints might
|
be used by other packages, while other endpoints might be used
|
be used by other packages, while other endpoints might be used
|
directly by the application, or might not be needed for the peripheral
|
directly by the application, or might not be needed for the peripheral
|
being built. There is also the possibility of a USB peripheral that
|
being built. There is also the possibility of a USB peripheral that
|
supports multiple configurations, with the ethernet support active in
|
supports multiple configurations, with the ethernet support active in
|
only some of those configurations. The USB-ethernet package has no
|
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
|
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
|
it which endpoints should be used and other information. This is the
|
purpose of the usbs_eth_init function.
|
purpose of the usbs_eth_init function.
|
|
|
|
|
The first argument identifies the specific
|
The first argument identifies the specific
|
usbs_eth data structure that is affected. It
|
usbs_eth data structure that is affected. It
|
is expected that the vast majority of affected applications will only
|
is expected that the vast majority of affected applications will only
|
provide a single USB-ethernet device to a single host, and the package
|
provide a single USB-ethernet device to a single host, and the package
|
automatically provides a suitable data structure
|
automatically provides a suitable data structure
|
usbs_eth0 to support this. If multiple
|
usbs_eth0 to support this. If multiple
|
usbs_eth structures are needed for some
|
usbs_eth structures are needed for some
|
reason then these need to be instantiated by other code, and each one
|
reason then these need to be instantiated by other code, and each one
|
needs to be initialised by a call to
|
needs to be initialised by a call to
|
usbs_eth_init().
|
usbs_eth_init().
|
|
|
|
|
The next three arguments identify the endpoints that should be used
|
The next three arguments identify the endpoints that should be used
|
for USB communications: a control endpoint, a receive endpoint for
|
for USB communications: a control endpoint, a receive endpoint for
|
ethernet packets coming from the host to the peripheral, and a
|
ethernet packets coming from the host to the peripheral, and a
|
transmit endpoint for ethernet packets going in the other direction.
|
transmit endpoint for ethernet packets going in the other direction.
|
Obviously all three endpoints should be provided by the same USB
|
Obviously all three endpoints should be provided by the same USB
|
hardware. The USB-ethernet package assumes that it has sole access to
|
hardware. The USB-ethernet package assumes that it has sole access to
|
the receive and transmit endpoints, subject to the use of
|
the receive and transmit endpoints, subject to the use of
|
usbs_eth_disable and
|
usbs_eth_disable and
|
usbs_eth_enable control functions. The package
|
usbs_eth_enable control functions. The package
|
also assumes that no other code is interested in USB state changes or
|
also assumes that no other code is interested in USB state changes or
|
class control messages: it installs handlers
|
class control messages: it installs handlers
|
usbs_eth_state_change_handler
|
usbs_eth_state_change_handler
|
and
|
and
|
usbs_eth_class_control_handler
|
usbs_eth_class_control_handler
|
in the control endpoint. If any other code does need to handle USB
|
in the control endpoint. If any other code does need to handle USB
|
state changes or class control messages then replacement handlers
|
state changes or class control messages then replacement handlers
|
should be installed after the call to
|
should be installed after the call to
|
usbs_eth_init, and those replacements should
|
usbs_eth_init, and those replacements should
|
invoke the USB-ethernet ones when appropriate.
|
invoke the USB-ethernet ones when appropriate.
|
|
|
|
|
The final argument to usbs_eth_init specifies
|
The final argument to usbs_eth_init specifies
|
the MAC address (or Ethernet Station Address) that should be provided
|
the MAC address (or Ethernet Station Address) that should be provided
|
to the host-side device driver. Since the USB-ethernet package does not
|
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
|
interact directly with a real ethernet device it cannot obtain the MAC
|
address from any hardware. Instead, it must be supplied by higher-level
|
address from any hardware. Instead, it must be supplied by higher-level
|
code. The details depend on the
|
code. The details depend on the
|
linkend="usbseth-intro-scenarios">scenario in which the
|
linkend="usbseth-intro-scenarios">scenario in which the
|
USB-ethernet package is being used.
|
USB-ethernet package is being used.
|
|
|
|
|
The call to usbs_eth_init should normally happen
|
The call to usbs_eth_init should normally happen
|
after the enumeration data has been provided but before the underlying
|
after the enumeration data has been provided but before the underlying
|
USB device driver has been started. If the USB device were to be
|
USB device driver has been started. If the USB device were to be
|
started first then a connection between host and peripheral could be
|
started first then a connection between host and peripheral could be
|
established immediately, and the host-side device driver would attempt
|
established immediately, and the host-side device driver would attempt
|
to contact the USB-ethernet package for information such as the MAC
|
to contact the USB-ethernet package for information such as the MAC
|
address.
|
address.
|
|
|
|
|
int
|
int
|
main(int argc, char** argv)
|
main(int argc, char** argv)
|
{
|
{
|
unsigned char host_MAC[6] = { 0x40, 0x5d, 0x90, 0xa9, 0xbc, 0x02 };
|
unsigned char host_MAC[6] = { 0x40, 0x5d, 0x90, 0xa9, 0xbc, 0x02 };
|
|
|
usbs_sa11x0_ep0.enumeration_data = &usb_enum_data;
|
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_eth_init(&usbs_eth0, &usbs_sa11x0_ep0, &usbs_sa11x0_ep1, &usbs_sa11x0_ep2, host_MAC);
|
…
|
…
|
usbs_start(&usbs_sa11x0_ep0);
|
usbs_start(&usbs_sa11x0_ep0);
|
…
|
…
|
}
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USB-ethernet Data Transfers
|
USB-ethernet Data Transfers
|
|
|
|
|
USB-ethernet Data Transfers
|
USB-ethernet Data Transfers
|
Exchanging ethernet packets with the USB host
|
Exchanging ethernet packets with the USB host
|
|
|
|
|
|
|
|
|
|
|
#include <cyg/io/usb/usbs_eth.h>
|
#include <cyg/io/usb/usbs_eth.h>
|
|
|
|
|
|
|
void usbs_eth_start_rx
|
void usbs_eth_start_rx
|
usbs_eth* usbseth
|
usbs_eth* usbseth
|
unsigned char* buffer
|
unsigned char* buffer
|
void (*)(usbs_eth*, void*, int) complete_fn
|
void (*)(usbs_eth*, void*, int) complete_fn
|
void* complete_data
|
void* complete_data
|
|
|
|
|
|
|
void usbs_eth_start_tx
|
void usbs_eth_start_tx
|
usbs_eth* usbseth
|
usbs_eth* usbseth
|
unsigned char* buffer
|
unsigned char* buffer
|
void (*)(usbs_eth*, void*, int) complete_fn
|
void (*)(usbs_eth*, void*, int) complete_fn
|
void* complete_data
|
void* complete_data
|
|
|
|
|
|
|
|
|
|
|
Description
|
Description
|
|
|
The USB-ethernet package provides two main modes of operation. In the
|
The USB-ethernet package provides two main modes of operation. In the
|
first mode it provides a network device
|
first mode it provides a network device
|
driver for use by a TCP/IP stack running inside the USB
|
driver for use by a TCP/IP stack running inside the USB
|
peripheral. All incoming ethernet packages should be passed up the
|
peripheral. All incoming ethernet packages should be passed up the
|
TCP/IP stack, and only the stack will generate outgoing packets. Apart
|
TCP/IP stack, and only the stack will generate outgoing packets. Apart
|
from initialization and possibly
|
from initialization and possibly
|
certain control operations,
|
certain control operations,
|
higher-level code will not interact with the USB-ethernet package
|
higher-level code will not interact with the USB-ethernet package
|
directly.
|
directly.
|
|
|
|
|
In the second mode there is no TCP/IP stack running inside the USB
|
In the second mode there is no TCP/IP stack running inside the USB
|
peripheral. For example, a simple USB-ethernet converter has an
|
peripheral. For example, a simple USB-ethernet converter has an
|
ethernet chip and a USB port: ethernet packets received by the
|
ethernet chip and a USB port: ethernet packets received by the
|
ethernet chip need to be forwarded to the USB host, and ethernet
|
ethernet chip need to be forwarded to the USB host, and ethernet
|
packets sent by the USB host need to be sent out of the ethernet chip.
|
packets sent by the USB host need to be sent out of the ethernet chip.
|
usbs_eth_start_rx and
|
usbs_eth_start_rx and
|
usbs_eth_start_tx allow for this lower-level
|
usbs_eth_start_tx allow for this lower-level
|
access to the USB-ethernet package.
|
access to the USB-ethernet package.
|
|
|
|
|
The two modes of operation are mutually exclusive. If the network
|
The two modes of operation are mutually exclusive. If the network
|
device driver mode is enabled then application code should communicate
|
device driver mode is enabled then application code should communicate
|
at the TCP/IP level, and not by using the lower-level functions.
|
at the TCP/IP level, and not by using the lower-level functions.
|
Instead, it is the network device driver that will make use of these
|
Instead, it is the network device driver that will make use of these
|
functions, and it assumes that it has exclusive access. The package
|
functions, and it assumes that it has exclusive access. The package
|
does not perform any locking.
|
does not perform any locking.
|
|
|
|
|
The transmit and receive functions work in much the same way. The
|
The transmit and receive functions work in much the same way. The
|
first argument identifies the usbs_eth
|
first argument identifies the usbs_eth
|
structure that should be used. For the majority of applications this
|
structure that should be used. For the majority of applications this
|
will be usbs_eth0. The second argument specifies
|
will be usbs_eth0. The second argument specifies
|
the location of the ethernet packet; outgoing for
|
the location of the ethernet packet; outgoing for
|
usbs_eth_start_tx and incoming for
|
usbs_eth_start_tx and incoming for
|
usbs_eth_start_rx. This buffer should correspond
|
usbs_eth_start_rx. This buffer should correspond
|
to the protocol:
|
to the protocol:
|
|
|
|
|
|
|
|
|
Outgoing packets can consist of up to 1516 bytes, consisting of a
|
Outgoing packets can consist of up to 1516 bytes, consisting of a
|
two-byte header specific to USB-ethernet followed by a standard
|
two-byte header specific to USB-ethernet followed by a standard
|
ethernet frame (a header with 6-byte destination address, 6-byte
|
ethernet frame (a header with 6-byte destination address, 6-byte
|
source address and a further two bytes, followed by a payload of
|
source address and a further two bytes, followed by a payload of
|
up to 1500 bytes). The two-byte USB-ethernet header consists simply of
|
up to 1500 bytes). The two-byte USB-ethernet header consists simply of
|
the size of the ethernet frame, i.e. the size of the rest of the
|
the size of the ethernet frame, i.e. the size of the rest of the
|
packet not including the USB-ethernet header, with the least
|
packet not including the USB-ethernet header, with the least
|
significant byte first.
|
significant byte first.
|
|
|
|
|
|
|
|
|
For incoming packets the supplied buffer should usually be at least
|
For incoming packets the supplied buffer should usually be at least
|
1516 bytes. There may be special circumstances in which a smaller
|
1516 bytes. There may be special circumstances in which a smaller
|
buffer might be safe; for example, if the host-side device driver is
|
buffer might be safe; for example, if the host-side device driver is
|
modified to support only smaller packets. Once the packet has been
|
modified to support only smaller packets. Once the packet has been
|
received the buffer will contain a two-byte header specific to
|
received the buffer will contain a two-byte header specific to
|
USB-ethernet, followed by a normal ethernet frame. The header
|
USB-ethernet, followed by a normal ethernet frame. The header
|
gives the size of the ethernet frame, excluding the header, with the
|
gives the size of the ethernet frame, excluding the header, with the
|
least significant byte first.
|
least significant byte first.
|
|
|
|
|
|
|
|
|
Both usbs_eth_start_tx and
|
Both usbs_eth_start_tx and
|
usbs_eth_start_rx are asynchronous: the transfer
|
usbs_eth_start_rx are asynchronous: the transfer
|
is started and, some time later, a completion function will be invoked.
|
is started and, some time later, a completion function will be invoked.
|
The third and fourth arguments to both
|
The third and fourth arguments to both
|
usbs_eth_start_tx and
|
usbs_eth_start_tx and
|
usbs_eth_start_rx supply the completion function
|
usbs_eth_start_rx supply the completion function
|
and an argument to that function respectively. The completion function
|
and an argument to that function respectively. The completion function
|
will be invoked with three arguments: a pointer to the
|
will be invoked with three arguments: a pointer to the
|
usbs_eth data structure, usually
|
usbs_eth data structure, usually
|
usbs_eth0; the supplied completion data ; and a
|
usbs_eth0; the supplied completion data ; and a
|
return code field. A negative value indicates that an error occurred,
|
return code field. A negative value indicates that an error occurred,
|
for example -EPIPE if the connection between USB
|
for example -EPIPE if the connection between USB
|
host and peripheral has been broken, or -EAGAIN if
|
host and peripheral has been broken, or -EAGAIN if
|
an endpoint has been halted. A positive value indicates the total size
|
an endpoint has been halted. A positive value indicates the total size
|
of the transfer, which should correspond to the size in the
|
of the transfer, which should correspond to the size in the
|
USB-ethernet header plus an additional two bytes for the header
|
USB-ethernet header plus an additional two bytes for the header
|
itself.
|
itself.
|
|
|
|
|
If the data transfer is succesful then the completion function will
|
If the data transfer is succesful then the completion function will
|
typically be invoked in DSR context rather than in thread context,
|
typically be invoked in DSR context rather than in thread context,
|
although this depends on the implementation of the underlying USB
|
although this depends on the implementation of the underlying USB
|
device driver. Therefore the completion function is restricted in what
|
device driver. Therefore the completion function is restricted in what
|
it can do; in particular, it must not make any calls that will or may
|
it can do; in particular, it must not make any calls that will or may
|
block such as locking a mutex or allocating memory. The kernel
|
block such as locking a mutex or allocating memory. The kernel
|
documentation should be consulted for more details of DSR's and
|
documentation should be consulted for more details of DSR's and
|
interrupt handling generally. Note that if the transfer finishes
|
interrupt handling generally. Note that if the transfer finishes
|
quickly then the completion function may be invoked before
|
quickly then the completion function may be invoked before
|
usbs_eth_start_rx or
|
usbs_eth_start_rx or
|
usbs_eth_start_tx returns. This is especially
|
usbs_eth_start_tx returns. This is especially
|
likely to happen if the current thread is descheduled after starting
|
likely to happen if the current thread is descheduled after starting
|
the data transfer but before returning from these functions.
|
the data transfer but before returning from these functions.
|
|
|
|
|
For transmit operations, it is possible for
|
For transmit operations, it is possible for
|
usbs_eth_start_tx to invoke the completion
|
usbs_eth_start_tx to invoke the completion
|
function immediately. If there is no current connection between host
|
function immediately. If there is no current connection between host
|
and target then the transmit will fail immediately with
|
and target then the transmit will fail immediately with
|
-EPIPE. In addition the USB-ethernet package will
|
-EPIPE. In addition the USB-ethernet package will
|
check the destination MAC address and make sure that the ethernet
|
check the destination MAC address and make sure that the ethernet
|
frame really is intended for the host: either it must be for the
|
frame really is intended for the host: either it must be for the
|
address specified in the initialization call
|
address specified in the initialization call
|
linkend="usbseth-init">usbs_eth_init, or
|
linkend="usbseth-init">usbs_eth_init, or
|
it must be a broadcast packet, or the host must have enabled
|
it must be a broadcast packet, or the host must have enabled
|
promiscuous mode.
|
promiscuous mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USB-ethernet State Handling
|
USB-ethernet State Handling
|
|
|
|
|
USB-ethernet State Handling
|
USB-ethernet State Handling
|
Maintaining the USB-ethernet connection with the host
|
Maintaining the USB-ethernet connection with the host
|
|
|
|
|
|
|
|
|
|
|
#include <cyg/io/usb/usbs_eth.h>
|
#include <cyg/io/usb/usbs_eth.h>
|
|
|
|
|
|
|
usbs_control_return usbs_eth_class_control_handler
|
usbs_control_return usbs_eth_class_control_handler
|
usbs_control_endpoint* ep0
|
usbs_control_endpoint* ep0
|
void* callback_data
|
void* callback_data
|
|
|
|
|
|
|
void usbs_eth_state_change_handler
|
void usbs_eth_state_change_handler
|
usbs_control_endpoint* ep0
|
usbs_control_endpoint* ep0
|
void* callback_data
|
void* callback_data
|
usbs_state_change change
|
usbs_state_change change
|
int old_state
|
int old_state
|
|
|
|
|
|
|
void usbs_eth_disable
|
void usbs_eth_disable
|
usbs_eth* usbseth>
|
usbs_eth* usbseth>
|
|
|
|
|
void usbs_eth_enable
|
void usbs_eth_enable
|
usbs_eth* usbseth>
|
usbs_eth* usbseth>
|
|
|
|
|
|
|
|
|
|
|
Description
|
Description
|
|
|
When the USB-ethernet package is initialized by a call to
|
When the USB-ethernet package is initialized by a call to
|
linkend="usbseth-init">usbs_eth_init it
|
linkend="usbseth-init">usbs_eth_init it
|
installs usbs_eth_state_change_handler to handle
|
installs usbs_eth_state_change_handler to handle
|
USB state changes. This allows the package to detect when the
|
USB state changes. This allows the package to detect when the
|
connection between the host and the peripheral is established or
|
connection between the host and the peripheral is established or
|
broken, resulting in internal calls to
|
broken, resulting in internal calls to
|
usbs_eth_enable and
|
usbs_eth_enable and
|
usbs_eth_disable respectively. This is
|
usbs_eth_disable respectively. This is
|
appropriate if no other code needs to access the USB device. However,
|
appropriate if no other code needs to access the USB device. However,
|
if there is other code, either other USB-related packages or the
|
if there is other code, either other USB-related packages or the
|
application itself, that needs to perform I/O over the USB bus, then
|
application itself, that needs to perform I/O over the USB bus, then
|
typically the USB-ethernet package should not have exclusive access to
|
typically the USB-ethernet package should not have exclusive access to
|
state change events. Instead, the assumption is that higher-level
|
state change events. Instead, the assumption is that higher-level
|
code, typically provided by the application, will install an
|
code, typically provided by the application, will install an
|
alternative state change handler in the control endpoint data
|
alternative state change handler in the control endpoint data
|
structure after the call to usbs_eth_init. This
|
structure after the call to usbs_eth_init. This
|
alternative handler will either chain into
|
alternative handler will either chain into
|
usbs_eth_state_change_handler when appropriate,
|
usbs_eth_state_change_handler when appropriate,
|
or else it will invoke usbs_eth_enable and
|
or else it will invoke usbs_eth_enable and
|
usbs_eth_disable directly. For further details of
|
usbs_eth_disable directly. For further details of
|
state change handlers and control endpoints generally, see the
|
state change handlers and control endpoints generally, see the
|
documentation for the common USB-slave package.
|
documentation for the common USB-slave package.
|
|
|
|
|
Similarly, usbs_eth_init will install
|
Similarly, usbs_eth_init will install
|
usbs_eth_class_control_handler in the control
|
usbs_eth_class_control_handler in the control
|
endpoint data structure as the appropriate handler for class-specific
|
endpoint data structure as the appropriate handler for class-specific
|
USB control messages. This code will handle the ethernet-specific
|
USB control messages. This code will handle the ethernet-specific
|
control messages , for example
|
control messages , for example
|
requests by the host to enable or disable promiscuous mode or to
|
requests by the host to enable or disable promiscuous mode or to
|
obtain the MAC address. If the USB device is not shared with any other
|
obtain the MAC address. If the USB device is not shared with any other
|
code then this is both necessary and sufficient. However, if other code
|
code then this is both necessary and sufficient. However, if other code
|
is involved and if that code also needs to process certain control
|
is involved and if that code also needs to process certain control
|
messages, higher-level code should install its own handler and chain
|
messages, higher-level code should install its own handler and chain
|
to the USB-ethernet one when appropriate. It should be noted that the
|
to the USB-ethernet one when appropriate. It should be noted that the
|
request code is encoded in just a single byte, so there is a real
|
request code is encoded in just a single byte, so there is a real
|
possibility that exactly the same number will be used by different
|
possibility that exactly the same number will be used by different
|
protocols for different requests. Any such problems will have to be
|
protocols for different requests. Any such problems will have to be
|
identified and resolved by application developers, and may involve
|
identified and resolved by application developers, and may involve
|
modifying the source code for the USB-ethernet package.
|
modifying the source code for the USB-ethernet package.
|
|
|
|
|
As an alternative to chaining the state change handler, higher-level
|
As an alternative to chaining the state change handler, higher-level
|
code can instead call usbs_eth_disable and
|
code can instead call usbs_eth_disable and
|
usbs_eth_enable directly. These functions may
|
usbs_eth_enable directly. These functions may
|
also be called if the USB-ethernet package should become inactive for
|
also be called if the USB-ethernet package should become inactive for
|
reasons not related directly to events on the USB bus. The main effect
|
reasons not related directly to events on the USB bus. The main effect
|
of usbs_eth_enable is to restart receive
|
of usbs_eth_enable is to restart receive
|
operations and to allow transmits. The main effect of
|
operations and to allow transmits. The main effect of
|
usbs_eth_disable is to block further transmits:
|
usbs_eth_disable is to block further transmits:
|
any current receive operations need to be aborted at the USB level,
|
any current receive operations need to be aborted at the USB level,
|
for example by halting the appropriate endpoint.
|
for example by halting the appropriate endpoint.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Network Device for the eCos TCP/IP Stack
|
Network Device for the eCos TCP/IP Stack
|
|
|
|
|
Network Device
|
Network Device
|
USB-ethernet support for the eCos TCP/IP Stack
|
USB-ethernet support for the eCos TCP/IP Stack
|
|
|
|
|
Description
|
Description
|
|
|
If the USB peripheral involves running the eCos TCP/IP stack and that
|
If the USB peripheral involves running the eCos TCP/IP stack and that
|
stack needs to use USB-ethernet as a transport layer (or as one of the
|
stack needs to use USB-ethernet as a transport layer (or as one of the
|
transports), then the USB-ethernet package can provide a suitable
|
transports), then the USB-ethernet package can provide a suitable
|
network device driver. It is still necessary for higher-level code to
|
network device driver. It is still necessary for higher-level code to
|
perform appropriate initialization by calling
|
perform appropriate initialization by calling
|
linkend="usbseth-init">usbs_eth_init, but
|
linkend="usbseth-init">usbs_eth_init, but
|
after that it will be the TCP/IP stack rather than application code
|
after that it will be the TCP/IP stack rather than application code
|
that transmits or receives ethernet frames.
|
that transmits or receives ethernet frames.
|
|
|
|
|
Not all peripherals involving the USB-ethernet package will require a
|
Not all peripherals involving the USB-ethernet package will require a
|
TCP/IP stack. Hence the provision of the network device is controlled
|
TCP/IP stack. Hence the provision of the network device is controlled
|
by a configuration option CYGPKG_USBS_ETHDRV. By
|
by a configuration option CYGPKG_USBS_ETHDRV. By
|
default this will be enabled if the TCP/IP package
|
default this will be enabled if the TCP/IP package
|
CYGPKG_NET is loaded, and disabled otherwise.
|
CYGPKG_NET is loaded, and disabled otherwise.
|
|
|
|
|
There are a number of other configuration options related to the
|
There are a number of other configuration options related to the
|
network device. CYGFUN_USBS_ETHDRV_STATISTICS
|
network device. CYGFUN_USBS_ETHDRV_STATISTICS
|
determines whether or not the package will maintain statistics, mainly
|
determines whether or not the package will maintain statistics, mainly
|
intended for SNMP: by default this will be enabled if the SNMP support
|
intended for SNMP: by default this will be enabled if the SNMP support
|
package CYGPKG_SNMPAGENT is loaded, and disabled
|
package CYGPKG_SNMPAGENT is loaded, and disabled
|
otherwise. The name of the ethernet device is controlled by
|
otherwise. The name of the ethernet device is controlled by
|
CYGDATA_USBS_ETHDRV_NAME, and has a default value
|
CYGDATA_USBS_ETHDRV_NAME, and has a default value
|
of either eth0 or eth1
|
of either eth0 or eth1
|
depending on whether or not there is another network device driver
|
depending on whether or not there is another network device driver
|
present in the configuration.
|
present in the configuration.
|
|
|
|
|
Usually eCos network device drivers default to using DHCP for
|
Usually eCos network device drivers default to using DHCP for
|
obtaining necessary information such as IP addresses. This is not
|
obtaining necessary information such as IP addresses. This is not
|
appropriate for USB-ethernet devices. On the host-side the
|
appropriate for USB-ethernet devices. On the host-side the
|
USB-ethernet network device will not exist until the USB peripheral
|
USB-ethernet network device will not exist until the USB peripheral
|
has been plugged in and communication has been established. Therefore
|
has been plugged in and communication has been established. Therefore
|
any DHCP daemon on the host would not be listening on that network
|
any DHCP daemon on the host would not be listening on that network
|
device at the point that eCos requests its IP and other information. A
|
device at the point that eCos requests its IP and other information. A
|
related issue is that the use of DHCP would imply the presence of a
|
related issue is that the use of DHCP would imply the presence of a
|
DHCP daemon on every affected host machine, as opposed to a single
|
DHCP daemon on every affected host machine, as opposed to a single
|
daemon (plus backups) for the network as a whole. For these reasons
|
daemon (plus backups) for the network as a whole. For these reasons
|
the USB-ethernet package precludes the use of DHCP as a way of setting
|
the USB-ethernet package precludes the use of DHCP as a way of setting
|
the IP address, instead requiring alternatives such as manual
|
the IP address, instead requiring alternatives such as manual
|
configuration.
|
configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example Host-side Device Driver
|
Example Host-side Device Driver
|
|
|
|
|
Example Host-side Device Driver
|
Example Host-side Device Driver
|
Provide host-side support for the eCos USB-ethernet package
|
Provide host-side support for the eCos USB-ethernet package
|
|
|
|
|
Description
|
Description
|
|
|
The USB-ethernet package is supplied with a single host-side device
|
The USB-ethernet package is supplied with a single host-side device
|
driver. This driver has been developed against the Linux kernel
|
driver. This driver has been developed against the Linux kernel
|
2.2.16-22, as shipped with Red Hat 7. The driver is provided as is and
|
2.2.16-22, as shipped with Red Hat 7. The driver is provided as is and
|
should not be considered production quality: for example it only
|
should not be considered production quality: for example it only
|
checks for a bogus vendor id 0x4242 rather than an
|
checks for a bogus vendor id 0x4242 rather than an
|
official vendor id supplied by the
|
official vendor id supplied by the
|
url="http://www.usb.org/">USB Implementers Forum. Also, if the
|
url="http://www.usb.org/">USB Implementers Forum. Also, if the
|
peripheral involves multiple configurations or multiple interfaces, it
|
peripheral involves multiple configurations or multiple interfaces, it
|
will fail to detect this. However, the driver can be used for simple
|
will fail to detect this. However, the driver can be used for simple
|
testing and as the basis of a full device driver. Details of the
|
testing and as the basis of a full device driver. Details of the
|
protocol used between host and peripheral can be found in the
|
protocol used between host and peripheral can be found in the
|
linkend="usbseth-protocol">Communication Protocol section.
|
linkend="usbseth-protocol">Communication Protocol section.
|
|
|
|
|
The host-side device driver can be found in the
|
The host-side device driver can be found in the
|
class="directory">host subdirectory of the USB-ethernet
|
class="directory">host subdirectory of the USB-ethernet
|
package, specifically the file ecos_usbeth.c, and
|
package, specifically the file ecos_usbeth.c, and
|
comes with a Makefile. Both files may need
|
comes with a Makefile. Both files may need
|
to be modified for specific applications. For example, the vendor id
|
to be modified for specific applications. For example, the vendor id
|
table ecos_usbeth_implementations may need to be
|
table ecos_usbeth_implementations may need to be
|
updated for the specific USB peripheral being built. The
|
updated for the specific USB peripheral being built. The
|
Makefile assumes that the Linux kernel sources
|
Makefile assumes that the Linux kernel sources
|
reside in /usr/src/linux, and
|
reside in /usr/src/linux, and
|
that the kernel has already been configured and built. Assuming this
|
that the kernel has already been configured and built. Assuming this
|
is the case, the device driver can be built simply by invoking
|
is the case, the device driver can be built simply by invoking
|
make with no additional arguments. This will result
|
make with no additional arguments. This will result
|
in a dynamically loadable kernel module,
|
in a dynamically loadable kernel module,
|
ecos_usbeth.o, in the current directory.
|
ecos_usbeth.o, in the current directory.
|
|
|
|
|
|
|
As normal for Linux kernel builds, the generated files such as
|
As normal for Linux kernel builds, the generated files such as
|
ecos_usbeth.o live in the same directory as the
|
ecos_usbeth.o live in the same directory as the
|
source tree. This is very different from eCos where the source tree
|
source tree. This is very different from eCos where the source tree
|
(or component repository) is kept separate from any builds. There may
|
(or component repository) is kept separate from any builds. There may
|
be problems if the component repository is kept read-only or if it is
|
be problems if the component repository is kept read-only or if it is
|
put under source code control. Any such problems can be avoided by
|
put under source code control. Any such problems can be avoided by
|
making a copy of the host
|
making a copy of the host
|
subdirectory and building that copy.
|
subdirectory and building that copy.
|
|
|
|
|
|
|
Loading the kernel module into the current system requires root
|
Loading the kernel module into the current system requires root
|
privileges. If the generic USB support is also a loadable module and
|
privileges. If the generic USB support is also a loadable module and
|
has not been loaded already, this must happen first:
|
has not been loaded already, this must happen first:
|
|
|
|
|
# insmod usb-uhci
|
# insmod usb-uhci
|
Using /lib/modules/2.2.16-22/usb/usb-uhci.o
|
Using /lib/modules/2.2.16-22/usb/usb-uhci.o
|
|
|
|
|
Depending on the host hardware, the uhci or
|
Depending on the host hardware, the uhci or
|
usb-ohci modules may be more appropriate. Loading
|
usb-ohci modules may be more appropriate. Loading
|
the generic USB module will typically result in a number of messages
|
the generic USB module will typically result in a number of messages
|
to the logfile /var/log/messages, giving details
|
to the logfile /var/log/messages, giving details
|
of the specific host-side hardware that has been detected plus any
|
of the specific host-side hardware that has been detected plus any
|
hubs. The next step is to load the USB-ethernet module:
|
hubs. The next step is to load the USB-ethernet module:
|
|
|
|
|
# insmod ecos_usbeth.o
|
# insmod ecos_usbeth.o
|
|
|
|
|
This should result in a number of additional diagnostics in the
|
This should result in a number of additional diagnostics in the
|
logfile:
|
logfile:
|
|
|
|
|
Apr 1 18:01:08 grumpy kernel: eCos USB-ethernet device driver
|
Apr 1 18:01:08 grumpy kernel: eCos USB-ethernet device driver
|
Apr 1 18:01:08 grumpy kernel: usb.c: registered new driver ecos_usbeth
|
Apr 1 18:01:08 grumpy kernel: usb.c: registered new driver ecos_usbeth
|
|
|
|
|
If a suitable USB peripheral is now connected the host will detect
|
If a suitable USB peripheral is now connected the host will detect
|
this, assign an address in the local USB network, obtain enumeration
|
this, assign an address in the local USB network, obtain enumeration
|
data, and find a suitable device driver. Assuming the peripheral and
|
data, and find a suitable device driver. Assuming the peripheral and
|
device driver agree on the supported vendor ids, the
|
device driver agree on the supported vendor ids, the
|
ecos_usbeth.o module will be selected and this
|
ecos_usbeth.o module will be selected and this
|
will be reported in the system log:
|
will be reported in the system log:
|
|
|
|
|
Apr 1 18:04:12 grumpy kernel: usb.c: USB new device connect, assigned device number 3
|
Apr 1 18:04:12 grumpy kernel: usb.c: USB new device connect, assigned device number 3
|
Apr 1 18:04:12 grumpy kernel: eCos-based USB ethernet peripheral active at eth1
|
Apr 1 18:04:12 grumpy kernel: eCos-based USB ethernet peripheral active at eth1
|
|
|
|
|
What can happen next depends very much on the software that is running
|
What can happen next depends very much on the software that is running
|
on top of the USB-ethernet package inside the peripheral. For example,
|
on top of the USB-ethernet package inside the peripheral. For example,
|
if there is a TCP/IP stack then it should be possible to bring up a
|
if there is a TCP/IP stack then it should be possible to bring up a
|
network connection between host and peripheral using
|
network connection between host and peripheral using
|
ifconfig.
|
ifconfig.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication Protocol
|
Communication Protocol
|
|
|
|
|
Communication Protocol
|
Communication Protocol
|
Protocol used between the host-side device driver and the eCos
|
Protocol used between the host-side device driver and the eCos
|
USB-ethernet package
|
USB-ethernet package
|
|
|
|
|
Description
|
Description
|
|
|
There is a USB standard for the protocol to be used between the host
|
There is a USB standard for the protocol to be used between the host
|
and a class of communication devices, including ethernet. However, the
|
and a class of communication devices, including ethernet. However, the
|
eCos USB-ethernet package does not implement this protocol: the target
|
eCos USB-ethernet package does not implement this protocol: the target
|
hardware for which the package was first developed had certain
|
hardware for which the package was first developed had certain
|
limitations, and could not implement the standard. Instead, the package
|
limitations, and could not implement the standard. Instead, the package
|
implements a simple new protocol.
|
implements a simple new protocol.
|
|
|
|
|
A USB-ethernet peripheral involves bulk transfers on two endpoints:
|
A USB-ethernet peripheral involves bulk transfers on two endpoints:
|
one endpoint will be used for packets from host to peripheral and the
|
one endpoint will be used for packets from host to peripheral and the
|
other will be used for the opposite direction. Transfers in both
|
other will be used for the opposite direction. Transfers in both
|
directions are variable length, with a lower limit of 16 bytes and an
|
directions are variable length, with a lower limit of 16 bytes and an
|
upper limit of 1516 bytes. The first two bytes of each transfer
|
upper limit of 1516 bytes. The first two bytes of each transfer
|
constitute a header specific to USB-ethernet. The next 14 bytes form
|
constitute a header specific to USB-ethernet. The next 14 bytes form
|
the normal header for an ethernet frame: destination MAC address,
|
the normal header for an ethernet frame: destination MAC address,
|
source MAC address, and a protocol field. The remaining data, up to
|
source MAC address, and a protocol field. The remaining data, up to
|
1500 bytes, are the payload. The first two bytes give the size of the
|
1500 bytes, are the payload. The first two bytes give the size of the
|
ethernet frame, least significant byte first, with a value between 14
|
ethernet frame, least significant byte first, with a value between 14
|
and 1514.
|
and 1514.
|
|
|
|
|
For example an ARP request from host to peripheral involves an
|
For example an ARP request from host to peripheral involves an
|
ethernet frame of 42 bytes (0x002A), with the usual 14-byte header and
|
ethernet frame of 42 bytes (0x002A), with the usual 14-byte header and
|
a 28-byte payload. The destination is the broadcast address
|
a 28-byte payload. The destination is the broadcast address
|
0xFFFFFFFFFFFF. The source depends on the MAC address specified for
|
0xFFFFFFFFFFFF. The source depends on the MAC address specified for
|
the host in the call to
|
the host in the call to
|
linkend="usbseth-init">usbs_eth_init, e.g.
|
linkend="usbseth-init">usbs_eth_init, e.g.
|
0x405D90A9BC02. The remaining data is as specified by the appropriate
|
0x405D90A9BC02. The remaining data is as specified by the appropriate
|
IETF RFC's. The actual bulk
|
IETF RFC's. The actual bulk
|
USB transfer involves the following sequence of 44 bytes:
|
USB transfer involves the following sequence of 44 bytes:
|
|
|
|
|
2a 00 ff ff ff ff ff ff 40 5d 90 a9 bc 02 08 06
|
2a 00 ff ff ff ff ff ff 40 5d 90 a9 bc 02 08 06
|
00 01 08 00 06 04 00 01 40 5d 90 a9 bc 02 0a 00
|
00 01 08 00 06 04 00 01 40 5d 90 a9 bc 02 0a 00
|
00 01 00 00 00 00 00 00 0a 00 00 02
|
00 01 00 00 00 00 00 00 0a 00 00 02
|
|
|
|
|
In addition there are two control messages. These will be sent by the
|
In addition there are two control messages. These will be sent by the
|
host to endpoint 0, the control endpoint, and by default they will
|
host to endpoint 0, the control endpoint, and by default they will
|
be handled by
|
be handled by
|
usbs_eth_class_control_handler. If class-specific
|
usbs_eth_class_control_handler. If class-specific
|
control messages are intercepted by other code then it is the
|
control messages are intercepted by other code then it is the
|
responsibility of that code to invoke the USB-ethernet handler when
|
responsibility of that code to invoke the USB-ethernet handler when
|
appropriate.
|
appropriate.
|
|
|
|
|
The first control message can be used by the host to obtain a MAC
|
The first control message can be used by the host to obtain a MAC
|
address:
|
address:
|
|
|
|
|
#define ECOS_USBETH_CONTROL_GET_MAC_ADDRESS 0x01
|
#define ECOS_USBETH_CONTROL_GET_MAC_ADDRESS 0x01
|
|
|
|
|
The control message's type field should specify IN as the direction.
|
The control message's type field should specify IN as the direction.
|
The request field should be 0x01. The length fields
|
The request field should be 0x01. The length fields
|
should specify a size of 6 bytes. The remaining fields of the control
|
should specify a size of 6 bytes. The remaining fields of the control
|
message will be ignored by the USB-ethernet package. The response
|
message will be ignored by the USB-ethernet package. The response
|
consists of the 6-byte MAC address supplied by the initialization call
|
consists of the 6-byte MAC address supplied by the initialization call
|
|
|
linkend="usbseth-init">usbs_eth_init.
|
linkend="usbseth-init">usbs_eth_init.
|
|
|
|
|
The second control message can be used by the host to enable or
|
The second control message can be used by the host to enable or
|
disable promiscuous mode.
|
disable promiscuous mode.
|
|
|
|
|
#define ECOS_USBETH_CONTROL_SET_PROMISCUOUS_MODE 0x02
|
#define ECOS_USBETH_CONTROL_SET_PROMISCUOUS_MODE 0x02
|
|
|
|
|
This control message involves no further data so the length field
|
This control message involves no further data so the length field
|
should be set to 0. The value field should be non-zero to enable
|
should be set to 0. The value field should be non-zero to enable
|
promiscuous mode, zero to disable it. The request field should be
|
promiscuous mode, zero to disable it. The request field should be
|
0x02. The remaining fields in the control message
|
0x02. The remaining fields in the control message
|
will be ignored. It is the responsibility of the host-side device
|
will be ignored. It is the responsibility of the host-side device
|
driver to keep track of whether or not promiscuous mode is currently
|
driver to keep track of whether or not promiscuous mode is currently
|
enabled. It will be disabled when the peripheral changes to
|
enabled. It will be disabled when the peripheral changes to
|
Configured state, typically at the point where the host-side device
|
Configured state, typically at the point where the host-side device
|
driver has been activated.
|
driver has been activated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|