Multiple CDC devices under USB 5.0 Beta stack

[johnstrohm]

We're developing a custom USB device (as opposed to host) around a K50 microcontroller.  This is a rebuild of a device that was originally based on another vendor's part, which has been discontinued (with no migration path!).  (Yes, we're ticked, as are a lot of their other customers for that part.)

Our device must support multiple (2 or more) instances of the USB CDC device class.  We have multiple serial ports.

At first read, the 5.0 stack does not seem to support multiple instances of a device class.  Am I missing something, or is this actually the case?

[Kan_Li]

Hi John,

I just consulted with our USB stack team, the CDC Owner told me the USB stack CDC class support multi-instance.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mhanuel]

Hello Kan Li,

I have found your post as the only reference to a CDC device with more than one UART using kinetics. I am working with K82F device, would you please let me know if there is some documentation about how CDC stack need to be modified to have more than one UART with same USB device? 

Will appreciate  if you or someone else have manage to do the above and can enlighten me.

Thank you in advance, 

[johnstrohm]

Kan, can you please point me to some example code?

I see how it supports multiple endpoints, each with its own queue.  I am admittedly still recovering from a very enjoyable vacation trip, but I don't see how the CDC device class driver communicates *WHICH* endpoint just received data to the application when it calls the callback to notify the application that data is available.  Is the application expected to poll all possible queues?

--John

[mjbcswitzerland]

Hi John

In case you get stuck with your requirements note that the uTasker project supports multipe CDC instances (also mixed with other classes) wîth end-to-end flow control for virtualCOM<->UART and support for all Kinetis USB parts (including the ones with crystal-less capability). It's simulator also allows USB simulation which makes application development and USB driver code reviews much easier to perform. The USB device stack has been industrially proven over several years (Coldfire and Kinetis) and is fully supported.

Regards

Mark

PS. The present download (from following link) doesn't include composite devices but simply contact me in case of interest.

µTasker Kinetis support

[johnstrohm]

