• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 624 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.

TM4C123 USB CDC

fjpolo
Prodigy 140 points

Hi guys, a few days ago one of my college professors handled me some code adapted from usb_dev_serial so I could start working with USB communications with my PC. As far as I can tell, code is interruption-oriented and so far I could only receive characters one at a time every time the interrupt is triggered. Since I need to sent date and time to the microcontroller I wouldn´t like to be receving chars one at a time and checking if I stil have anything left to receive. I wanted to end the received string with '\n' in order to get the Rx part finished, but I can´t figure out how to do this.

I´m attaching in a .rar the files and posting here Rx interrupt handler (I´ve just went back to just receving one char). By the way I´m working with a custom board, ArLinkEx as debugger, and CooCox as my IDE.

//*****************************************************************************
//
// Handles CDC driver notifications related to the receive channel (data from
// the USB host).
//
// \param ui32CBData is the client-supplied callback data value for this
// channel.
// \param ui32Event identifies the event we are being notified about.
// \param ui32MsgValue is an event-specific value.
// \param pvMsgData is an event-specific pointer.
//
// This function is called by the CDC driver to notify us of any events
// related to operation of the receive data channel (the OUT channel carrying
// data from the USB host).
//
// \return The return value is event-specific.
//
//*****************************************************************************
uint32_t
RxHandler(void *pvCBData, uint32_t ui32Event, uint32_t ui32MsgValue,
void *pvMsgData)
{
//
// Which event are we being sent?
//
switch(ui32Event)
{
//
// A new packet has been received.
//
case USB_EVENT_RX_AVAILABLE:
{
//
// We do not ever expect to receive serial data, so just flush
// the RX buffer if any data actually comes in.
//
//USBBufferFlush(&g_sRxBuffer);
// Si se desea leer debería utilizarce algo como:
//
//USBBufferRead(&g_sRxBuffer, &data, 1);
// TODO Receive
USBBufferRead(&g_sRxBuffer, &mydata, 1);
//USBBufferFlush(&g_sRxBuffer);
//
//
//
if((usb_flag ==1) && (usb_counter == 5)){
//USBBufferRead(&g_sRxBuffer, &mydata, 1);
USBSerialSend(&mydata, 1);
usb_date[5] = mydata;
usb_date[6] = '\n';
USBSerialSend("\n\r", 2);
//
int k =0;
for(k=0;k<=6;k++){
USBSerialSend(&usb_date[k], 1);
}
USBSerialSend("\n\r", 2);
usb_counter =0;
usb_flag=0;
}
if((usb_flag ==1) &&(usb_counter >=0 | usb_counter <=4)){
//USBBufferRead(&g_sRxBuffer, &mydata, 1);
USBSerialSend(&mydata, 1);
usb_date[usb_counter] = mydata;
usb_counter++;
}
if(mydata=='a'){
USBSerialSend(&mydata, 1);
USBSerialSend("\n\r", 2);
USBSerialSend("Hello world!\n\r", 14);
//usb_counter = 1;
usb_flag=1;
}
else  if((usb_flag==0)&&(mydata != 'a'))USBSerialSend("Wrong option!\n\r", 15);
//USBBufferRead(&g_sRxBuffer, &mydata, 1);
//USBSerialSend("Rx OK\n\r", 7);
// donde data es una variable definida de tipo unsigned char.
break;
}
//
// We are being asked how much unprocessed data we have still to
// process.  Since there is no actual serial port and we are not
// processing any RX data, just return 0.
//
case USB_EVENT_DATA_REMAINING:
{
return(0);
}
//
// We are being asked to provide a buffer into which the next packet
// can be read. We do not support this mode of receiving data so let
// the driver know by returning 0. The CDC driver should not be sending
// this message but this is included just for illustration and
// completeness.
//
case USB_EVENT_REQUEST_BUFFER:
{
return(0);
}
//
// We don't expect to receive any other events.
//
default:
{
break;
}
}
return(0);
}

Test051 - USBv2.rar

  • 0
    TI__Guru**** 196596 points

    Hi Fjpolo,

    The sample code can read as many characters from UART FIFO as we can. I modified the code for your project. What are the changes you made? Can you try the original project from TivaWare first?

    Regards,

    QJ

  • 0 in reply to QJ Wang
    Prodigy 140 points

    Hi QJ,

    thanks for the reply. Were you the developer of usb_dev_serial or did I got it wrong? I already tried that code for my TivaC launchpad. The thing is, that I strugled with it tryng to get rid of the UART part, but I couldn´t get the uSB to work without it, so I must have been doing something wrong. That´s when I got this piece of code I attached earlier. I didn´t make any change here, just LED ports, and some code inside RxHandler in order to get more than one char, but still just one at a time. I could take a look again at usb_dev_serial but it wasn´t clear enough for me what was going on there. I just at the moment need at the moment to get more than one char and save them into a string in the same interrupt handler, particulary 7 chars, when the last one is '\n', for example:

    120816\n being August the 12th 2016, the date

    121845\n being 12:18:45, the time

    Like I said, I don't really know how usb_dev_serial receives, but I wouldn´t mind looking at it again with some help.

    Franco

  • 0 in reply to fjpolo
    TI__Guru**** 244400 points
    Hello Franco

    Please define the intention of sending the date and time. If it is just a loopback operation then I would suggest using usb_dev_bulk example

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 140 points

    Hi Amit,

    thanks for the reply. It´s not intended to be a loopback operation. After I get the USB connected, microcontroller is supposed to wait for a menu command:

    1- Set date

    2- Set time

    3- Set period

    4- Start logging

    5- Stop logging

    After getting a command and if it´s correct it sends an ACK to the PC. For commands 1 to 3 it waits to receive data(6 char + '\n') and if its correct, sends a new ACK. After that it goes back to waiting a command again. For command 4, starts sending sensor data until it gets 5 as a command.

    I could implement it using flags and counters, but I was trying to reach an easier way to read a string coming from the PC. I mean, There must be a way of reading the buffer after the first time I get the interrupt without having to wait for an interrupt for every char I get and read it individually.

    Franco

  • 0 in reply to fjpolo
    TI__Guru**** 244400 points
    Hello Franco

    I would suggest checking the qs_logger example in DK-TM4C123G as a good starting point.

    Regards
    Amit