• Locked Locked
  • Replies 16 replies
  • Subscribers 34 subscribers
  • Views 2267 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.

Improved documentation for TivaWare USB Library

Brian Willoughby
Genius 4630 points

I'd like to start a discussion on how and where the TivaWare USB Library documentation and examples could be improved.

So far, I'm finding that quite a bit is already there. It's impressive that USB Audio Device Hosting is present in the examples, because Isochronous USB is challenging even on established platforms like Windows. That said, here are a couple of suggestions:

1) The API documentation in the TivaWare USB LIbrary document could go into a little more detail about each function. Even when read by a developer with extensive USB implementation experience, these API leave some questions open about implementation details.

2) It seems that a few more examples might be useful, particularly for high-performance USB bandwidth.

3) Some other participants on this forum have requested a Tutorial for USB developers with moderate development experience. This could be a challenge, since USB is such a broad topic. However, pointers to official USB documentation for basic study, as well as a well-organized document that fills in gaps specific to the TM4C could go a long way in terms of tutorial material.

If others would like to add to the list, or refine the suggestions, then perhaps we could help Texas Instruments improve the documentation.

Brian Willoughby, Sound Consulting

  • TI__Guru**** 244400 points
    Hello Brian,

    What type of examples would you like to see for high-performance USB? 129 has the USB High Speed so making an example would require us to make a new dev/eval board and so this needs to be discussed. So a forum input would be very good (in the past we have done that for memory boards for the TM4C129, the documentation is ongoing for the web). Without a good set of examples it would be very generic!!!

    I would go back to the TMS documentation to see how we can enhance the experience.

    Regards
    Amit
  • in reply to Amit Ashara
    Genius 4630 points
    I'm just getting started with the TM4C, so some of my comments may be premature. That said, I'd like to see a USB Audio Host example that supports more than 16-bit stereo at Full Speed. Perhaps 6-channel audio at 24-bit would be a good example of the maximum that USB Audio can handle at Full Speed. As for the dev/eval board, perhaps Optical Digital Audio would be a good way to get that many channels in or out without actually putting 6 to 8 channels of conversion (ADC, DAC). Look at the XMOS USB Multi-Channel Audio U16 and USB DJ Audio Platforms for examples of what your competitors are doing. This might be a good opportunity for Texas Instruments to show off their quality audio converter chips interfacing to the TM4C via I8S serial digital audio streaming protocols.

    As for USB High Speed, that would be another good example, but I am currently focused on maximizing bandwidth using USB Full Speed, due to the lower cost of Device and Host chips that can handle Full Speed. I selected the TM4C1293 because it can handle Full Speed, and I merely want to hit about 750 KB/sec bandwidth. As I understand it, if you were to come up with a USB High Speed dev/eval board, then it would require an external ULPI USB PHY chip, and that would be a great platform for folks who are interested. I simply cannot predict whether more customers would be interested in Full Speed or High Speed.
  • in reply to Brian Willoughby
    TI__Guru**** 244400 points
    Hello Brian

    More than HS and FS, it is about documentation, software-usage-feature and application. Going the application route helps us improve software and documentation. Audio is a good thought and let's see how many more see the thread to contribute to.

    Regards
    Amit
  • Intellectual 765 points
    There are significant differences between the API described in the TIVAWARE USB Library User Guide (SW-TM4C-USBL-UG-2.1.1.71) and the actual software supplied with TI-RTOS version 2.12.01.33 (TIVAWARE_C_SERIES version 2.1.0.12573c). For example, Section 4.2 describes returned mode values like USB_MODE_IDLE; the actual enumerations defined in usblib.h for the tUSBMode are like "eUSBModeNone". It is almost like the user guide was written for a different version. Is there a later version of the user manual? Is there a version of the TIVAWARE that matches the manual?
  • in reply to Tom Farmer
    TI__Guru**** 244400 points
    Hello Tom

    I agree with your observations, the software went ahead and changed but the document has clearly lagged behind on updates. However making the changes to the document is going to be a slow process as we need to ensure that both updates and fixes go along with USB application example to be more feature centric of API's that can help build better applications.

    Regards
    Amit
  • in reply to Amit Ashara
    Guru 20670 points
    Hi Amit,

    Maybe I say that while I see your point, there should be at least clear and easy to find the error that the user reported... or people will keep falling for it until the update is done.
  • in reply to Amit Ashara
    Guru 47900 points

    I've punched "Like" for both Brian & Tom. Both presented well thought & argued "push" for their interests.

    That said - ARM MCUs enjoy wide appeal - across many, many vendors.  Have (Brian/Tom) fully or significantly investigated - to see if better pathways may exist?  In addition - would not "USB Specialty" chip developers (a la FTDI) prove, "likely suspect?"   (and provide some inroads?)

    My sense - "broad-based MCU-centric" vendors (i.e. here) may not "dive as deeply" as you desire.   Identifying those who do (if any) may prove more fruitful...

  • in reply to cb1
    Genius 4630 points

    FTDI Chip solutions are very limited in scope, designed primarily for existing legacy designs. They are not appropriate for new designs, and I would recommend against using them. If you have an aging serial product that is based on RS-232 or similar serial links, then FTDI probably has a solution that can patch up your old design to get you started in the USB world. But if you're designing a modern product that needs to implement any USB Class besides CDC, such as Audio, then there are many better choices than FTDI.

    I have designed multiple, commercial USB devices for clients based on PIC and TMS320 processors. I have also worked with other chips like freescale. The TM4C is a very good choice when considering all aspects from electrical specifications to firmware support and flexibility of customization.

  • in reply to Brian Willoughby
    Guru 47900 points
    And - beyond Freescale - have you looked at other ARM MCUs? (especially M7 and the market leaders...)

    I am in much disagreement w/your characterization of FTDI... Does your (bit harsh) judgment reflect a recent visit to their site - survey of multiple, newer developments?
  • in reply to cb1
    Genius 4630 points
    I don't want to spend a lot of time talking about non-TI solutions on a TI forum.

    However, none of the FTDI Chip solutions are programmable, as far as I can tell. They offer conversion between USB and various other protocols, including basic FIFO storage, but there is no capability for any USB functions besides the primary protocol conversion. That rules out all of the designs I've done so far as not compatible with FTDI.

    Strange that you mention the M7, because it's at the opposite end of the spectrum from FTDI. The M7 is certainly programmable, and therefore flexible enough, but it's more than I need for my current application. Between the FTDI at the low end (non-programmable) and the M7 at the high end (of embedded - not counting A7 or other ARM Cortex-A solutions), there is a very wide spectrum of solutions available from multiple vendors. There's no reason to limit the choices to just the extremes.

    I'm finding the development process with the TM4C to be superior to everything else so far. At some point, evaluation of more options has to stop and implementation has to start. I've reached the point where I am implementing a solution with the TM4C1294, and I doubt I will change at this point. Meanwhile, other client projects have me researching ST Micro options, but so far they are not superior to Texas Instruments.
  • in reply to Brian Willoughby
    Guru 47900 points

    So long as you've made a "reasonable" investigation of the broader product market... (too often - single-source forever proves short-sighted)

    Iirc - several clients have combined FTDI w/MCUs here - and realized success.   (that "whole" exceeded the "sum of the individual parts.")  We note further that FTDI's "USB to UART" chip was most helpful to the "acquired vendor's" Cortex M3 - which while departed - led directly to the creation of this forum.   And they assuredly have "programmable" devices.  (VNC2 - 256KB Flash & 4 channel DMA controller - for one)
     
    I "jumped in" as you "called for assistance" - had not mentioned the fullness of your investigation - vendor here advised that their "focused assistance" was not imminent - and hoped that others would add their findings...

  • in reply to cb1
    Genius 4630 points

    Thank you for the additional input.

    I realize that you can combine an MCU with an FTDI Chip, but in my opinion there are so many great MCU options that already have on-board USB peripherals that it's just not worth bothering with a two-chip solution.

    Another thing that I forgot to mention is packaging. Many embedded processors are available only in BGA, but I am happy that the TM4C is available in PQFP. That alone saves me a lot of money on multiple fronts.

  • in reply to Brian Willoughby
    Guru 117855 points

    Good - we now appear more in agreement (not that that's required) - and both viewpoints have been presented.

    Like you - I wish (more) USB detail could be made available - yet vendor here has signaled that as, "downstream."   (perhaps very downstream - after PF0/PD7)

    My small firm finds "accomplishing the mission" (even when two, or God forbid (more) chips) are required "trumps" (single chip's) "missing" capability/functionality.   If one cannot meet clients' specifications w/"single chip" - perhaps it IS worth bothering w/2 (or more) chips which (together) meet multiple clients' need.   That's my (clear) finding...

    Even w/our Pick n Place & 20' multi-stage reflow oven - BGA proves a nightmare.   (Hello X-Ray charges)  Fortunately the (broader) market provides M0, M3, M4 & M7 in soic, p/t qfp in multiple flavors...

  • in reply to cb1
    Intellectual 765 points

    Our 1st generation product went to market with a Stellaris chip in it.  Our application requires both USB OTG (only Full speed) and 10/100 Ethernet along with some significant motor control functionality.  We also used DSP/BIOS and got it to work with the lwip stack.   Using this we achieved a very small package footprint that our customers have designed into their products.  All of this software development was done by a different firmware engineer.

    Now, with EOL on Stellaris, we are attempting to port to TIVA.  Our only hardware problem has been that the TIVA only has one quadrature encoder and we need two; we have a fix for that.  On the software side, the changes are significant and well beyond those described in the Stellaris-to-Tiva change document.  The first was that the API for TI-RTOS is not identical to the DSP/BIOS.  Furthermore our engineer had to modify part of DSP/BIOS so we certainly expected a few challenges with the transition.  But those issues aside, we have been able to handle most of our applications internal functionality using the documentation related to the TI-RTOS kernal and drivers.

    A bigger issue is that the USB stack API has changed significantly.  We had expected to use the USB drivers included with TI-RTOS but, we found out later, OTG is not supported.  So, I set out to port our existing code using the TIVAWARE API.  I have not done much with the OTG overhead stuff yet other than the initialization code.  I was able to set up the device side to the point that it compiles and links.  I am struggling with the host side.  We created a driver for our proprietary external device in Stellarisware.  I am currently trying to port it to TIVAWARE, but the mouse driver in the TIVAWARE version that came with TI-RTOS does not match the description in the manual nor does its calling convention match. So, if I make the revised driver look like the mouse driver in the TIVAWARE source code, it does not match the calling conventions described in the TIVAWARE USB manual.

    I have not even started trying to transition from lwip to NDK.....

    For us the only real advantage of the TM4C1294 over the competition was having both OTG and 10/100 with integrated PHYs.   We do use the FTDI chip in other applications and would have done so here if we could have, but we needed functionality beyond its capabilities. 

    The lack of accurate documentation on the TIVAWARE USB API has been, and continues to be, a real challenge....

  • in reply to Tom Farmer
    Genius 4630 points

    Hi Tom,

    Please start a new topic about your specific troubles. I have a few suggestions, but I don't think it's appropriate to get into details inside this documentation topic. When you have a new topic on the site, I'll see what help I can offer. You may find others who have some help to offer as well.

    Brian

  • in reply to Tom Farmer
    Guru 55913 points
    Hi Tom,

    Did that very conversion long ago and now have LWIP1.4.1 porting local TCP 23 and internet http 80 consecutively. That 2 clients TCP stack is tricky and not without hidden issues. Our testing USB port is serial CDM virtual and sends printf data to a windows console. Migration LM3 to TM4C was daunting and took a few months to complete. A custom PCB is very soon off the press and OTG ports detects the self powered client, likely the Android or more currently windows USB client endpoint.

    Seems silly to me adding mouse/keyboard TM4C when LCD touch screen is the future and getting better by the year. Our custom PCB will take full advantage of high speed USB connected devices, plan to host future endpoints for command control. Have tested BLDC 3 phase motors up to 185v 2.5Kw 18 amps peak using window Ethernet real time GUI to make monitor BLDC performance, make sensorless FOC timing changes, switch to encoder or Halls taco speed monitors. Reinventing the entire wheel sounds rather difficult when we can improve upon existing wheel adding USB support alone seems more fitting our view.

    Send a private message if or any interest in project: http://www.genatco.com