• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 537 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TM4C1294KCPDT: USB CDC - USBDCDCInit() initialize params.

Jayaraj Balasubramanian
Prodigy 120 points
Part Number: TM4C1294KCPDT


Tool/software: TI-RTOS

Hi All,

TM4C1294KCPDT - Serial - CDC example.

In the USBDCDCInit() API, to initialize the CDC layer the structure parameter that is passed to it is tUSBDCDCDevice,as below :

typedef struct
{
    const uint16_t ui16VID;
    const uint16_t ui16PID;
    const uint16_t ui16MaxPowermA;
    const uint8_t ui8PwrAttributes;
    const tUSBCallback pfnControlCallback;
    void *pvControlCBData;
    const tUSBCallback pfnRxCallback;
    void *pvRxCBData;
    const tUSBCallback pfnTxCallback;
    void *pvTxCBData;
    const uint8_t *const *ppui8StringDescriptors;
    const uint32_t ui32NumStringDescriptors;
    tCDCSerInstance sPrivateData;
}
tUSBDCDCDevice

The 7th and 9th params are function callbacks to be registered to notify on send and receive events.

It is observed in the sample project and also elsewhere that USBBufferEventCallback is registered which is a driver API.

Why is it so?

Isn't it that an application callback should be registered.?

  • 0
    TI__Guru*** 135355 points

    Hello Jayaraj,

    No you wouldn't use an application callback here because you want the USB Buffer to operate below the application, and using the driver callbacks allow for this.

    See this description of the callback functionality:

    //! This function is the USB buffer event handler that applications should
//! register with the USB device class driver as the callback for the channel
//! which is to be buffered using this buffer.
//!
//! \note This function will never be called by an application.  It is the
//! handler that allows the USB buffer to be inserted above the device class
//! driver or host pipe driver and below the application to offer buffering
//! support.

    In summary, using the USB driver's callback allows for USB to run underneath the application so you only need to worry about processing events once they are received from the callback and do not need to manage the buffering of data.

  • 0 in reply to Ralph Jacobi
    Prodigy 120 points

    Hello Ralph,

    Thank you for the information.

    I am trying to create an application that runs on top of USB CDC layer. (i.e. application that uses CDC layer as a channel).

    To accomplish this, I was going through the sample application that uses USB CDC layer, however it is observed that USBBufferRead and USBBufferWrite APIs (driver level APIs) are being used.

    In addition to these APIs, other Driver level APIs are also used (ex USBBufferDataAvailable etc) 

    To my understanding for a USB CDC channel, APIs related to USB CDC layer should be used (ex USBDCDCPacketWrite, USBDCDCPacketRead, USBDCDCRxPacketAvailable etc) and not driver level APIs directly.

    Please correct me if am wrong.

    [Edit]

    To be more precise,

    I want to develop an application that uses USB CDC layer to transport the packets.

    The only point of confusion here is that, the whether to use the CDC layer APIs alone, i.e the one which is exposed in the file - usbdcdc.h

    Or also the APIs exposed in usblib.h (assumed to be driver call) which has APIs like USBBufferSpaceAvailable()

    Please provide clarity on this.

    Thanks,

    Jay

  • 0 in reply to Jayaraj Balasubramanian
    TI__Guru*** 135355 points

    Hello Jay,

    You would use the usblib.h API's such as USBBufferSpaceAvailable. You only need to use the CDC API's for configuration to ensure the USB stack is running in CDC mode.

    The structures defined in usb_serial_structs.c (or it's equivalent) provide the link between CDC specific functions and the general USB library. This allows for the USB library to handle running multiple types of devices with a single layer and buffer.

    Edit: corrected usb_serial_structs.h to usb_serial_structs.c.