Communication Device Class in Win7 for VCOM

[lilltroll77]

From the web I read
"Mac OS9 and OS X recognize the device instantly when connected."

"Windows system has a CDC protocol driver (usbser.sys) to generate virtual COM port. However, it requires a "Setting Information" file at the first connection. At this time, the patch driver (lowcdc.sys) is installed together."

I get an unknown device in the device manager when I plug in the VCOM example, but I have no clue what driver to feed it with.
Not even after reading at MSDN that mostly links to the ATMEL way of doing it.
I have tested several drivers but Windows refuse to eat them :(

[henkmuller]

I will look into this - there is a rumour that it is supported http://support.microsoft.com/kb/837637/en-us

[lilltroll77]

I downloaded the test driver from theSycon for the other USB stuff, but at least it didn't work "out of the box"
Do you have any ideas on how to to the Ethernet over USB on Windows ?

[henkmuller]

I still have to test that thoroughly - it may well be that there is a 'magic handshake' missing for windows. I saw some drivers from TI which I think are free and I thought would implement USB/CDC Ethernet...

On 17 Oct 2011, at 09:29, Mikael wrote:

I downloaded the test driver from theSycon for the other USB stuff, but at least it didn't work "out of the box"
Do you have any ideas on how to to the Ethernet over USB on Windows ?

Reply to this email directly or view it on GitHub:
#1 (comment)

[lilltroll77]

Hmm, would this vcom solve the 1½ year long problem with sending non Audio data to the Audio USB Card.
It has been many discusssion, here for an example
https://www.xcore.com/groups/usb-audio-20-group

theSycon wanted you to pay 3000£ or something upfront to be able to use the API.
I havn't heard of anyone that wanted to risk that amount of money. Even people that bought a batch of THX chips with the licens didn't get it.

There is companies that has released custom XMOS Audio product in there own brand.
How did they solve the USB communication dilemma in Windows?
Or has this been solved with drivers from other vendors ?
Is the vcom a open source way to be able to send nonAudio data, like filter coef from a host GUI, when using the card as a USB 2.0 Audio card.

[henkmuller]

I have not tried this but it may solve that problem. You could either put an ethernet or a VCOM device next to an audio device and send non-audio data both ways. THe Ethernetnet device would be portable - you could use a web server to configure your audio board.

[lilltroll77]

We tried it in Ubuntu 10.4.3 LTS as well. The Ethernet starts as Eth1, but it is impossible to establish a connection to the VCOM, even if it is seen both in "lsusb", and in /dev/
Can you verify that the existin vcom GIT code is working on Mac, and if so gist a dump of the log file created when plugging in the USB XMOS device.

[henkmuller]

Just checked it - the current version works.
As requested I have called it XMserial (rather than Ethernet!), will push that change in a minute.

On the Mac it comes up with a window:

A new network interface has been detected

The "XMSerial" network interface has not been set up.
To setup this interface, use Network Preferences.

I then press "Cancel" because it isn't really a network interface (the Mac thinks it is an old fashioned AT-modem on a USB cable), and then do in one window

% cat /dev/cu.usbmodem2621 
HELLO
THIS IS A TEST FROM XMOS 1234!
^C
%

while in another window:

% echo 'Hello' > /dev/cu.usbmodem2621 
% echo 'this is a test from XMOS 1234!' > /dev/cu.usbmodem2621 
%

The kernel.log file has two lines related to this:

Nov 10 11:12:07 henk-mullers-imac kernel[0]: USBMSC Identifier (non-unique): 000000009833 0x5ac 0x8403 0x9833
Nov 10 11:12:08 henk-mullers-imac kernel[0]: AppleUSBCDCACMData: Version number - 4.0.1, Input buffers 8, Output buffers 16

The server.log is empty.

On linux I would expect a new /dev/tty to appear - it is worth trying

ls -latr /dev

and see what the most recent file is. I will see if I can find a linux box somewhere...

[henkmuller]

On a linux box I can see a problem:

Nov 10 11:26:20 starbug kernel: [2685888.415813] usb 1-3: configuration #1 chosen from 1 choice
Nov 10 11:26:20 starbug kernel: [2685888.843201] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
Nov 10 11:26:30 starbug kernel: [2685898.840218] usbcore: registered new interface driver cdc_acm
Nov 10 11:26:30 starbug kernel: [2685898.840222] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Nov 10 11:26:30 starbug kernel: [2685898.922513] usb 1-3: USB disconnect, address 2

The last line isn't good. It keeps the CDC ACM module in there though. Sometimes it takes a while to disconnect, in which time it does not complain when I access /dev/ttyACM0 - but it does not give me data either.

[henkmuller]

Success on linux...

root@starbug:/home/henk# cat /dev/ttyACM0 &
[1] 24705
root@starbug:/home/henk# 
root@starbug:/home/henk# stty < /dev/ttyACM0
speed 9600 baud; line = 0;
-brkint -imaxbel
-echo
root@starbug:/home/henk# echo 'hello' > /dev/ttyACM0
root@starbug:/home/henk# HELLO

echo 'hello' > /dev/ttyACM0
root@starbug:/home/henk# HELLO

echo 'hello' > /dev/ttyACM0
root@starbug:/home/henk# HELLO

Will push in a minute.
If you do not do the 'stty -echo < ...' the linux kernel will echo characters back to the device - which leads to an infinite loop of HELLOs with ever increasing numbers of carriage returns and line feeds (they are expanded each time around the loop).

[lilltroll77]

Great, if we can verify it on Linux, it is easier to track problems in Windows, since we have something to compare to.

[henkmuller]

Ethernet example (ecm) also works under linux now, but you need to go to http://169.254.85.85/ in order to use http://blah.local/ you will need avahi or similar

[lilltroll77]

Yes I saw the IP for the XMOS side even if it was written in HEX. It seems to be working fine now the ECM.
Over to VCOM.

[henkmuller]

Is it working fine on Windows or on Linux?
I will add a rudimentary matrix of supported platforms for each VCOM and ECM.

[lilltroll77]

Yes I had no problem at all yesterday in linux. What about Windows?
At least the VCOM should be able to run on Windows own CDC driver. Making it a "freeware"
We had problem earlier, and tested 14 different versions driver, but maybe that will be resolved now with the new code XMOS code. Or do you have a trick for Windows as well ?

[lilltroll77]

An other thing, can VCOM be fitted in the XTAG2 ? Has it place for VCOM code?
I havn't made a deep dive into the XTAG2, but it is the toolchain that loads the program into the XTAG2, am I right ?

[henkmuller]

So for linux I had to change it because, despite the USB device stating that it has no capability do do line-state-settings, the linux driver tries it anyway, and when we don't respond hangs up. So I have faked that. It may be that windows will ask for something similar...

About the XTAG2 - there is some space left in there, but that is mostly used at the moment for buffering xscope data. In theory you could slot VCOM in there. I am not sure whether the XTAG2 will be running out of threads, I will need to check.

[lilltroll77]

What about that you could choose.

1. Hi speed scope single way
   or
2. full duplex VCOM, for your own purpose

[henkmuller]

Yes that may work.

But, the user would have to "reboot" their XTAG2 when switching modes - it would be nicer if there was a soft switch. I will have a chat with the XTAG2 designer and see what room there is...

[henkmuller]

VCOM on windows is now working using the .INF file on xcore (now in github), and some extra handhelding for the windows usbser.sys driver.