UM0463

Programming model of the library

7/30

2

Programming model of the library

2.1

Handling control endpoint 0

The USB specification[1] defines four transfer types, Control, Interrupt, Bulk and

Isochronous. The USB host sends requests to the device through the control endpoint

(every USB device has only one control endpoint). The format of the requests is defined and

is sent to the device as a SETUP packet. The meaning of the requests is classified into

three categories: standard, class specific and vendor specific.

Since the standard requests are common and generic to all USB devices, the library

receives and handles all standard requests on the control endpoint 0. The library also

handles DFU specific requests by itself without any user code intervention. The library

answers requests without the intervention of the user application if the library has enough

information about the requests.

Otherwise, the library will call user application defined callback functions to process the

requests when some application actions are needed or some information from the

application is needed.

The format and the meaning of the class specific requests and the vendor specific requests

are not common to all USB devices. The library does not handle any of the requests in these

categories except DFU requests. Whenever the library receives a request that it does not

know, the library calls a user defined callback function and passes the request to the user

application code.

All the SETUP requests are processed with a state machine. Two models are implemented

to run this state machine, the polling model and the interrupt model.

As stated previously in Section 1.2.1: USB device, an interrupt is generated at the end of the

correct USB transfer. The library code receives this interrupt. In the interrupt process

routine, the trigger endpoint is identified. If the event is Correct Transfer on endpoint 0, the

state machine is started with the token received in the interrupt model immediately, or the

token received is saved and the state machine is started from the main loop in the polling

model afterward.

The advantage of the interrupt model is that the device answers the host requests to the

control endpoint in the fastest way which improves the overall performance of the whole

USB system. The disadvantage of the interrupt model is that the MCU global interrupt will

be disabled for a slightly longer time and the other application defined interrupt events have

to wait for the USB process finishes to be served. Some programming restrictions are

required in the interrupt model because of the limitation of the particular compiler.

On the other hand, the advantage and the disadvantage of the polling model are reversed.

The running of the USB state machine would not interfere with the other part of the

application. The application developer has the freedom to run the USB state machine at the

time when he/she wants. In the polling model, the library responds to the USB requests

quite slower than running in the interrupt model. This may slow down the bus in a fast

system or in systems with a lot of transactions on the control endpoint.

In the polling model, USB_Polling () is used to run the USB state machine. The user code

has to call this function from his/her main (see app_main () function) loop. The USB model is

selected in the configuration file (mcu_conf.h).