Using Generic USB Controllersthe virtual COM-port device can NAK attempts by the USB host to send data.
When the remote device asserts CTS, the virtual COM-port device can send
the buffered data and begin accepting new data from the host. To use CTS in
this way, the USB host doesn’t need to know the signal’s state.
If you want to use CTS in an unconventional way, such as having a host appli-
cation read a switch state on a device, you’re out of luck unless you can define a
vendor-specific command that travels on the same bulk pipes that carry applica-
tion data or use a vendor-specific driver that supports reading CTS. .
,
Some chip companies provide example firmware for USB virtual COM ports
using generic microcontrollers that contain USB device controllers. Chips with
example code include Atmel Corporation’s AT89C5131, Microchip Technol-
ogy’s PIC18F4550, and NXP Semiconductors’ LPX214x. Example firmware
can be extremely helpful in getting a device up and running. Any of these exam-
ples is a good supplement to the material in this chapter.<
Table 16-2 shows required and optional requests for devices that use the
abstract control model.
The two required requests, SEND_ENCAPSULATED_COMMAND and
GET_ENCAPUSULATED_RESPONSE, enable the host to perform proto-
col-specific communications such as issuing an AT command or requesting a
response to a command. If the COM-port device doesn’t use AT commands,
the host will never send these requests.
For devices that have asynchronous serial interfaces, other requests monitor and
control the states of RS-232 signals that these devices might use. The
SET_LINE_CODING and GET_LINE_CODING requests set and request