The KLIM Zephyr will impress you by its performance and versatility. With its 3000 rotations per minute and an innovative cross flow turbine powered by a simple USB, it will cool YOU down as well as any of your electronic devices! With the KLIM Zephyr you get a cooling solution for your Laptop, Tablet, Smartphone and even yourself. Don’t connect any Zephyr Hardware to your PC until after the driver files are installed as part of your OmniSense software installation. Don’t install any Zephyr utilities on an Apple computer using a virtual PC interface, and then connect the BioHarness module to the computer. The device may behave unpredictably during subsequent operations. Now we need to support pen drive when Zephyr is working on USB host mode. But there is USB device mode only on Zephyr. Describe the solution you'd like Please provide a framework of USB host, like driver, api, protocol, etc. Describe alternatives you've considered Please provide thinking and methods that I might use to add. Additional context NA.

• USB device controller drivers (hardware dependent)
• USB device core layer (hardware independent)
• USB device class drivers (hardware independent)

USB Vendor and Product identifiers¶

The USB Vendor ID for the Zephyr project is 0x2FE3. The default USB ProductID for the Zephyr project is 0x100. The USB bcdDevice Device Release Numberrepresents the Zephyr kernel major and minor versions as a binary codeddecimal value. When a vendor integrates the Zephyr USB subsystem into aproduct, the vendor must use the USB Vendor and Product ID assigned to them.A vendor integrating the Zephyr USB subsystem in a product must not use theVendor ID of the Zephyr project.

The USB maintainer, if one is assigned, or otherwise the Zephyr TechnicalSteering Committee, may allocate other USB Product IDs based on well-motivatedand documented requests.

USB device controller drivers¶

The Device Controller Driver Layer implements the low level control routinesto deal directly with the hardware. All device controller drivers shouldimplement the APIs described in file usb_dc.h. This allows the integration ofnew USB device controllers to be done without changing the upper layers.For now only Quark SE USB device controller (Designware IP) is supported.

Structures¶

• ep_addr: endpoint address, the number associated with the EP in the deviceconfiguration structure.IN EP = 0x80 | <endpoint number>. OUT EP = 0x00 | <endpoint number>
• ep_mps: Endpoint max packet size.
• ep_type: Endpoint type, may be Bulk, Interrupt or Control. Isochronousendpoints are not supported for now.

• USB_DC_ERROR: USB error reported by the controller.
• USB_DC_RESET: USB reset.
• USB_DC_CONNECTED: USB connection established - hardware enumeration is completed.
• USB_DC_CONFIGURED: USB configuration done.
• USB_DC_DISCONNECTED: USB connection lost.
• USB_DC_SUSPEND: USB connection suspended by the HOST.
• USB_DC_RESUME: USB connection resumed by the HOST.
• USB_DC_INTERFACE: USB Interface selected by the HOST.
• USB_DC_UNKNOWN: Initial USB connection status.

• USB_DC_EP_SETUP: SETUP packet received.
• USB_DC_EP_DATA_OUT: Out transaction on this endpoint. Data is availablefor read.
• USB_DC_EP_DATA_IN: In transaction done on this endpoint.

APIs¶

The following APIs are provided by the device controller driver:

usb_dc_attach()

This function attaches USB for device connection. Upon success, the USB PLLis enabled, and the USB device is now capable of transmitting and receivingon the USB bus and of generating interrupts.

usb_dc_detach()

This function detaches the USB device. Upon success the USB hardware PLL ispowered down and USB communication is disabled.

usb_dc_reset()

This function returns the USB device to it’s initial state.

usb_dc_set_address()

This function sets USB device address.

usb_dc_set_status_callback()

This function sets USB device controller status callback. The registeredcallback is used to report changes in the status of the device controller.The status code are described by the usb_dc_status_code enumeration.

usb_dc_ep_configure()

This function configures an endpoint. usb_dc_ep_cfg_data structure providesthe endpoint configuration parameters: endpoint address, endpoint maximumpacket size and endpoint type.

usb_dc_ep_set_stall()

This function sets stall condition for the selected endpoint.

usb_dc_ep_clear_stall()

This functions clears stall condition for the selected endpoint

usb_dc_ep_is_stalled()

This function check if selected endpoint is stalled.

usb_dc_ep_halt()

This function halts the selected endpoint

usb_dc_ep_enable()

This function enables the selected endpoint. Upon success interrupts areenabled for the corresponding endpoint and the endpoint is ready fortransmitting/receiving data.

usb_dc_ep_disable()

This function disables the selected endpoint. Upon success interrupts aredisabled for the corresponding endpoint and the endpoint is no longer ablefor transmitting/receiving data.

