Virtual Communication (COM) Demo - CDC device is necessary

[ThomNet]

Hi

in the USB Host User's Guide, Rev. 4, Appendix C Virtual Communication (COM) Demo, under C.1 Setting Up the Demo it is mentioned: "Note: To run this demo, a CDC device is necessary"

Is there a simple CDC device to be recommended, which I can buy, to run this demo successfully?

I have a CDC device, which is a mobile telephone unit and which I have connected to my TOWER system but I'm not getting any character echoed back from it, may be because of driver incompatibility.

Therefore I'm looking for a CDC device which has been tested with the example application and works.

Thanks for helping!!

Thomas

[ThomNet]

HI Martin,

thanks for the information.

I've just ordered it.

THomas

[ThomNet]

Hi Martin,

I would like to ask you again for your support.

I have attached 4 photos:

1.) The terminal log of the attach process of the USB2SER to my TOWER system with 1 interface.

2.) The terminal log of the attach process of a LISA-U230 mobile phone module to my TOWER system with 5 interfaces

3.) A photo from my USB2SER EVB

4.) A photo from the LISA-U230 EVB

How can I differenciate between the 5 interfaces from MQX ? Do the interfaces have dedicated names, like tty0, tty1, tty2, tty3, tty4 and who is giving those names? If there is a name, what is the name of the USB2SER interface and where can I find it in the source code?

Thanks again for any ideas

Thomas

[Martin_]

I was working on similar problem, when up to 4 cdc devices could be attached to Tower usb cdc host via USB HUB.

The thing is that because we attach multiple usb devices of the same class, the usb host stack calls the same callback functions (usb_host_cdc_data_event() and usb_host_cdc_acm_event() as registered via USB_HOST_DRIVER_INFO structure) for all of them.

The assignement of file names to the attached devices is done at application level. It is in usb_host_cdc_data_event callback for the USB_INTF_EVENT case, by calling function usb_class_cdc_install_driver(data_parser, device_name)), where the device_name will be one of the file names.

So, we need to implement a solution at application level to assign "tty0:", "tty1:" ... "tty4:" file names to attached devices dynamically, and close the files when a device is detached.

My solution was based on the order of attach. I specified for my application, that the 1st attached device will be "tty0:", second "tty1:" and so forth. Then I modified the communication task in such a way that it reads/writes from/to the attached devices. When a device is detached, the corresponding file is closed and removed from a list of attached devices. I have a demo for this - modification of the default MQX demo /usb/host/examles/cdc/cdc_serial - to support 2 attached cdc devices via usb hub at one time, I think it can be extended to 5 quite easily. If you compare the attached cdc_serial.c with the MQX 4.0 default cdc_serial.c you will see differences.

[ThomNet]

Hi Martin,

thanks again for your quick and very detailed reply.

I will let you know any new and positive results.

Thomas

[ThomNet]

Hi Martin,

I have testet your cdc_serial.c file and I have checked it with the EVBUSB2SER board and with the LISA U230 board. See the two terminal logs.

I'm wondering that with the USB2SER it opens tty0 (good guy!!) but with LISA it opens nothing. With LISA shouldn't it open at least tty0 and tty1? Do you have any idea why?

All my best

Thomas

[Martin_]

Hi Thomas,

I guess it is caused by the order of the events. The code I sent expects an attach event is immediately followed by an interface event, as this happens when you attach one by one device via USB hub. Your device seems to have different order of events - it goes through attach of all cdc devices, then it goes via interface events of all devices.

To modify the applicaton behavior, we can add a short code into interface event switch cases, to find index corresponding with the device that caused the interface event. Proposed cdc_serial.c is attached. Please let me know if it works.

-Martin

[ThomNet]

Hi Martin,

thanks again!!

I have checked the file, you've send to me. It's the same behavior as before. I have attached the terminal log screen shot with 3 x the attach log.

Interesting to watch is the fact, that one control interface seems to be missing?

May be this gives a new idea?!

All my best again

Thomas

[Martin_]

Hi Thomas, actually, I inadvertently introduced an error in application data interface callbacks.

Hopefully this one is correct. The handling of multiple cdc data devices is at application level, it should be easy to debug.

[ThomNet]

Hi Martin,

I'm still in the phase of debugging and I think, I'm getting closer.

I have another question, which probably is easy for you to answer:

Is MQX 4.0 supporting the usage of USB high speed over the TWR-SER2 board?

Thomas

[Martin_]

Hi Thomas,

the High speed USB (EHCI controller) is supported in twrk70f120m BSP. This BSP can work with TWR-SER2, where the high speed ULPI is connected to mini-AB receptacle.

To configure usbh/usbd library to use the ehci controller, in twrk70f120m.h we need to define:

#define USBCFG_DEFAULT_HOST_CONTROLLER    (&_bsp_usb_host_ehci0_if)

for usbh + ehci.

#define USBCFG_DEFAULT_DEVICE_CONTROLLER  (&_bsp_usb_dev_ehci0_if)

for usbd + ehci.

-Martin

[ThomNet]

oh I forgot, i extended MAX_CDCDEV_NUM  to 8 (#define MAX_CDCDEV_NUM  8). Therefore we get the 5 well known interfaces now. Thomas

[ThomNet]

Hi Martin,

thanks again.

Great, for tty0 it works (see below)! Is this also what you expected? tty1? Is this my part now to extend the source code? My LISA modul is still not responding. May be it's to early for it and it's still sleeping :-)

Speaking to ublox, they told me that only 3 tty's are responding to AT commands. May be tty0 is speaking to the non AT port? I will find out.

If you have any idea to make tty1 also working, please let me know.

All my best again

Thomas

[Martin_ · Accepted solution]

Hi Thomas,

I use Freescale's USB2SER as CDC device, tried with MQX 4.0 and TWR-K60N512 and it works.