![]() |
![]() |
Contains APIs related to MSC (Mass Storage) SCSI handling.
Functions | |
BYTE | USBMSC_bufferProcessed () |
BYTE | USBMSC_updateMediaInfo (BYTE lun, struct USBMSC_mediaInfoStr *info) |
BYTE | USBMSC_registerBufInfo (BYTE lun, BYTE *RWbuf_x, BYTE *RWbuf_y, WORD size) |
USBMSC_RWbuf_Info * | USBMSC_fetchInfoStruct (VOID) |
BYTE USBMSC_bufferProcessed | ( | ) |
This function should be called by the application after it has processed a buffer request.
USBMSC_Rwbuf_Info*RWBufInfo | Pass the value received from USBMSC_fetchInfoStruct(). |
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.
BYTE USBMSC_updateMediaInfo | ( | BYTE | lun, |
struct USBMSC_mediaInfoStr * | info | ||
) |
Informs the API of the Current State of the Media on LUN lun.
lun | is the logical unit (LUN) on which the operation is taking place. Zero-based. (This version of the API only supports a single LUN.) |
info | is 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.
BYTE USBMSC_registerBufInfo | ( | BYTE | lun, |
BYTE * | RWbuf_x, | ||
BYTE * | RWbuf_y, | ||
WORD | size | ||
) |
Gives the API a Buffer to Use for READ/WRITE Data Transfer.
lun | is the Lun number. |
*RWbuf_x | is the address of an X-buffer. If null, then both buffers are de-activated. |
*RWbuf_y | is the address of an Y-buffer. (Double-buffering is not supported in this version of the API.) |
size | is 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_updateMediaInfo() 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 kUSB_succeed every time. It is up to the application to ensure that the buffers are valid.
USBMSC_RWbuf_Info* USBMSC_fetchInfoStruct | ( | 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().