Bulk USB windows client RXD data only when user must first type characters?

Hi Amit,

The word bulk implies at minimum the 256 byte TXD buffer extent can be filled with a Block and sent to the client. Not the client send data to the target character at a time or have to cut and paste text into a windows client. This Bulk USB example uses an elusive call back derived from the lower layers necessary to access the USB device just to send TX data back to the Windows client. The (pvcBData) USB instance name is passed up through the layers from the client connection. It seems impossible to fill that USB device name for originating data from the Target without first RX data from the Windows client. The Bulk example seems useless for that point alone. There is no indication as to how the USB instance name can be asserted when originating TX data from the target. That instance name passes in function calls in lower down layers though a callback (pvcBData) and bulk transfer then Echos the psDevice instance name back to the USB peripheral to access the Windows client.

How can we get the host USB instance name to pass into the psDevice for TX data without first RX data?

Again the biggest hinge pin is the EK-TM4C1294XL gives a false view of a serial CDM virtual Com port that is not so easily configured or even possible without adding the ICDI MPU into the custom PCB. Possibly not a good scenario that will lead to more fallout than success rate in end product to market.  IOT is dependent on http user feed back that is not ported out the EMAC into a web browser and was configured to use UART0 and a virtual CDM driver that requires the ICDI be present for an costly user interface.

The only obvious way we can invoke the USB instance name passed in the RX connection from the client?

        //
        // A new packet has been received.
        //
        case USB_EVENT_RX_AVAILABLE:
        {

            //
            // Get a pointer to our instance data from the callback data
            // parameter.
            //
            psDevice = (tUSBDBulkDevice *)pvCBData;

            //
            // Read the new packet and echo it back to the host.
            //
            return(EchoNewDataToHost(psDevice, pvMsgData, ui32MsgValue));
        }

One notes that your lovely violet text has (rarely) appeared here.     (perhaps w/good reason...)

 Monsieur Brett (aka BP101),

 Amit raised a key point - it's unclear if you've recognized:

Amit Ashara said:

...example code...actually working as a loopback. Did you attempt breaking this software loopback? 

Devilish attention to detail is required for you to slay (or wound) this dragon...

Recall that "principal" is your PAL - one, "agrees in principle!"

Actually the title of the SW client if taken as true implies a bidirectional data transfer in Bulk form via the USB port.

Why do we have to waste time installing all the SW then find the title given the client is no where close to what it even is or does.

We call that fudging the truth or Fluffing and this not so Bulk client appears to be full of that.

The client exhibits the ability to translate lower case keyboard entries and echo them back in upper case.

A better name would be USB keyboard echo client then we wouldn't feel cheated by the example.

Hi,

the bulk example isn't perfect, but it is great to teach people basic fundamentals if you look around you can find that this example is linked with a basic exercise about USB so don't expect to transfer at fast rate from the start. At the beginning of the summer, I didn't know anything about USB but with this example, I was able to make a USB bulk transfer rate of 5.3 mb/s by working it around.

You need to re-write the window side application to let the MCU transfer to the PC host.

Hi Mathew,

Somewhere recall reading USB version 2 serial data rate was only 200 kilobits at best 250kbps.

How did you managed to get 3.5 megabit/second and if so was it with the bulk Windows client having no modifications? 

BP101 said:

The USB has SW protocol flow control handshake making it a more robust and reliable interface for data exchange

