So you've got a TI platform (ARM, DSP, OMAP, etc. -- hereafter "USB device") that you want to communicate with a Windows application. You're writing both ends of that application -- the TI-side, and the Windows-side -- but you want it to communicate through the USB link. How to?
The Microsoft WINUSB API is a great way to make that easier. No need to write user-mode or kernel mode drivers. Your Windows-side application can communicate with the USB device through this clean, supported, documented API interface. Tasty!
Until recently, that solution was made needlessly complicated by the requirement for an INF file and surrounding minutiae. You had to create an INF file (".inf") to precise specifications (with a GUID inside it), and it must be specially "signed" (through some cryptic process), and include two different co-installer executables, and put it all inside a "driver package". Then you had to actually install it successfully. This was even more complicated if someone else -- say, a customer -- was doing the installing. You had to e-x-p-l-a-i-n it to them. Ugh! Lots of inconvenience, and lots of room for failure.
Well, now there's a way to do it all auto-magically, without an INF file. Just plug-in your USB connection, and it works. Plug-and-Play. And it works on all Microsoft operating systems going back to XP. (And all the necessary Windows components will be installed automatically, simply by enabling your Windows Driver Updates!)
That's all fabulous! I can see the future!
All this tasty goodness requires just one, more, thing: An update to the TI USB Starterware, to make it speak Microsoft. I've been examining the Microsoft requirements, and it looks pretty straightforward to make the changes to TI Starterware.
It requires creating three simple packed data structures:
- The first basically says, "I know the secret Microsoft protocol, therefore I get to play the game!" (It is 18 bytes long, and unchanging. It will be the same on every USB device.)
- The second basically says, "I want to communicate through the WINUSB API interface." (It is 40 bytes long, and unchanging. It will be the same on every USB device that wants to use the WINUSB API.)
- The third includes the GUID. (It is 142 bytes, and once you set it up for a particular application, it is unchanging. Except for the GUID, it will be the same on every USB device.)
The GUID is a long string of (random) numbers, that Windows uses to figure out which application to connect the USB device to. A GUID is created easily using a tool in MS Visual Studio. Previously, the GUID was held in the INF file, but that file is no longer needed, by using the new solution. Since the USB device and the Windows-side application both will contain the same GUID, they each communicate it to Windows, which then connects them together -- without an INF file.
I've created those three packed data structures in CCS. Now it's onward to updating the TI Starterware. The change is simple in concept: When the Windows host asks for these data structures, the USB device should send them -- just like it sends other similar data packets. It's that straightforward. MS has a unique command-byte that "asks" for them, but it's simple to catch that, and then respond with the proper data structure. Microsoft has done a good job of melding their protocol into the USB standard, so the changes are seamless, easy, and invisible to all the lower layers of USB handling.
Before I get into details, I want to ask: Is anyone here (a TI employee, or a TI customer) working on this? Are there plans for this? (Should I wait for TI to do it? -- it might take years.....)
-- Walter
P.S. The Microsoft protocol allows for some additional options, such as dealing with power issues: selective power-down, and remote-wakeup. But those are unnecessary for most TI customer applications. Rather, the central benefit of this approach is to get rid of that darned INF file.
