I'm pouring through the StarterWare help file looking for extra insight on how to use the USB. (The file is OMAPL138_StarterWare_1_10_02_02.chm) I'll have some questions from time to time. I hope it's alright if I post them here.
1) I'm comparing two descriptions of the structure known as tHIDInstance. One description from usbdhid.h, and the other description from the above-mentioned .chm file. The two structures are an exact match, except the first five items from the .chm structure are absent from the same structure in the usbdhid.h file. I can't see any reason why there should be a difference. What's up?
2) I'm looking at the .chm file for insight about two related functions: USBDHIDInit and USBDHIDCompositeInit. The problem is the two functions are identical, except for their names. That is, they pass and return the same information, and they are both described identically. Here is the text for both:
Initializes HID device operation for a given USB controller.
That doesn't help unravel when to use one, versus the other. (Also, the example HID device mouse driver uses both function calls: first the CompositeInit, and then the Init. I can't figure out why.)
As mentioned in my opening post, I'm trying to clarify the usage (and difference) between two very similar functions: USBDHIDInit versus USBDHIDCompositeInit.
I discovered some hints of clarification by examining the parallel functions specifically for a mouse device: USBDHIDMouseInit versus USBDHIDMouseCompositeInit. Under the latter function, the .chm help file says this:
This call is very similar to USBDHIDMouseInit() except that it is used for initializing an instance of the HID mouse device for use in a composite device. [Walter comments: The .chm file doesn't illuminate how to do that.]
Since my USB port is to mimic a single USB HID device -- not multiple HID devices, and not a composite device -- then perhaps I am safe by merely using the one function, USBDHIDInit, (and completely ignore the USBDHIDCompositeInit function). ??? However, the mouse example from the StarterWare package calls BOTH initialization routines, even though it is likewise a single, non-composite device. It initializes the mouse twice: once with each function. So I remain confused. What is the difference between the Init versus CompositeInit functions? And how are we to use these?
Looking at source code sometimes is the quickest and clearest way to knowledge (at least more than reading comments).
Some calls seems quite redundant, because the last thing done by USBDHIDMouseCompositeInit is to call USBDHIDCompositeInit, but this is also the first thing done done by USBDHIDInit (after some ASSERT checks). Of course USBDHIDMouseCompositeInit is an API, so it could be used elsewhere than in USBDHIDMouseInit, even though I don't know how and for which purpose.
In any case USBDHIDInit always calls USBDHIDCompositeInit, so do not care for your implementation, the first will be enough. Or if you prefer, follow HIDMouse design.
By the way using "Composite" term here seems not the best choice, due to its meaning in USB context.
Thanks for your help. This forum, and the help you guys give, is a major reason why I'm a big TI fan.
Yes, the word "Composite" (as in USBDHIDCompositeInit) was confusing to me. I presumed it had something to do with initializing composite USB devices. Such as a keyboard with a built-in trackball, both using the same USB controller -- thus they together represent a "composite" device. I presumed that was the meaning, soI couldn't figure out the proper way to use these function calls. Also, the identical descriptions of the two functions (in the .chm file) made it hard to differentiate between the two functions.
I had previously thought (mistakenly) that the .chm file represented the entirety of my access to knowledge about the API -- the .chm file is intended as a complete description of how I am to use the APIs. I assumed (mistakenly) that the source code for the API libraries was unavailable to us, and that the deep dark bowels of the code could not be knowable to us. (Which would ordinarily be fine with me, as I really DON'T want to be overwhelmed with minutiae about USB.) But with your suggestion, I poked around some more and located the source files in question. So indeed, examination of the source code does over another avenuefor understanding things.
While I am grateful for that (as this StarterWare is a huge step forward for using USB), I also would hope for a better description within the .chm file itself. I want the APIs to HIDE the deeper information about USB, so Ineed not know about it. I just want to know the bare minimum for what I need to get done. (Information hiding is typically one of the goals of object-oriented programming design.)
Let me give a relevant example. The USB API returns various event codes to me (indicating errors, idle, resume, suspend, and so forth). And I need to handle those somehow. But, the .chm file grants no insighton how to confidently do that. For example, I am concerned that my handling might cause the USB to 'lockup'because I handled something wrong. Such as I'm waiting for the USB controller or Host system to do something, and they are waiting for me to do something -- so it locks up waiting. The .chm file could give some meta-level (overview) understanding of these matters, so that we developers could be more confident (and without having to read source code for the various USB libraries.......). That's my suggestion anyway.
Max thank you for your help.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.