If it proves "more robust" (I'm not so sure) it is not for the UART's lack of "SW protocol flow control."    Have you forgotten the long used "Xon/Xoff" - which for decades has managed UART (& other) SW data flows - enabling the slower device to cry, "Uncle!"   (and then continue - when processing completes)

Matthieu stated his data rate was 5.3 mb/s - not the lesser 3.5 you claim...

cb1- said:

The USB has SW protocol flow control handshake making it a more robust and reliable interface for data exchange

If it proves "more robust" (I'm not so sure) it is not for the UART's lack of "SW protocol flow control."

Indeed

cb1- said:

Have you forgotten the long used "Xon/Xoff" - which for decades has managed UART (& other) SW data flows - enabling the slower device to cry, "Uncle!"

Venerable but not particularly robust. Far better were the various packet based methods with ack/nak or even better sliding window acknowledgements. These are not particularly difficult to implement.

And TCP among it's features has software rate control.

BP101, keep in mind that the purpose of such demonstration programs is to illustrate how the HW/SW work not to provide a high performance implementation for you to use. Your other option is to but high performance implementations from someone.

Robert

BP101 said:

paying attention to the simple question being asked

Was a question (really) asked?    Diagram your post's subject/title - appending "?" to an otherwise declarative sentence - is not standard practice!

We recognize your frustration - yet none here have caused nor aided/abetted - and we (now) come under attack!   (note even Matthieu had his 5.3 mb/s "demoted" to 3.5!)   (dyslexia & frustration may not a "good" mix - make...)

While you've got Matthieu & Amit's attention - your full mobilization to implement Matthieu's "verified answer" may make great sense...   (although "verified" - one suspects this subject far from complete - and satisfied...)

BP101 said:

The award goes to Mathieu L. - the Question has been answered!

Just to note that Amit provided the same answer in his first response, admittedly not quite as step by step.

BP101 said:

The X-on/off protocol is not supported by the ICDI, nor UARTprintf() as it has been written.

That's a bit of a non-sequiter (and I don't think anyone suggested they did). Also you would not use a printf variant for anything approaching high performance.

Robert

To b Echo mode or not to be echo mode would have been a far better answer:

    //
    // Are we operating in echo mode or not? The "-e" parameter tells the
    // app to echo everything it receives back to the device unchanged.
    //
    bEcho = ((argc > 1) && (argv[1][1] == 'e')) ? TRUE : FALSE;

    //
    // Print a cheerful welcome.
    //
    printf("\nBulk USB Device Example\n");
    printf(  "-----------------------\n\n");
    printf("Version %s\n\n", BLDVER);
    if(!bEcho)
    {
        printf("This is a partner application to the usb_dev_bulk example\n");
        printf("shipped with TivaWare software releases for USB-enabled\n");
        printf("boards. Strings entered here are sent to the board which\n");
        printf("inverts the case of the characters in the string and returns\n");
        printf("them to the host.\n\n");
    }
    else
    {
        printf("If run with the \"-e\" command line switch, this application\n");
        printf("echoes all data received on the bulk IN endpoint to the bulk\n");
        printf("OUT endpoint.  This feature may be helpful during development\n");
        printf("and debug of your own USB devices.  Note that this will not\n");
        printf("do anything exciting if run with the usb_dev_bulk example\n");
        printf("device attached since it expects the host to initiate transfers.\n\n");
    }

Hi Amit,

Seems the header file (#include "lmusbdll.h") is present in name only inside the VS project Bulk client import. However the library file exists (lmusbdll.lib) in the example download. Don't believe anyone should have to rebuild lmusbdll.dll since the library is present but to create the bulk client executable the header is required.

Can you please post the (lmusbdll.h) header file?

// One downside to using WinUSB is that it requires you to have the Windows
// Device Driver Kit (DDK) installed to build applications which use the
// interface. This is a very large download making it awkward for people
// with slow internet connections. The use of lmusbdll(64).dll also offers
// the advantage that applications using it can still be modified and
// rebuilt even without the DDK installed on the development system.  To
// update and rebuild lmusbdll itself, however, the DDK is still required.

Thanks Amit, Do see it there - had expected it to be in the downloaded client project files.

BTW the -e switch shows only the USB speed and packet count yet the Windows client code seems to be written polling in a RD/WR buffer format.

Hi Mathieu,

Case you want to try USBprintf() with the Bulk USB client the code to do so is posted below. Simply cut and paste UARTprintf() into Bulk_Dev client and modify a few lines with USBbufferWrite() and your in business. Thanks again for the tip and VS2k5 could import client once edit version 9 to 8 in the VSCproject file. May need to later add buffer status flag returned in USBBufferWrite() that checks the RingBuffer char remaining.

With the UpdateThrougput() enabled it prints out text at an average of 4kbps to the bulk client. Don't forget to add the (-e) echo switch to the Windows shortcut! :)

            //
            // Yes - we are in echo mode (-e) switch was detected.
            //
            printf("Running in echo mode. Press Ctrl+C to exit.\n\n");

            while(1)
            {
                //
                // Read a block of data from the device.
                //
                dwError = ReadUSBPacket(hUSB, szBuffer, ECHO_PACKET_SIZE, &ulRead,
                                  INFINITE, NULL); 

                //
                // Add a string terminator to the returned data (this
                // should already be there but, just in case...)
                //
                szBuffer[ulRead] = '\0';

                
                 /*Print the buffer contents to the console */
                   printf("%s", szBuffer);