USB toys to play with
BradC
Posts: 2,601
Ok all,
I've got these into a shape that I'm not incredibly embarrassed to show them to the world. (Some parts are still pretty icky)
You'll probably figure it out yourselves, but the files are
USB_lowlevel - the media driver common to all my USB stuff
USB_california - the "California Dreaming" demo beaten into decent shape. It will type the song any time a keyboard led changes state (caps/num/scroll)
USB_Serial - the FullDuplexSerial compatible serial object
USB_Demo_main - very simple loop to loopback serial data for testing.
avrcdc.inf - the driver description file for windows. Lifted from the AVR-CDC project (I've also lifted his VID/PID so as to make it all fit together easily)
The USB_Serial has passed repeated testing on linux, macos and windows with over 20MB each test (takes a little over an hour)..
[noparse][[/noparse]edit] No data corruption, my testing methodology was flawed and I was losing the last 8 bytes due to a premature pipe flush. [noparse][[/noparse]/edit]
The USB_Serial object is not USB compliant (uses bulk endpoints on a low-speed device) but it works on every windows box I've tried it on.
None of the objects are really USB compliant as they take too long to respond to the host. They do respond within the limit of the specification though and therefore should function on any host
you plug them into.
Have at it.
Brad
Edit: If you install the driver for usb-serial on Windows, you will need to change the VID or PID of USB_california or else windows will stupidly think it's a serial port and not a keyboard.
This is not a problem on sane operating systems.
having said that, I should have changed the vpd/pid anyway.
Post Edited (BradC) : 9/16/2007 12:53:29 PM GMT
I've got these into a shape that I'm not incredibly embarrassed to show them to the world. (Some parts are still pretty icky)
You'll probably figure it out yourselves, but the files are
USB_lowlevel - the media driver common to all my USB stuff
USB_california - the "California Dreaming" demo beaten into decent shape. It will type the song any time a keyboard led changes state (caps/num/scroll)
USB_Serial - the FullDuplexSerial compatible serial object
USB_Demo_main - very simple loop to loopback serial data for testing.
avrcdc.inf - the driver description file for windows. Lifted from the AVR-CDC project (I've also lifted his VID/PID so as to make it all fit together easily)
The USB_Serial has passed repeated testing on linux, macos and windows with over 20MB each test (takes a little over an hour)..
[noparse][[/noparse]edit] No data corruption, my testing methodology was flawed and I was losing the last 8 bytes due to a premature pipe flush. [noparse][[/noparse]/edit]
The USB_Serial object is not USB compliant (uses bulk endpoints on a low-speed device) but it works on every windows box I've tried it on.
None of the objects are really USB compliant as they take too long to respond to the host. They do respond within the limit of the specification though and therefore should function on any host
you plug them into.
Have at it.
Brad
Edit: If you install the driver for usb-serial on Windows, you will need to change the VID or PID of USB_california or else windows will stupidly think it's a serial port and not a keyboard.
This is not a problem on sane operating systems.
having said that, I should have changed the vpd/pid anyway.
Post Edited (BradC) : 9/16/2007 12:53:29 PM GMT
Comments
So it passed a 120MB loopback test with zero data corruption/loss.
I've also tried a hack where we bypass all the fifo/queues and just re-assemble the incoming packets and loop them straight back out again in the application cog.
Maximum sustained transfer rate of 7.6KB/s full-duplex. I "assume" you should get nearly double that in one direction.
Brad
Not had chance to play yet, but once I get some spare time, I will, as this is interesting stuff.
Well done matey.
Baggers.
Do you think it is possible for you to create a low-speed software USB host using a propeller?
It would be nice to be able to use generic usb mice/keyboards on a prop...
Nik
It would not be easy from a protocol handler perspective and its way down my list of things to try.. but it is something I've been giving some thought to.
It would certainly be a single USB object per device though, hub enumeration is _way_ out.
According to www.recursion.jp/avrcdc : "No dedicated driver necessary.
CDC loads Windows built-in usbser.sys"
Unfortunately, it's not taht simple on my system; Windows XP SP2.
It recognises the device is connected, launches the New Hardware Wizard, I select the
directory for avrcdc.inf, tell it to continue with the unsigned driver, off it goes to
update files, "usbser.sys to F:\Windows\System32\drivers" but then fails with "An error
occured during the installation of the device. The system cannot find the file specified".
Is it really too much to ask that Bill G could have his software name "the file specified" ?
I don't think it's usbser.sys because that's in *\drivers, and when I copy it to
the avrcdc.inf directory, rename it and update avrcdc.inf that renamed
.sys file is copied over to *\drivers ... then the 'file not found" report
is given.
Anyone got any ideas on how to move forward ?
All I can say is it "just works" under MacOS and Linux (with a hack)..
I hate windows.. no ..really..
Does the California Dreamin' demo work for you? I wonder if you run that first does that bugger the driver installation for the serial port as they both use the same VID/PID pair.. (yes, I'm a twit)
Sorry for the hassle.. I don't actually _do_ windows, though I "obtained" a copy to test it on a machine here..
[noparse][[/noparse]edit] After another attempt, I just got it to work under Win2k with the avrcdc.inf file.
Know that does not help you though hippy. Bloody flaky OS. I tried that for a day and it never worked. 4 days later and it works 1st go.
The difference was the first time I guess I tried to tell it to use a device then selected "have disk". This time I just put the .inf the the root
and told it to add that to its search path. Different problem than you are having with the file not found error though I guess..
[noparse][[/noparse]\edit]
Post Edited (BradC) : 9/16/2007 8:54:51 PM GMT
No worries; you've written an astounding bit of code, and this is
fluff which 'the other side' needs. That it gets as far as it does is
amazing enough.
No joy on Windows 98 SE either, but I wasn't expecting any miracles
there. Can get it indicated as 'working okay' under Device Manager
as a Composite USB Device ( COM & LPT ) or a Lucent Corp USB
Modem ( that uses a CDC-mode driver ) but cannot get to assign a
COM port :-(
USBVIEW.EXE shows your part of the universe working as would be
expected ( as best I can tell ).
I'll try the keyboard USB and twiddle with the PID's to see if I can
get any further. I'm afraid I'm no USB expert at all so I can only
'poke 'n' hope' and see if something springs to life.
At least I've confirmed the hardware works and the pinouts for
the USB connector
Never saw it under XP, linux or MacOS though..
You can ensure it does not happen by rebooting the prop before you plug it in.. I have to plug/unplug the prop 3 or 4 times under 2k to get it to latch up..
Chasing it down now..
Fixes the lockup on unplug/replug under windows. I never saw it under XP, but it would have done it there.
The rx routine was not seeing EOP if you unplugged it in the middle of a packet. Linux and MacOS only poll the device while it's open. Windows hammers it from the second it enumerates.
So in Windows unplugging the device had a very high chance of unplugging mid packet. The receive routine would just keep on going, thinking it was getting lots of continuous data and
with the indirect addressing was scribbling all over the COG ram until it hit dira and switched itself off. (nice safeguard that!)
No difference to data behaviour, just made unplug/replug more reliable on Windows.
Brad
I got a chance to try out the USB serial port. Great job!
A few questions though... I managed to get it to work on a propeller using a 5Mhz crystal under Windows XP with absolutely no problems.
But on a propeller that uses a 6Mhz crystal I get an unrecognized device error. I changed all the obvious things (5_000_000 declarations)
but no luck. Any ideas?
Also I tried it on my Ubuntu 7.04 and it seems to find the device OK. here's my dmesg
After unplugging and replugging I get a little less info
My PC seems to know the port is there but when I try to actually use it (kermit), I get an error message when I send a character.
Your code mentions something about a slight kernel patch required and maybe this is what I'm running up against. What has to be done to make linux work?
One more question, you mentioned achieving about 6-7k/sec transfer rate. Do I need to do anything special concerning transfer speed.
Under windows I was able to open the port at 230400baud and it seemed to work (just echoing characters). Will the USB driver and propeller negotiate the actual
maximum speed, or is it possible to send data too fast.
Thanks again. This is a great addition to the propeller's capabilities.
-Chad
1st.. it is _absolutely_ hard coded to an 80Mhz cog speed. It will not work at any other clock speed, so I guess the 6MHZ crystal is out. Unfortunately this is just an artefact of the bit bashing used to run the USB MAC.
I guess if I got hold of a 6MHz crystal I could produce a USB_lowlevel driver that would be tailored to run at that speed. It's only a matter of adding some extra delays.
2nd. Ubuntu 7.04 will find the device, but will not be able to talk to it as the uhci driver blocks all attempts to send bulk packets.
If you are interested in patching/compiling your kernel, I'll write a nice detail on what needs to be changed. It's only commenting out 3 lines in the kernel 7.04 uses (I'm using it on this machine here)
I've never actually recompiled an Ubuntu kernel, but I believe it's pretty easy. I compile all mine from the vanilla kernel.org sources when I need to modify them.
3rd, Baud rate is completely irrelevant to this device. The commands that the PC sends to the prop to set/get baud rate are received and ignored. The device will send/receive data as fast
as it's little cogs will carry it.
There is complete flow control built in, so the whole chain will throttle the transfer speeds as required to suit the data source/sink. The USB protocol has reasonably efficient flow control built in, so if your spin
program is not reading the data fast enough, the system will just throttle back until there is space in the buffer at each end. No data will be lost.
Good news in that it means it can work, bad news in that it means
there's something odd/wrong with my PC. Thanks for the report.
If only XP reported which file it was it could not find I think I'd be
a lot closer to getting it working [noparse]:([/noparse]
On the Win 98SE front, it appears to be working, but without any
means of serial port enumeration it doesn't get a port and cannot
be accessed. I cannot find any enumerator ( serenum.sys ) for
98SE, and I don't know how to access USB devices through VB6
or anything else. No serious complaint as 98SE is 'dead and buried'
in most respect but good to know it is fundamentally compatible
with it.
I kinda figured the cog speed thing was hardcoded. I've got a bunch of spare 6Mhz crystals that I use in my sumobot kit.
Unfortunately I had the kids all solder in their crystals (now I wish I'd used a socket). I'd be more than willing to send you some.
I'd also be very interested in instructions on modifying the kernel sources. I've never done before but what better time to learn than now.
Thanks,
Chad
I've compiled so many kernels I just forget the feeling of it all being new to me..
I'll see if I can locate a 6Mhz crystal locally.. snail mail takes at least 2 weeks to get to me from anywhere on the planet pretty much.
@hippy. I seriously feel for you. I fought Win2k for a not insignificant period before extending my middle finger to it and doing a clean XP install to be able to test this thing.
Win98 will never work, they just did not have a CDC-ACM driver in that OS. Hell, they had only just figured out how to enumerate a mouse..
Now I have it working in Win2k, for every different port or hub port I stick this thing in, the OS asks me to insert the Windows disk so it can install the driver for it. How freakin' thick is this OS?
Now, I have 10 different USB serial ports installed. The numbering changes every time I stick it in a different port! ARGH! XP is not much better..
I still have a spare endpoint pair in this low level stack.. I'm gonna have a try at a dual-port model (and maybe if I can bend the standard a little, a 3 port model!) in the next week or two.
I just found a couple of old 10K pots lying about.. I can see a USB HID joystick in my future.. (can anyone say steering wheel and throttle? OH YEAH!)
I really appreciate you guys testing this stuff.. nothing worse than "it works for me, must be your problem" when trying to develop software.
hippy, did you at least get the California Dreamin' keyboard emulation to work?
Yes, under XP. Got the lyrics typed up into an open copy of Notepad so I'll call that definitely success
I then blew it by unplugging / resetting which caused XP to think I've got an 'Unknown Device" which
it won't let me flush. Edited the PID and it's now being recognised but haven't managed to get it
typing anything
One thought on the serial issue is that I'm dual booting so Windows isn't on C:\ which could be a problem,
or something within layout.inf isn't as expected or is looking in the wrong place and not finding what
should be there. I'll keep prodding and seeing if I can come up with anything.
Don't get distracted or bogged down over my problems but keep tearing ahead with other USB offerings.
I'm just sorry I'm not able to be giving you or anyone else much help.
I'll have a look round for Microchip and other CDC drivers / applications and see if I can make them
sing. I've learned more about USB in the last 24 hours than since it was invented. Thanks for the
inspiration.
The California Dreamin' code should type a copy each time you press Caps/Num/Scroll Lock.. it looks for the LED change state message and triggers.
USB is kinda fun.. it was a drudge at first.. and I still hate writing descriptors, but overall I'm having a ball now.. Now I've got the low level cog stuff sorted, the app level is a doddle..
Abstraction rules (especially when it makes things _faster_ rather than the alternative).
Bugger. But at least another factor taken out of the equation.
Re-burnt the Eeprom using the original PID, unplugged the PropPlug, plugged in the 'Keyboard'
USB, hit NumsLock and bingo, worked first time. Press again, and more joy. Think a re-boot
fixed whatever was wrong on that count, although I also suspect that the PropPlug plugged in
at boot-up was having some adverse effect.
Can you update the USB_LowLevel_XXX.spin so the Start method imports the pin numbers as
parameters ...
And likewise USB_Serial_XXX.spin and future higher level drivers so we can
choose our own I/O assignments. Thanks in anticipation.
www.sourcequest.com/download/suplog.htm -
Ignore the download link in the page, just go up a level to -
http://www.sourcequest.com/download/suplog.htm
Attached is the best trace I've managed to get of what's going on or
not going on as the case may be.
The failure is in the last few lines, and interesting issues are the fails at
01:51:12.843 and particularly 01:51:18.953. Maybe someone can hazard
a guess as to what's going on. I suspect it's Windows re-install time.
On the plus side, I'm learning lots about Windows which I never knew.
I'm running Ubuntu 7.04 on my Mac Mini. It's running a 2.6.20-16-generic stock Ubuntu kernel image.
This *may* cause any linux-restricted-modules drivers you are using to stop working, Atheros wireless and stuff like that.. you've been warned.
This process took almost 3G of space on my machine, so it's pretty disk hungry too.
Ok, here is how I did it.
grab usb.patch.txt and save it to your home directory. ~/
sudo apt-get install build-essential kernel-package gcc bin86 linux-source fakeroot
mkdir kernel
cd kernel
tar -xjf /usr/src/linux-source-2.6.20.tar.bz2
cd linux-source-2.6.20
cat ~/usb.patch.txt | patch -p1
cp /boot/config-2.6.20-16-generic .config
fakeroot make-kpkg -initrd --append-to-version=bkc0.1 linux_image
<wait, wait, make coffee, drink coffee before it gets cold, wait, go out for a nice Italian meal, wait some more>
Seriously, this stock kernel compiles world+dog, it takes _forever_... (and I'm on a 1.8G dual core with 2GB of ram!)
cd ..
sudo dpkg -i linux-image-2.6.20.3-ubuntu1bkc0.1_2.6.20-16.31_i386.deb
<reboot into the new kernel> - Make sure you select it in grub, it may not be the default selection (it was here)
[noparse][[/noparse] 71.640000] usb 3-1: new low speed USB device using uhci_hcd and address 2
[noparse][[/noparse] 71.820000] usb 3-1: configuration #1 chosen from 1 choice
[noparse][[/noparse] 71.972000] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
[noparse][[/noparse] 71.980000] usbcore: registered new interface driver cdc_acm
[noparse][[/noparse] 71.980000] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters
brad@bkmac:~$ stty -F /dev/ttyACM0 -echo ; cat /dev/ttyACM0 & sleep 1 ; echo " Hello There " > /dev/ttyACM0 ; sleep 1 ; killall cat
+ Terminated cat /dev/ttyACM0
5970
Hello There
Cookin' with gas!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
everything is working as it should have from the off.
There is the end all solution to windows problems.. re-install..
Wish it could have been otherwise, but yes the news is very welcome thanks [noparse]:)[/noparse]
I'm making the mods you suggested and working on a 96Mhz version of the lowlevel cog also.. should have something in a day or so.
terminal emulator application ( VB6 via MScomm32 ) and the old
Terminal.exe from Win 95 days, after holding down a character to
send repeatedly the Propeller simply 'stops responding' and eventually
Windows plays its 'device gone away' tune.
This is with a simple Spin echo loop, but also with a simple number
printing loop ( no receive ) sending every 500mS ...
repeat usb.tx("<") usb.tx( usb.rx ) usb.tx(">")Printing numbers is a bit hit and miss. Most times it fails, but some
times seems to keep going. When it does fail, I note that the blue
Led on the PropPlug is flashed ( not connected to anything ) whether
Propeller Tool is running or not.
If not, can you send me a copy of your terminal program?
The blue led is the receive led isn't it? How could that possibly be triggered from the prop I wonder?
That routine stretches us right out to the timing limits of the USB controller
With both #crc16check removed it seemed stable.
I call PUB Start, delay 20 secs then send every 500mS. That allows the Propeller to be powered up, Windows to go 'Bing-Bong", and the associated COM port to be available for HyperTerm when loaded.
I noticed another effect; sending from Propeller only, characters sent to it via HyperTerm which the Propeller doesn't even try and receive causes transmission to stall for a while but does often recover, send too much and XP grinds to a halt, 100% CPU utilisation
see what I can trim down to speed things up. It does work on all my machines here, but I do know I'm stretching the timing right to the ragged edge of the spec.
I'll try some tests on the other stuff.. I assume you mean you get the prop to send data to XP without hyperterminal open and things get ugly?
Also nasty things happen when you send data to the prop from hyperterminal and you are not calling usb.rx on the prop?
Maybe windows has ugly issues with flow control. I don't see this problems on MacOS or Linux.. (there's a surprise)
Will have a play, thanks for the detailed feedback and testing, I really appreciate it.