We are building a composite device, that contains an Audio device of our own specification, a minimal (reboot only) DFU device, a HID device, and some number of CDC devices.  (It is actually a family of devices, using a common executable.  Depending on pin straps and programmable parameters in a non-volatile memory, it decides (among other things) how many CDC devices to instantiate.

So yes, we would need composite device support.

Does µTasker include its own USB stack, or does it use the Kinetis stack?

[mjbcswitzerland]

John

uTasker doesn't use the Kinetis stack but has its own solution consisting of three files:

- A HW driver (adapts itself to whichever part is being used without needing special headers). There are two Freescale ones, for Kinetis (KL and K) and for Coldfire V2.

- A generic USB file which is HW and class independent.

- A Class/Application file which supports HID (mouse/keyboard), CDC and MSD

It can be built and tested using VisualStudio (with all USB activity/interrupts simulated) so that complete applications can be developed, tested and debugged without need for HW or time-critical breakpoints (that othewise can cause the host to declare errors and make debugging almost impossible).

The user can select which device class support is required:

	//#define USE_USB_HID_MOUSE	// human interface device (mouse)
	#define USE_USB_HID_KEYBOARD	// human interface device (keyboard)
	#define USE_USB_MSD	// needs SD card to compile
	//#define USE_USB_CDC	// USB-CDC (use also for Modbus over USB)

EIther one of these or a mixtures can be set and the class/application builds itself accordingly.

If USE_USB_CDC is specified the number of interfaces can be optionally increased by adding (eg. of 3 CDC in total)

#define USB_CDC_COUNT  3

The standard class/application file links the CDC interfaces to UARTs, for example

	#define CDC_UART_1	1	// UARTs to be used with multiple USB-CDC/serial connections
	#define CDC_UART_2	2
	#define CDC_UART_3	3
	#define CDC_UART_4	4
	#define CDC_UART_5	5

where the first interface is linked to UART1, the second to UART2, etc. according to the defines (which pins each UART muxes to is defined elsewhere - the UARTs are interrupt and/or DMA driven, with or without flow control, whereby each one can operate in a different mode as required)

The class/application file is a "user file" so can be modified as necessary to do anything else needed, or different handling, by the specific application.

There is also is a boot loader class/application file that supports firmware loading [http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF and Kinetis K60 Tower Kit - Flexible Boot Loader - YouTube] via USB-MSD and has also a selectable KBOOT HID mode (or older Freescale  "HIDloader.exe" mode). There are a range of pre-built binary that can be loaded to  standard FSL boards at µTasker Test Software and Demos

When using USB-MSD it automatically works with an SD card using utFAT http://www.utasker.com/docs/uTasker/uTasker_utFAT.PDF [the boot loader model emulates FAT12 for programming to internal Flash].

The class/application file controlling composite operation simply has a set of descriptors for each mix. These are consts in Flash. If you want to start up with configurable sets it is possible to either have a number of predefined ones, whereby the one to use in a session is determined during enumeration. The standard user interface to the generic layer uses:

extern void *fnGetUSB_device_descriptor(unsigned short *usLength)

{

    *usLength = sizeof(device_descriptor);

    return (void *)&device_descriptor;

}

As you can see it returns a pointer to the device descriptor to be used, which could be selected from a list defined on an input etc. The generic layer does all of its work referencing this so there is no further application layer involvement until actual application data is present.

Or it would be possible to dynamically construct a descriptor in static RAM to avoid the predefined ones (with a bit more SW effort to construct it correctly).

The USB device operation is documented in http://www.utasker.com/docs/uTasker/USB_User_Guide.PDF and uses a unique endpoint coupling technique which means that the user sees the USB-CDC as if it were a bi-directional UART interface and can use identical code to using a UART (http://www.utasker.com/docs/uTasker/uTaskerUART.PDF).

QUEUE_HANDLE usbHandle = fnOpen(TYPE_USB, 0, &tInterfaceUSBParameters); // open USB-CDC interface [using paired endpoints]

QUEUE_HANDLE uartHandle = fnOpen(TYPE_TTY, FOR_I_O, &tInterfaceUARTParameters)

fnWrite(uartHandle, "Hello, World!", 13); // send string out on UART

fnWrite(usbHandle, "Hello, World!", 13); // send string out on (connected) USB-CDC

and

fnMsgs(uartHandle); // get waiting length in UART input buffer

fnMsgs(usbHandle); // get waiting length in USB-CDC input buffer

etc.

It the two need to be changed one can simply do

QUEUE_HANDLE temp = uartHandle;

uartHandle = usbHandle:

usbHandle = temp;

and now all UART code works with the USB-CDC and inverted.

The uTasker MODBUS module can, for example, work on UARTs or across USB connections by just setting the handle appropriately.

What is however not included is an audio class interface since the existing included ones are all bulk (not isochronous) but I don't think that there is any big difficulty involved to add one since the generic layer was designed for this mode too. If a USB analyser is available it is possible to record the operation of reference devices and then feed these sequences through the simulator as stimulation base for adding appropriate application level code to handle them (eg. it was possible to implement the KBOOT HID mode within a few hours starting with a recording of its operation with no need to debug on the HW because all development and debugging had been completed beforehand - it was already complete for all KL and K parts due to the HW abstraction layer).

Regards

Mark

P.S. Update: The uTasker stack now supports RNDIS (based on CDC) together with composite pure CDC etc. It also supports USB-Audio, whereby it can be seen in action at https://www.youtube.com/watch?v=n-GABeILGV8&feature=youtu.be

http://www.utasker.com/docs/uTasker/uTaskerRNDIS.pdf
http://www.utasker.com/docs/uTasker/uTaskerUSB_Audio.pdf

It is also available as open source project for those who don't need support and works on all Kinetis parts with USB (no porting needed).