Hi Geoff
I am not aware of anyone who has worked with this class.
I am assuming you are interested in operating as a device so I'll give some details about the classes in the present project version and how new classes are added.
1. The USB device driver is generic (class-less) - made up of the USB HAL in
kinetis_USB_OTG.h or
USB_HW_Device.h, plus
USB_drv.c (generic, class-less and HW-independent)
2. The class and application (the application may in fact be the class itself or the class with some additional interfaces for a specific application) is realised in
usb_application.h3.
usb_application.h includes a descriptor file (eg.
usb_cdc_descriptors.h) which defines the descriptors used during enumeration, describing the use of endpoints for a single class with one or more interfaces, or for composite types with multiple classes/interfaces.
4.
usb_application.h includes CDC (and/or RNDIS), HID (raw, mouse, keyboard), MSD and audio which allows one or composite configurations of these to be selected.
5. To add a new class one can replace
usb_application.h with a new file that includes a new descriptor file (rather than directly integrate a new class into the composite environment - which can be done as a second step if desired).
6. The first thing to do is to construct the descriptors (the easiest way to start is to do a recording of a similar device and just plug in the same values - one can adjust them later once one has more understanding of what they control and what one wants). Enumeration should work using the original
usb_application.h including this new descriptor. I have seen that USBTMC uses the same endpoints as CDC (control, bulk-in, bulk-out and an optional interrupt endpoint).
7. Now it is necessary to handle the class initialisation, meaning interpreting and responding to control endpoint requests and possibly any bulk endpoint messages (if they exist).
Again the easiest way to start is to record a similar device and do exactly the same to begin with.
8. Once class initialisation is compete the actual useful part starts where the applications at the host and device use the connection for their real work. Rather than (as in CDC) being a transparent communication link it looks like USBTMC is built up on class messages passing commands and such so each of these message types need to be interpreted at the class level and responded to accordingly. Application events/data that are exchanged can be passed to/from the application layer (usually via queues (fnRead()/fnWrite()) or handled directly if the application/class are a single unity.
9. I am not going to pretend that it is simple, even though the generic layer greatly simplifies the task due to the fact that one doesn't need to get involved with the low level USB2.0 or HW operation and can concentrate on the class exchanges; adding and testing a new class can take a few days of work and the USBTMC looks to have quite a number of messages to be implemented (a little more that MSD). It also need some general USB knowledge and a USB analyser.
10. What is possible in the uTasker USB environment, however, is that reference operation can be simulated (using a script that injects the host endpoint data in the sequence that it arrives in a standard case) so that if such a recording exists (from a USB analyser) the new class can be implemented and tested directly in the simulator (visual studio) meaning that basic operation should be possible without any development on the HW needed. Usually there will be some additional surprised during real use but 'exceptions' can then be analysed and solved as they arrive.
There is a very small example of USB scripts in the document http://www.utasker.com/docs/uTasker/uTaskerV1.3_USB_Demo.PDF (page 13).Regards
Mark
