• State
  • Locked Locked
  • Replies 26 replies
  • Subscribers 33 subscribers
  • Views 2458 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.

Some thoughts on TI's USB library examples

Gergo Santha
Genius 3585 points

Hi!

Some months ago I was trying to develop a custom USB HID application on my Tiva launchpads. After countless hours of fiddling with existing examples, googling etc. I just abandoned the project, feeling a bit disappointed. Few weeks ago I've been asked again to develop this feature and before jumping in into this I'd like to ask if TI intends to provide any useful examples in the future?
At the moment there are only mouse, keyboard and gamepad examples. In my opinion these are pretty useless. I think that no one designs mouses, keyboards or gamepads, the market is already crowded with zillions of such devices. What would be interesting is a custom HID to replace the common VCP approach which is good enough as a diagnostic tool but not sufficient in a real product. 
I was always pleased and satisfied with the great support from TI and I simply can't understand that there are only useless examples in the USB HID topic. 

  • 0
    Guru 117855 points

    We, "Like" your writing - nicely backgrounded yet to the point.

    May I note that such semi-firms all seek to, "Outperform their market."    That's a major metric - most always influences, "raises, bonuses & budgets."

    So - BFD.     Yet - if you can compare/contrast the "success" of (similar) others - might that, "outperformance by others" serve as a strong motivator - here?

    Your case & desire may "earn" better (i.e. some) response - especially if you can present evidence that (others) have, "outperformed" - in your area of interest...

  • 0 in reply to cb1_mobile
    Genius 3585 points
    Hi cb1_mobile,

    since English is not my native language it is very likely that I'd misunderstand your first 3 sentences so please forgive me if I'll not address them. If I get your last one correctly, my asnwer is: there is a good example for HID datapipes on MSP430, proving that TI had the intention to provide some 'realistic' examples at least once. I know that I should transfer the MSP430 code to Tiva - it seems very likely that I'll do that - but before that I'd ask TI.
  • 0 in reply to Gergo Santha
    Guru 117855 points
    Oh well - hard for me to recall (everyone's) background - and I write fast/furiously (here) when blocked @ "paid job."
    While migrating code from MSP is an alternative - have you checked (other) ARM vendors' skill & offering in your desired USB area?" If (others) have "out-performed" (i.e. produced more capable & usable & applauded) USB code examples - mention of that would greatly motivate crack staff - here!
  • 0
    Guru 55913 points
    Hi Greg,
    The bulk USB client example and USB serial CDL examples found in Tivaware require the user to install the Windows device driver for them to work properly. Windows drivers are found in folder C:\TivaWare_C_Series-2.1.0.12573\windows_drivers. Believe the USB serial CDL example loops alphabet characters into a virtual COM port of windows attached console such as Putty or YAT. The USB Bulk example is short sassy providing a direct USB pipe into Windows and said to include the MS-Visual Studio 8 source code for the client

    The Bulk USB client example can be downloaded here:
    software-dl.ti.com/.../index_FDS.html
  • 0
    TI__Guru**** 244400 points
    Hello Greg, cb1, BP101,

    My 2 cents as TI:

    cb1's running post e2e.ti.com/.../423619 on "Tell TI" is a good place to start. It could be from the documentation of the API's to the actual example we may have to span.

    In the past (unrelated to this thread) I have asked the forum for what "functional USB examples" need to seen in the TivaWare, for which the answer turned to be"NULL". As USB has more applications than just "mouse, keyboard, gamepads", in HID market space, then what next? Also an important thing to note is that when doing such examples, the next items that pops on the forum is I want this USB example (well we can cannot possibly give 2^N examples of combinations and no vendor may directly).

    So back to the basic question and to keep it on a practical note: what kind of HID examples do we work on since not everyone may use TM4C for HID!!!

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

    Hi Amit, 

    Simply inspired writing!    (as noted by, "crack (yet to escape) for holiday - staff" - and this deskbound reporter - unqualified for holiday due to workload)  

    Pity that past, "NULL" resulted - and that's (nearly) the case "enjoyed" by, "Tell TI."     And - as you note - "disappointed" poster failed to note that, "more centralized point" (i.e. "Tell TI") to "dock" his "disappointment & (unspecified) request."    

    May I note - in the most "plain & simple" language - that originating poster here seeks, "Useful" examples - yet completely fails to define or bound, "useful!"   

    Might such "defining & bounding" themselves prove, "useful?"    (as you - more gently - note...we thus witness Poster, "Hoist by his own petard" - was he not?)

  • 0 in reply to cb1_mobile
    TI__Guru**** 244400 points
    Hello cb1

    Absolutely agree with you on the last point. A problem well bound can have a solution well defined.

    Regards
    Amit
  • 0 in reply to Genatco
    Genius 3585 points

    Hello BP101,

    I'd like to implement a customized USB HID interface which is different from CDC or Bulk mode.

  • 0 in reply to Amit Ashara
    Genius 3585 points
    Hi Amit,

    thank you for your offer! I did not noticed your question in the past, I was not reading the forum for some time because I was up to my ears. Anyway, it would do no harm if that post was stickied to the top of the forum.
    I agree that the word 'useful' was pretty undefined but in the context I'd been writing it was clear. Mice and keyboards are good examples for HID, however, they are special (they've got their own classes, report forms etc.) so they are not so good to learn how to implement a simple data exchange USB HID. They are also 'just' examples, as there will be no one who prepares to design the n+1 mouse or keyboard. However, I'm sure that there are loads of people who would happily get rid of the serial port approach and would use a clean, plug'n'play custom HID:

    - custom USB HID with an interrupt IN endpoint sending 1...64 bytes of raw data to the host if requested
    - endpoint 0 OUT to send commands, parameters etc. to the device from the host
    - optional: interupt OUT endpoint implementation (host -> device)
    - some host (PC) side implementation examples in whatever language
  • 0 in reply to Gergo Santha
    Guru 117855 points

    Good to see poster, "Flesh out" his past request - that's sure to help.

    May I attempt to further refine - with less "USB technical" but more, "Real World" Tiva-USB objectives?

    a) LPad acquires multiple channels (say 8) of ADC data - and (again 8) of GPIO_Input - and 8 GPIO_Output.      And is controlled & interrogated by the host PC - which may perform further processing but (always) will "log" this data.     Goal is the highest, error/PC crash-free transfer rate.

    b) In essence - most here seek to simply, "Remove the mystery & heartache" which is imposed (most always) by the complexity of USB.    Don't we (all) seek the simplicity of the (long gone) Serial (RS232) ports of the past?      Starting with (a) above and enabling (b) here - to my mind - provides a useful roadmap.

    Perhaps this is best stated as, "Enable most (all) of the LPads functionality to be quickly & robustly exchanged with a host PC."     

    I'd avoid having the host PC "set-up/config" and or program the LPad - that's adding undue complexity.    The ability to have the LPad do, "that which it does best" and to add the ability to regularly/quickly/robustly "exchange" with a host PC - for further processing and especially for data logging - seems the "real" (now clear & useful) objective.

  • 0 in reply to Gergo Santha
    TI__Guru**** 244400 points
    Hello Greg,

    It seems that your choice is in INTERRUPT EndPoint rather than BULK. Note that the throughput would be lesser on INTERRUPT End Point. I have seen more dependence in BULK to squeeze as much bits-per-sec on customer application. Nevertheless it is a good suggestion. I would however be a little pessimistic on the requirement and rather try to see how to make a more generic solution.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    May some here note that such detail may mask, "Forest thru the trees?"

    Was not a clear, crisp "description of need" submitted?
  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1,

    The description is clear, but only for the requirement. Can we afford to just add one example to do so or rather take a step back (at expense of time) and do a better job to support USB is the question I ask myself (and to the forum)

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

    1600+ "hits" - yet only 4-5 responders - reveals forum contributions like, "Pulling teeth."     (such true @ "Tell T.I. top of forum)

    Past suggestion - "Enable 8 TM4C ADC channel reads - 8 GPIO Outputs - and 8 GPIO inputs - at highest (& robust) rate possible - via USB exchange w/host PC" seems a, "near universal, USB goal."     Again - that was quickly/easily doable via past serial COM Port - not so much under USB...    

    Unclear why "variation" from that (past, standard) "formula for success" seems necessary...

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1

    IMHO, It is the variations of the same that is going to be affecting the "near universal, USB goal", the famed "give me a code" included.

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

    May I suggest that, "undue focus upon (possible) variations" may be misplaced.     Are not 24 channels (or near that) - of efficient data exchange - between the TM4C and host PC - sufficient for 90%+ use cases?   (my group believes, "Yes")

    Indeed even famed, "gimme a code" seems well covered w/the "near universal, USB goal" which stems directly from past, serial COM Port standard...

    It's clear that, "what exists now" proves insufficient.    Suggestion advanced should effectively correct - and provides a neat "bridge" to off-shoots - which should not delay the now, "clear, universal USB goal."

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1,

    Sufficient but may not be satisfactory. Yet an attempt can be done on the targetted code.

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

    What exists now is, "Proven" to be unsatisfactory!     My suggestion seems most reasonable/quickest to correct - such "baby steps" (i.e. KISS) have long been proven to lead to success...

  • 0 in reply to Gergo Santha
    Guru 55913 points

    Perhaps if you tried the bulk driver it might surprise at the serial transfer speed it achieves with very little code overhead as HID device requires. Hearing the words raw data are I/O (binary) and that is exactly what bulk client will do without bulk amounts of code at either end.

    Imported the client part into Visual Studio today, seems it would not require much to add fancy .net windows to build upon the existing cmd script dialog box. That is often the foundation for adding upper tiers in a custom user interface. My opinion is HID drivers remain mostly transparent to the user existing at the ACPI compliant (hardware abstraction layer) HAL in Windows filtering data up to the application layer. Beyond that often tend to lean on the less difficult method for wired devices PDA, smart phone etc.. We have ARM 4-7 processor support built into Visual Studio 8 for building core windows functions via .net 2.0 frame work or for manipulating a few existing shell projects.

  • 0 in reply to Genatco
    Guru 47900 points

    BP101 said:
    Perhaps if you tired the bulk driver it might surprise

    Should we here, "tire the bulk driver" - indeed that would surprise.

    Earlier - poster & Amit agreed that more detailed Tiva USB code examples were needed.      That's at the MCU side - your writing steers toward PC side - that was not this thread's focus.     In your defense - this thread has bobbed/weaved - enough to confuse...

    Are you saying that Visual Studio 8 has (deliberate & noted) support - specifically for ARM4-7 microcontrollers?     [edit]  We checked - and indeed this proves true - although (apparently) such does not, "Play nice" with our IAR IDE.     With the power of IAR - and not regular nor excessive "attachment" to host PC - that "support" for ARM 4-7 may be of questionable value.

  • 0 in reply to cb1
    Guru 55913 points
    That's at the MCU side - your writing steers toward PC side - that was not this thread's focus.
    Tend to disagree on substance in that:
    The client piece HID, specifies an Windows driver request that the TM4C device must follow in software design not the other way around. The TI HID driver for Windows device class supports only USB mouse and possibly keyboard interrupts. Unless mistaken that was one of the posters complaints that the HID driver device class was fixed.
  • 0 in reply to Genatco
    Genius 3585 points
    Hi BP101,

    I will check the Bulk example then. I'm focusing on custom HID primarily because it needs no driver installation from the user.
  • 0 in reply to Amit Ashara
    Genius 3585 points
    Hi Amit,

    I agree that there might be solutions with more throughput, but in my case the data rate what HID can offer is sufficient and the driverless, 'just plug it' way is very appealing. Please note that I wasn't talking about generic solutions just ONE more HID example besides mouse, keyboard and gamepad.
  • 0 in reply to cb1
    Genius 3585 points
    I agree 100%. It is funny, that in the era of USB everything (USB3.0 at the moment I guess), in the era of MBit transfers, we are still hacking our UARTs and install chips which are mimicking serial ports over USB. Just because the universal serial bus is so complex that those who understand and can effectively utilize it are the ones who really don't need to write a line of code anymore.
  • 0 in reply to Gergo Santha
    Guru 55913 points
    Hi Greg,
    Well we can't always rely on Windows plug and play manger to automatically install a proper HID for every custom device class or can we. Course if the vendor sends Windows Update a signed driver (msi) that becomes less of a bother to the user. How many times we click on check Windows Update for the manufactures driver and come up empty handed?

    Perhaps if we can get TI to post the Bulk driver to Windows Update then that becomes almost seamless.

    BTW: Visual Studio Bulk project file is in the latest Tivaware 12573 SW bundle 2015, 3.5GB download.
  • 0 in reply to Gergo Santha
    Guru 47900 points

    Thank you for that, Greg.      Progress proves - not always - wonderful!

    Our firm's been around long enough to have quickly (and profitably) thrown together Q-Basic Apps and been, "On the Air" with little drama - or time - or effort! 
     
    USB "saves us from ourselves" - much as the (unaffordable) "self-driving cars" will!    Ahhh Progress!     (prepare for WUI to replace DUI)

    (WUI - "walking under the influence")