[Teaser] FullDuplexSerial_001 compatible USB serial device

[BradC]

G'day all,

Just another teaser I'm afraid. I have one minor bug to squash (which is driving me up the wall) before I release this into the wild.

It "Just works" on Mac OS, requires an .inf file for Windows and requires some minor patching to the uhci driver (remove 3 lines of code) with Linux.

I've used the VID/PID pair for the AVR CDC driver temporarily so I can use the supplied .inf for that, it will likely change before I release the proper object.

As you can see below, I'm currently getting sustained bi-directional read/write speeds of about 6.5K bytes per second. I've not tested it unidirectionally and the main loop is in spin (it just reads a byte from the fifo if available and writes it back out again. It's not really quick enough and I think if I wrote it in asm I could get the bus utilization up a bit, but this is typical of the sort of spin app you would use the object in.




brad@bklaptop2:~$ cat /proc/bus/usb/devices | grep -B 4 -A 8 Propeller

T: Bus=02 Lev=02 Prnt=33 Port=01 Cnt=01 Dev#= 77 Spd=1.5 MxCh= 0
D: Ver= 1.01 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=16c0 ProdID=05e1 Rev= 1.00
S: Manufacturer=Brads-Propeller
S: Product=CDC-ACM-HACK
C:* #Ifs= 2 Cfg#= 1 Atr=40 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=100ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E: Ad=01(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms

brad@bklaptop2:~$ lsusb
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 077: ID 16c0:05e1
Bus 002 Device 033: ID 058f:9254 Alcor Micro Corp. Hub
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

brad@bklaptop2:~$ stty -F /dev/ttyACM0 raw ; cat /dev/ttyACM0 & sleep 1 ; killall cat ; rm test.1 test.2 ; dd if=/dev/urandom of=test.1 bs=1M count=1 ; sync ; cat /dev/ttyACM0 | pipebench -b 128 > test.2 & sleep 1 ; sleep 1 ; cat test.1 > /dev/ttyACM0 ; sleep 2 ; killall cat ; sleep 1 ; sync ; echo; echo ; echo ; md5sum test.1 test.2
23615
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.677055 seconds, 1.5 MB/s
+ Terminated cat /dev/ttyACM0
23638
Summary:
Piped 1024.00 kB in 00h02m32.52s: 6.71 kB/second
+ Done cat /dev/ttyACM0 | pipebench -b 128 >test.2



2a6d11cd32b2729d03c69daf581a7056 test.1
2a6d11cd32b2729d03c69daf581a7056 test.2
brad@bklaptop2:~$

[hippy]

@ BradC : That's excellent work and good luck with the bug squashing. I'm just about to add a USB port to my proto board to test your earlier USB keyboard code and USB serial is something I am really looking forward to.

[Ariba]

BradC

That sounds very interesting. I also worked on a Software USB the last days, and yesterday I had the first success with it.
It enumerates, and I can communicate with Libusb. A CDC version was also on my plan, but now I wait for your
expiriences with it, I don't have MAC and Linux for testing.

I think you will not get a speed that are much faster than now. With Lowspeed USB you can transfer max. 8 Bytes per 1 ms
this gives 8 kByte/second. Or is this different on BulkTransfers? The problem is that CDC uses Bulk transfers, and they are
theoretically not allowed in LowSpeed mode. It works on most computers, but not on all, and therefore CDC is not practicable
for mass products.

I hope you find the bug and release it soon...

Andy

[BradC]

Andy

Yes, low-speed bulk violates the spec in nasty ways. It works on Mac OS, Windows, Linux 2.4 kernels and Linux 2.6 kernels if you comment out a check in uhci-q.c
They have just introduced a patch into the latest development kernel which changes low-speed bulk endpoints into interrupt endpoints and that needs commenting out
before it'll run too. We are discussing this on the linux-usb-devel list at the moment to see if there is a way forward.

You are right about the interrupt transfers, they should be theoretically limited to 8K/s, but as I'm not using them I don't see that yet.

Additionally, my protocol stack violates the 7,5 bit time turnaround requirement for low-speed USB, and relies on the host not timing out the transfer for 16 bit times (which _is_ in the spec).
I fully CRC check each inbound packet, and this takes longer than the spec allows.