MSP430USBDevelopersPackage_5_20_06_02
|
Functions | |
uint8_t | USBMSC_pollCommand (void) |
int16_t | MSCToHostFromBuffer () |
int16_t | MSCFromHostToBuffer () |
uint8_t | USBMSC_processBuffer (void) |
uint8_t | USBMSC_getState () |
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) |
uint8_t | Scsi_Cmd_Parser (uint8_t opcode) |
uint8_t | Scsi_Send_CSW (uint8_t intfNum) |
void | Msc_ResetStateMachine (void) |
void | Msc_ResetFlags (void) |
void | Msc_ResetStruct (void) |
void | SET_RequestsenseNotReady (void) |
void | SET_RequestsenseMediaNotPresent (void) |
void | MscResetCtrlLun (void) |
USBMSC_RWbuf_Info * | USBMSC_fetchInformationStructure (void) |
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().
uint8_t USBMSC_pollCommand | ( | void | ) |
Checks to See if a SCSI Command has Been Received.
Checks to see if a SCSI command has been received. If so, it handles it. If not, it returns having taken no action. The return values of this function are intended to be used with entry of low-power modes. If the function returns USBMSC_OK_TO_SLEEP, then no further application action is required; that is, either no SCSI command was received; one was received but immediately handled; or one was received but the handling will be completed in the background by the API as it automatically services USB interrupts. If instead the function returns USBMSC_PROCESS_BUFFER, then the API is currently servicing a SCSI READ or WRITE command, and the API requires the application to process a buffer. (See Sec. 8.3.6 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for a discussion of buffer processing.) Note that even if the function returns these values, the values could potentially be outdated by the time the application evaluates them. For this reason, it's important to disable interrupts prior to calling this function. See Sec. 8.3.5 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for more information.
uint8_t USBMSC_processBuffer | ( | void | ) |
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_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.
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.
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_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.
uint8_t USBMSC_updateMediaInformation | ( | uint8_t | 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.