Instruction manual

Renesas USB MCU and USB ASSP USB Basic Host and Peripheral firmware
R01AN0512EJ0210 Rev.2.10 Page 18 of 157
Apr 1, 2013
Table 4-1 Peripheral Function Used
Control Transfer Stage Device Class Response to Host
Control read usb_pstd_StandReq1() Transmit data
Control write usb_pstd_StandReq2() Receive data
Control w/o data usb_pstd_StandReq3() Return status
Control read status usb_pstd_StandReq4() Receive status
Control write status usb_pstd_StandReq5() Return status
Control transfer end usb_pstd_StandReq0() None
4.2 API (Application Programming Interface)
This chapter has two sections; “ANSI” API, and PCD API. Select one in r_usb_usrconfig.h.
The ANSI type API is recommended for new projects.
4.2.1 ANSI API
A PDCD module (USB class driver) implements hardware control requests by using the ANSI API.
The ANSI API provides an-ANSI-type interface enabling the use of the same API for applications of different classes.
USB-BASIC-F/W provides five API functions: open(), close(), read(), write(), and control().
[Note]
1. PDCD cannot be registered with the ANSI API. Use the driver registration API
R_usb_pstd_DriverRegistration() to register the PDCD.
2. This ANSI API does not support control transfers during peripheral operations. Use the peripheral control
transfer API R_usb_pstd_ControlRead( ) /R_usb_pstd_ControlWrite( ) / R_usb_pstd_ControlEnd() for
control transfers in this case. (See
4.4 Peripheral Control Transfer )
A list of the ANSI-type API functions is shown in
Table 4-2.
Table 4-2 List of ANSI API functions
ANSI API Description
open() Confirm whether USB device class communication is enable or not.
close() End USB device class communication
read() Execute USB receive process
write() Execute USB send process
control() Execute process according to control code
4.2.2 General operation using ANSI API
To use the ANSI API, here is the general order of how to set up USB transfers.
1. Call open, with the relevant class number for your system.
2. After a successful open, call control to register the call-back functions that will be called by the Basic FW when
the application later uses the read and write APIs.
3. These application read and write calls will each cause the Basic FW to trigger the respective callbacks for the
transfer types registered by the control call(s), that is, there will be one call for each transfer type and direction.
4. Later, when for example a bulk OUT transfer has been completed, the registered user callback will trigger.
5. When your callback is triggered, take care of the incoming data - or for outgoing data do relevant processing for
successfully sent user data.
6. It is important to determine how many bytes have been sent or received in the user application data arrays. For
the Basic FW’s “vendor class” this application data is in the data arrays usb_gvendor_smpl_bi_data[][],
usb_gvendor_smpl_bo_data[][], usb_gvendor_smpl_ii_data[][], and usb_gvendor_smpl_io_data[][], depending