Functions
UsbMscScsi.c File Reference

Detailed Description

Contains APIs related to MSC (Mass Storage) SCSI handling.

Functions

uint8_t USBMSC_processBuffer ()
 
uint8_t USBMSC_updateMediaInformation (uint8_t lun, struct USBMSC_mediaInfoStr *info)
 
uint8_t USBMSC_registerBufferInformation (uint8_t lun, uint8_t *RWbuf_x, uint8_t *RWbuf_y, uint16_t size)
 
USBMSC_RWbuf_Info * USBMSC_fetchInformationStructure (void)
 

Function Documentation

uint8_t USBMSC_processBuffer ( )

This function should be called by the application after it has processed a buffer request.

Parameters
USBMSC_Rwbuf_Info*RWBufInfoPass the value received from USBMSC_fetchInformationStructure().

This function should be called by the application after it has processed a buffer request. It indicates to the API that the application has fulfilled the request. Prior to calling this function, the application needs to write a return code to rwInfo.returnCode. This code should reflect the result of the operation. The value may come from the file system software, depending on the application. See Sec. 8.3.6 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for a list of valid return codes.

Returns
USB_SUCCEED
uint8_t USBMSC_updateMediaInformation ( uint8_t  lun,
struct USBMSC_mediaInfoStr *  info 
)

Informs the API of the Current State of the Media on LUN lun.

Parameters
lunis the logical unit (LUN) on which the operation is taking place. Zero-based. (This version of the API only supports a single LUN.)
infois a structure that communicates the most recent information about the medium.

Informs the API of the current state of the media on LUN lun. It does this using an instance info of the API-defined structure USBMSC_mediaInfoStr. The API uses the information in the most recent call to this function in automatically handling certain requests from the host. In LUNs that are marked as not removable in USBMSC_CONFIG, this function should be called once at the beginning of execution, prior to attachment to the USB host. It then no longer needs to be called.

In LUNS that are marked as removable, the media information is dynamic. The function should still be called at the beginning of execution to indicate the initial state of the media, and then it should also be called every time the media changes.

See Sec. 8.3.4 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for more about informing the API of media changes.

Returns
USB_SUCCEED
uint8_t USBMSC_registerBufferInformation ( uint8_t  lun,
uint8_t *  RWbuf_x,
uint8_t *  RWbuf_y,
uint16_t  size 
)

Gives the API a Buffer to Use for READ/WRITE Data Transfer.

Parameters
lunis the Lun number.
*RWbuf_xis the address of an X-buffer. If null, then both buffers are de-activated.
*RWbuf_yis the address of an Y-buffer. (Double-buffering is not supported in this version of the API.)
sizeis the size, in bytes, of the buffers.

Gives the API a buffer to use for READ/WRITE data transfer. size indicates the size of the buffer, in bytes.

NOTE: Currently, only single-buffering is supported, so RWbuf_y should be set to null. If the application intends to allocate the buffer statically, then this function needs only to be called once, prior to any READ/WRITE commands being received from the host. Most likely this would happen during the application's initialization functions.

NOTE: This API has to be called after the call to USBMSC_updateMediaInformation() at the beginning of execution.

However, this function optionally enables dynamic buffer management. That is, it can activate and de-activate the buffer, by alternately assigning a null and valid address in RWbuf_x. This is useful because the buffer uses a significant portion of the RAM resources (typically 512 bytes). This memory is not needed when USB is not attached or suspended.

If doing this, it's important that the application re-activate the buffer when USB becomes active again, by issuing another call to the function, this time using valid buffer information. If the API needs the buffer and doesn't have it, it will begin failing READ/WRITE commands from the host. The re-activation can take place within USB_handleVbusOffEvent().

size must be a multiple of a block size - for FAT, a block size is typically 512 bytes. Thus values of 512, 1024, 1536, etc. are valid. Non-multiples are not valid.

The function returns USB_SUCCEED every time. It is up to the application to ensure that the buffers are valid.

Returns
USB_SUCCEED
USBMSC_RWbuf_Info* USBMSC_fetchInformationStructure ( void  )

Returns a pointer to the USBMSC_Rwbuf_Info structure instance maintained within the API.

Returns a pointer to the USBMSC_Rwbuf_Info structure instance maintained within the API. See Sec. 8.3.6 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for information on using this structure. This function should be called prior to USB enumeration; that is, prior to calling USB_connect().

Returns
A pointer to an application-allocated instance of USBMSC_RWBuf_Info, which will be used to exchange information related to buffer requests from the API to the application.

Copyright 2015, Texas Instruments Incorporated