usb_dc_ep_flush()

This function flushes the FIFOs for the selected endpoint.

usb_dc_ep_write()

This function writes data to the specified endpoint. The suppliedusb_ep_callback function will be called when data is transmitted out.

usb_dc_ep_read()

This function is called by the Endpoint handler function, after an OUTinterrupt has been received for that EP. The application must only call thisfunction through the supplied usb_ep_callback function.

usb_dc_ep_set_callback()

This function sets callback function for notification of data receivedand available to application or transmit done on the selected endpoint.The callback status code is described by usb_dc_ep_cb_status_code.

usb_dc_ep_read_wait()

This function is similar to usb_dc_ep_read, the difference being that, itdoesn’t clear the endpoint NAKs so that the consumer is not bogged down byfurther upcalls till he is done with the processing of the data. The callershould reactivate ep by invoking usb_dc_ep_read_continue() do so.

usb_dc_ep_read_continue()

Clear the endpoint NAK and enable the endpoint to accept more data from thehost. Usually called after usb_dc_ep_read_wait() when the consumer is fineto accept more data. Thus these calls together acts as flow controlmechanism.

usb_dc_ep_mps()

Get endpoint max packet size.

USB device core layer¶

The USB Device core layer is a hardware independent interface between USBdevice controller driver and USB device class drivers or customer applications.It’s a port of the LPCUSB device stack. It provides the followingfunctionalities:

• Responds to standard device requests and returns standard descriptors,essentially handling ‘Chapter 9’ processing, specifically the standarddevice requests in table 9-3 from the universal serial bus specificationrevision 2.0.
• Provides a programming interface to be used by USB device classes orcustomer applications. The APIs are described in the usb_device.h file.
• Uses the APIs provided by the device controller drivers to interact withthe USB device controller.

Structures¶

Callback function signature for the device status.

Callback function signature for the USB Endpoint.

Callback function signature for class specific requests. For host to devicedirection the ‘len’ and ‘payload_data’ contain the length of the received dataand the pointer to the received data respectively. For device to host classrequests, ‘len’ and ‘payload_data’ should be set by the callback functionwith the length and the address of the data to be transmitted bufferrespectively.

• ep_cb: callback function for notification of data received and availableto application or transmit done, NULL if callback not required byapplication code.
• ep_addr: endpoint address. The number associated with the EP in the deviceconfiguration structure.

• class_handler: handler for USB Class specific Control (EP 0)communications.
• custom_handler: the custom request handler gets a firstchance at handling the request before it is handed over to the‘chapter 9’ request handler.
• payload_data: this data area, allocated by the application, is used tostore class specific command data and must be large enough to store thelargest payload associated with the largest supported Class’ command set.

• usb_device_description: USB device description, seehttp://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors
• cb_usb_status: callback to be notified on USB connection status change
• interface: USB class handlers and storage space.
• num_endpoints: number of individual endpoints in the device configuration
• endpoint: pointer to an array of endpoint configuration structures(usb_cfg_data) of length equal to the number of EP associated with thedevice description, not including control endpoints.

The class drivers instantiates this with given parameters using the“usb_set_config” function.

USB device class drivers¶

To initialize the device class driver instance the USB device class drivershould call usb_set_config() passing as parameter the instance’s configurationstructure.

For example, for CDC_ACM sample application:

To enable the USB device for host/device connection:

The class device requests are forwarded by the USB stack core driver to theclass driver through the registered class handler.For the CDC ACM sample class driver, ‘cdc_acm_class_handle_req’ processesthe SET_LINE_CODING, CDC_SET_CONTROL_LINE_STATE and CDC_GET_LINE_CODINGclass requests:

The class driver should wait for the USB_DC_INTERFACE device status codebefore transmitting any data.

There are two ways to transmit data, using the ‘low’ level read/write API orthe ‘high’ level transfer API.

low level API:

To transmit data to the host, the class driver should call usb_write().Upon completion the registered endpoint callback will be called. Beforesending another packet the class driver should wait for the completion ofthe previous write. When data is received, the registered endpoint callbackis called. usb_read() should be used for retrieving the received data.For CDC ACM sample driver this happens via the OUT bulk endpoint handler(cdc_acm_bulk_out) mentioned in the endpoint array (cdc_acm_ep_data).

Drivers Zephyr Usb Devices Adapter

high level API:

Drivers Zephyr Usb Devices Pc Camera

The usb_transfer method can be used to transfer data to/from the host. Thetransfer API will automatically split the data transmission into one or moreUSB transaction(s), depending endpoint max packet size. The class driver doesnot have to implement endpoint callback and should set this callback to thegeneric usb_transfer_ep_callback.