• State Answer Suggested
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 797 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.

Testing the bulk USB example - Is there a USBprintf() command in Tivaware library?

Genatco
Guru 55913 points

Have the USB bulk driver working with an existing application and like to decommission UART0 currently piping messages out a serial CDM virtual COM port to a terminal emulator running on Windows desktop.

Oddly the USB bulk driver example RX FIFO was getting flooded during the host TX data echo cycle (mangled echo return) and the UARTprintf() RX/TX counts were accelerating so fast it quickly flooded the COM port emulator @115200kb. The fix is posted below for anyone experiencing the same issues.

UARTprintf() handles messages strings versus integer data differently and has many switches %d,i,s,n etc...

USB printf() handles only asscii characters in the Bulk example.

Otherwise Is there a Tivaware library command that can internally redirect all UART0 TX/RX data into USB0 TX/RX?

Thanks for ideas!

 

    /* Flush the RX buffer of any stray data */
    USBBufferFlush(&g_sRxBuffer);

    //
    // We've processed the data in place so now send the processed data
    // back to the host.
    //
    USBBufferDataWritten(&g_sTxBuffer, ui32Count); 
  • 0
    Guru 55913 points

    Obviously the answer to this question is NO?

    The point behind this question is that slower UART speeds are now Legacy data transfer speeds. UART technology need to be considered as a decommissioned device at some point in the Tivaware library.

    Might the USB Bulk host device example could have considered the necessity for writing a UART to USB FIFO redirect filter rather than make the programmer search for every last UARTprintf() in the application or examples?

    The ICDI code does exactly that function indirectly piping Target UART0 data into ICDI USB0 out to serial CDM virtual COM port driver. Obviously we cant merely hard wire the TX/RX of UART0 into USB0 RX/TX and maintain the CDM device driver into Windows? 

    The code for ICDI is not disclosed, how we might achieve that same data exchange at the internal peripheral HW level is a mystery. We note the OTG mode USB serial virtual CDM driver Example is many more times the lines of code (functions) of the simple Bulk device example.

  • 0
    TI__Guru**** 244400 points
    Hello BP101

    As you answered the question, no we do not have TivaWare library command that can internally direct UART to USB. It must be done by the application (consider the need for string processing).

    Decommission UART: No..

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Decommission UART...HELL NO! Not every application is MCU to PC!

    MCU to MCU - or to a cluster or even "swarm" (credit MIT) of MCUs may well employ UART (via RS485) or CAN or SPI.

    UART is far from dead/buried - BP101's black (UART) hearse arrives (we think) most prematurely...

  • 0 in reply to cb1
    Guru 55913 points
    That's odd don't see a UART connection on any PDA/PAD in production and yet micro USB is the new champion. Others dragging the team of slower horses might never visit Mars on those slow serial transfers left over from the 1980's.

    Pluto makes work week history a planet once again, who knows and was it a UART or USB interconnect that saved the day during that MPU reboot fail safe?

    That's ok we have masterminds working on a solution, USBprintf() is on the burner as we post. That sounds strange!
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,
    Seeing the target UART port data into the virtual CDM serial built into ICDI and out that USB port seems an good method at first. In reality that is highly complex and likely not the solution most will end up with on their custom PCB. One the cost is high to add the ICDI MPU and secondly TI is not disclosing the source code it is flashed with.

    Those alone are good enough reasons to decommission the outdated UART and replace the peripheral with an integrated graphics engine LCD peripheral module and cosponsor a 4 wire I2C direct drive LCD to match it. Time to make the donuts again!
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    The earlier option was to have FTDI chip which would have increased the cost as the 3rd party devices cost are passed on to end customer as is. No rebate and full margin... Source code for a lot of IPs (SW and HW) are maintained by the Silicon Vendor (and TI is not an exception)

    It all comes down to the cost of a LaunchPad. Other way around is that one can go for a DK-TM4C12x.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,
    We take a different view that invention is supposed to be about the end product. The LP is neat but designer discovers on the fly far to many PCB traces to make it even fit in that very small foot print. How can innovation succeed unless the Si engineers develop better interface solutions for the very small PCB footprint and not merely miniaturize components until the human eye can no longer see them.

    Microsoft created PNP and the world exploded now we await the next best IEEE answers to take LCD into PNP possibly a HID platform beyond the here and now of cell phone LCD displays. Mission to Mars roll up portable LED maps will require thinking outside the Cube!
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    While our views our specific to how we see the end system, when doing for the masses it is required to sometimes be "non-optimal" and be able to supplement by SW, Forum and share-code projects.

    Regards
    Amit