Reset RX and TX Buffers in USB_BULK

Serial is not USB.  You have to set up baud rates, ports and protocols on both the host and the client, USB you plug and go.

Actually USB is a serial data stream - don't get your point here. I didn't infer for you to use a serial virtual CDM driver or UARTprintf().

Check again the call is USBprintf() which sends TM4C TX data direct to the modified windows client bulk USB example. Take what you can from the posted code snippets to make your custom program work.

The USB host side bulk example FIFO are flushed with following code:        

USBBufferFlush(&g_sTxBuffer);           

USBBufferFlush(&g_sRxBuffer);

Adding V to 4000 in the RXBuffer as you know requires to modifying the Rx callback character loop counter found in (EchoNewDataToHost). One problem you might be having is the RX call back directly writes RX characters into TX buffer prior to sending any data back to the device channel. USBprintf() writes data direct into the channel via (USBbufferWrite()) immediately sending the data on the USB channel to the connected end point. The double 4k4k is the Echo subroutine is not flushing the RX buffer after each TX buffer cycle, easily fixed adding above flush to the Echo routine.

>The USBBufferFlush(&g_sTxBuffer); 

I was referring to flush the RXBuffer after each TXBuffer write so the RX data of the last cycle is not appended to the TX data of the present cycle. The unmodified TM4C bulk USB code was looping the terminals Echo output at high speed likely since it had a CR terminated at the end of the string. 

The VS C++ bulk client example can be imported and easily modified into an RX dumb terminal and launched with the (-e) switch it will report the TP speed. When bulk client is configured in TX mode only the TM4c code side USB_bulk_buffer_size has to be increased to 2048 bytes testing the buffer has some space remaining prior to each USBbuffferWrite() cycle. USB serial TX is that fast, it will quickly fill the 2048 buffer.

http://software-dl.ti.com/tiva-c/SW-TM4C/latest/index_FDS.html

    //
    // How much space is there in the transmit buffer?
    //
     ui32Space = USBBufferSpaceAvailable(&g_sTxBuffer);

    //
    // If the USB buffer space will not hold the
    // string try again later when it will.
    //
    if(ui32Space < 256)
    {
      /* Flush the TX buffer of any overflow data */
        USBBufferFlush(&g_sTxBuffer);
    	return;
    }

Hi Don,

The link in last post leads to DL Windows bulk USB client MSVS Visual Studio project. You mentioned writing a custom C# client - sounds interesting assume it uses .NET2.0 to help implement USB client access to the ACP compliant device driver layer? Good to know the TI end point USB device driver is not explicitly required. That USB bulk TI device driver sometimes disconnects the host from client console for no apparent reason.

That said we currently can not use the TI bulk USB client with the (-e) switch enabled to send data back to the host LP as there is no split display or command entry window. Would have been helpful a more advanced TI programmer build that bulk USB multitasking console. Also the USB code (LP side) we now use to peak into the FIFO for a CR terminator is not yet written as it exists only for UARTs. That polling (peak) function scans the client command line entry received from the character string sent back to the host LP upon a user CR key stroke.

This case bulk USB device LP side the RX event flag function call would make a great place to (peak) for that CR. Course the client part has to have a command line added. I haven't had time to see if the C+ CMD console being used can be invoked in split screen mode to add that ability. Something in gut tells me not possible, a bulk client rewrite using IE hooks is necessary to achieve that.