Freescale Medical Applications USB Stack Architecture
USB (Universal Serial Bus) is used to connect external devices to the host computer. USB is one of the most popular interfaces connecting devices such as cameras, keyboards, microphone, printers, ecc. USB interconnects are also getting popular in the medical segments. The Medical Applications USB stack enables you to use Freescale S08 and CFV1 silicon to make some devices.

Medical Applications USB Stack Architecture
The class driver layers implement various class drivers that have different functions. This driver interfaces with the device layer for its lower layer functions. For some functions, the device layers do not provide additional functionality and call the lower layer functions. Most of the validation for parameters is done in this layer. This layer must be independent of any underlying hardware and therefore can be ported on the different hardware platform with minimal changes. The device layer can sit on top of the controller layer that is the hardware dependent layer and interfaces the hardware registers. As stated earlier, the layered architecture helps the application developers to develop applications. However, it does not limit the developer to interface lower layer APIs if they prefer to.

S08 and CFV1 USB Stack Architecture Layers
Software Flows
The initialization flow starts when the application initializes the class driver that in turn initializes the low level driver and the controller. The class driver also registers the callbacks it requires for events occurring in the USB bus. Sometime after this, the host starts the enumeration process by sending the setup packet to get descriptors for device, configuration, and string. These requests are handled by the class driver that uses the descriptors defined by the application. The enumeration finally ends when the host sets the device configuration. At this point, the class driver notifies the application that the connection has been established.
Transmission Flow
The application transmits data to the USB host by calling the class driver specific send API. The class driver checks for the current status of the queue. If the queue is full then the function returns with a BUSY status, if there is already an outstanding request that has not been completed yet, it queues the request unless the queue is empty, it prepares to pass the request to the low level driver. As part of the preparation, it checks whether the bus is suspended or not. Incase the bus is suspended, it wakes the bus and the bus then sends the request to the lower layer driver. When the send API operation is completed, the class driver removes the request from the queue and sends the next in queue if it exists.
Reception Flow
When the controller receives the data on its receiver port, the low level driver sends an event to the class driver. The class driver calls the low level driver to receive the packet in its buffers. If the size of the packet is smaller than the size of the end-point buffer, then the class driver processes the packet immediately. If the size of the packet is greater than the endpoint buffer size, the class driver waits for an event from the low level driver with the complete packet. The class driver processes the packet after it is received.
Developing an Application
Perform these steps to develop a new application:
1. Make a new application directory under /device/app directory. The new application directory is
made to make the new application.
2. Copy the following files from the similar pre-existing applications.
— main.c
— usb_descriptor.c
— usb_descriptor.h
— user_config.h
Change these files to suit your application. The usb_descriptor.c and usb_descriptor.h files contain the descriptors for USB that are dependent on the application and the class driver. The
user_config.h contains configuration options. The main.c file contains the initial code for the device. If the device is changed, this file must also be modified accordingly.
3. Create the CodeWarrior directory where the project files for the new application can be created.
4. Create a new file for creating the main application function and the callback function as defined above.

New Application Directory
• usb_descriptor.c
This file contains USB Framework Module interface. It also contains various descriptors defined by USB Standards like, device descriptor, configuration descriptor, string descriptor and other class specific descriptors that are provided to Framework Module when requested. For customization, user can modify these variables and function mplementations to suit the requirement.
a) Variables
The list below shows user modifiable variables for an already implemented class driver. The user should also modify corresponding MACROs defined in usb_descriptor.h file. To save precious RAM space in S08 devices, constant variables are stored in ROM.
– usb_desc_ep
This is an array of endpoint structures. Endpoint structure describes the property of endpoint like, endpoint number, size, direction, type, and so on. This array should contain all the mandatory endpoints defined by USB class specifications. Sample code implementation of usb_desc_ep for HID class is given below:
const USB_ENDPOINTS usb_desc_ep =
{
HID_DESC_ENDPOINT_COUNT,
{
HID_ENDPOINT,
USB_INTERRUPT_PIPE,
USB_SEND,
HID_ENDPOINT_PACKET_SIZE,<---User Modifiable
}
< User can add other endpoints depending on class requirement >
};
– g_device_descriptor - this variable contains USB Device Descriptor
– g_config_descriptor - this variable contains USB Configuration Descriptor
– String Descriptors -users can modify string descriptors to customize their product. String descriptors are written in UNICODE format. An appropriate language identification number is specified in USB_STR_0. Multiple language support can also be added
– Standard Descriptor Table - users can modify standard descriptor table to support additional class specific descriptors and vendor specific descriptors
– g_valid_config_values this variable contains valid configurations for a device. This value remains fixed for a device
uint_8 const g_valid_config_values[USB_MAX_CONFIG_SUPPORTED+1]={0,1};– g_alternate_interface - this variable contains valid alternate interfaces for a given configuration. Sample implementation uses a single configuration. If user is implementing additional alternate interfaces then USB_MAX_SUPPORTED_INTERFACES macro (usb_descriptor.h)
should be changed accordingly
static uint_8 g_alternate_interface[USB_MAX_SUPPORTED_INTERFACES];
b) Interfaces
The interfaces are called by low level USB stack and class drivers.
– USB_Desc_Get_Descriptor - tThis interface function is invoked by USB Framework. This call is made when Framework receives GET_DESCRIPTOR call from Host.
– USB_Desc_Get_Endpoints - this interface function is called from class driver. This function returns a pointer to USB_ENDPOINT structure.
– USB_Desc_Get_Interface - this interface function invoked by USB Framework. This function returns a pointer to alternate interface for the specified interface.
– USB_Desc_Remote_Wakeup - this interface function invoked by USB Framework. If the application supports remote wakeup then this function return TRUE otherwise FALSE.
– USB_Desc_Set_Interface - this interface function is called from USB Framework. This function sets an alternate interface for specified interface.
– USB_Desc_Valid_Configation - this interface function is called from USB Framework.
– USB_Desc_Valid_Interface - this interface function is called from class driver to validate if the interface is valid or not.
• usb_descriptor.h
This file is mandatory for the application to implement. Framework and class drivers include this file for function prototype definitions and data structures described in usb_descriptor.c. User modifying usb_descriptor.c should also modify MACROs in this file as well.
• user_config.h
This file is required to define various compile time macros. These parameters are essential for successful compilation of source code.
Reference:
Medical Applications USB Stack
CONTACT REQUEST
If you want to know more about Freescale products, please submit your request to Arrow Italy using this form.
- Ionela's blog
- 222 reads





Post new comment