PDA

View Full Version : USB toys to play with



BradC
09-16-2007, 12:33 AM
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)..
No data corruption, my testing methodology was flawed and I was losing the last 8 bytes due to a premature pipe flush.

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

BradC
09-16-2007, 02:29 PM
brad@bklaptop2:/tracks$ 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=120M count=1 ; sync ; cat /dev/ttyACM0 | pipebench -b 128 > test.2 & sleep 1 ; sleep 1 ; cat test.1 > /dev/ttyACM0 ; sleep 10 ; killall cat ; sleep 5 ; sync ; echo; echo ; echo ; md5sum test.1 test.2
7392
rm: cannot remove `test.1': No such file or directory
rm: cannot remove `test.2': No such file or directory
+ Terminated cat /dev/ttyACM0
1+0 records in
1+0 records out
125829120 bytes (126 MB) copied, 64.4303 seconds, 2.0 MB/s
7645
Summary:
Piped 120.00 MB in 04h55m36.98s: 6.92 kB/second
+ Done cat /dev/ttyACM0 | pipebench -b 128 >test.2



cef991981077266e84300515e6557294 test.1
cef991981077266e84300515e6557294 test.2




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

Baggers
09-16-2007, 08:18 PM
Cheers BradC,
Not had chance to play yet, but once I get some spare time, I will, as this is interesting stuff.
Well done matey.

Baggers.

Sten
09-16-2007, 08:27 PM
Hello Brad

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... http://forums.parallax.com/images/smilies/smile.gif

Nik

BradC
09-16-2007, 08:38 PM
I've been thinking about that Sten, in fact I just had my head in the spec looking at the boot protocol requirements for keyboard/mouse.
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.

hippy
09-17-2007, 02:58 AM
I'm suffering some woes ( understatement of the day ! ) trying to get the drivers installed.

According to www.recursion.jp/avrcdc (http://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 ?

BradC
09-17-2007, 03:12 AM
Nah.. I had *major* with a capital "M" problems .. like I never even got it to work on Win2k.. so I installed XP-SP2 in a spare partition and that *did* work..

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..

BradC
09-17-2007, 03:13 AM
You *could* try incrementing the PID in both the INF file and the .spin file and see if it works from scratch...

[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..
[\edit]

Post Edited (BradC) : 9/16/2007 8:54:51 PM GMT

hippy
09-17-2007, 04:16 AM
BradC said...
Sorry for the hassle.


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 http://forums.parallax.com/images/smilies/smile.gif

BradC
09-17-2007, 04:32 AM
Win2k has exposed a weird race condition with reset handling where the lowlevel and app code would end up doing something odd..
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..

BradC
09-17-2007, 05:52 AM
Only in windows.. sheesh....

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

Chad George
09-17-2007, 10:10 PM
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


usb 5-1: new low speed USB device using uhci_hcd and address 2
[10288.624000] usb 5-1: device descriptor read/64, error -84
[10288.908000] usb 5-1: configuration #1 chosen from 1 choice
[10289.344000] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
[10289.348000] usbcore: registered new interface driver cdc_acm
[10289.348000] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters




After unplugging and replugging I get a little less info



USB disconnect, address 2
[10725.100000] usb 5-1: new low speed USB device using uhci_hcd and address 3
[10725.280000] usb 5-1: configuration #1 chosen from 1 choice
[10725.284000] cdc_acm 5-1:1.0: ttyACM0: USB ACM device




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

BradC
09-17-2007, 10:37 PM
Heya Chad, nice to hear it works for you!

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.

hippy
09-17-2007, 11:00 PM
Chad George said...
I managed to get it to work on a propeller using a 5Mhz crystal under Windows XP with absolutely no problems.


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 :(

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.

Chad George
09-17-2007, 11:03 PM
Brad,

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

BradC
09-18-2007, 03:27 AM
@Chad, I'm currently running through the Ubuntu build process to jot down some notes and try and make it easy.
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?

hippy
09-18-2007, 04:31 AM
BradC said...
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 http://forums.parallax.com/images/smilies/wink.gif

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.

BradC
09-18-2007, 04:47 AM
Nah, My Xp install is on E:\ and 2k is on C:\. When I boot into XP it still got it right... next

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).

hippy
09-18-2007, 05:14 AM
BradC said...
Nah, My Xp install is on E:\ and 2k is on C:\. When I boot into XP it still got it
right... next


Bugger. But at least another factor taken out of the equation.


BradC said...
The California Dreamin' code should type a copy each time you press
Caps/Num/Scroll Lock.


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.

hippy
09-18-2007, 07:08 AM
Feature request time ... you knew it would happen, but should be an easy one ...

Can you update the USB_LowLevel_XXX.spin so the Start method imports the pin numbers as
parameters ...



PUB Start(crctable, buffers,dminuspin,dpluspin,enablepin) : OK | i
Pcrcmask := crctable
epb := buffers
K := |< dpluspin ' D+ ( was Pin 1 )
J := |< dminuspin ' D- ( was Pin 0 )
Enable := |< enablepin ' En ( was Pin 2 )
OK := cognew(@USB_STACK, 0)



And likewise USB_Serial_XXX.spin and future higher level drivers so we can
choose our own I/O assignments. Thanks in anticipation.

hippy
09-18-2007, 08:16 AM
Okay, I'm still bashing away and discovered SetupAPILogger here -
www.sourcequest.com/download/suplog.htm (http://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.

hippy
09-18-2007, 08:38 AM
Plus some good news ... California Dreamin' worked fine under Win 98SE.

BradC
09-18-2007, 09:40 PM
Ubuntu Kernel re-compile howto. Best of luck Chad.

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)

[ 71.640000] usb 3-1: new low speed USB device using uhci_hcd and address 2
[ 71.820000] usb 3-1: configuration #1 chosen from 1 choice
[ 71.972000] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
[ 71.980000] usbcore: registered new interface driver cdc_acm
[ 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
09-19-2007, 02:41 AM
Kill all cat? that's not a very nice thing to do, but at least you were well rested before you did it http://forums.parallax.com/images/smilies/tongue.gif .

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

hippy
09-19-2007, 03:01 AM
@ BradC : Finally, some very good and welcome news - After a re-install of XP,
everything is working as it should have from the off.

BradC
09-19-2007, 03:43 AM
YAY! (cheers, waves, fireworks, bunting)

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 :)

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.

hippy
09-19-2007, 11:42 PM
@ BradC : Having some problems under Windows XP. Using my own
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.

BradC
09-20-2007, 12:01 AM
Is it reproducible in hyperterminal?
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?

BradC
09-20-2007, 12:21 AM
Just for kicks, comment out the call #crc16check in pid_data0 and pid_data1 in USB_lowlevel and see what happens.
That routine stretches us right out to the timing limits of the USB controller

hippy
09-20-2007, 01:14 AM
Repeatable in HyperTerm, seems to occur when opening other applications and browsing, perhaps something putting a strain on the system ?

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 http://forums.parallax.com/images/smilies/smile.gif

BradC
09-20-2007, 01:45 AM
Right.. your system seems to be on the edge of the timing limits.. all the other soft-usb implementations ignore the CRC check and just assume it's all good.. I'll have to look closer and
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.

hippy
09-20-2007, 01:58 AM
BradC said...
I assume you mean you get the prop to send data to XP without hyperterminal open and things get ugly?


No, the Prop is only sending when HyperTerm is open. I spoke too soon earlier; still getting sending stopping even with crc checks removed when not touching anything.


BradC said...
Also nasty things happen when you send data to the prop from hyperterminal and you are not calling usb.rx on the prop?


Yes, that's correct.


BradC said...
Will have a play, thanks for the detailed feedback and testing, I really appreciate it.


No problem, I'd like to see it working as much ( perhaps more so on Windows ? ) as you do http://forums.parallax.com/images/smilies/smile.gif

BradC
09-20-2007, 03:04 AM
Can you send me your main spin routine and a detailed set of steps to reproduce it? I'd love to see it fail here. (There's setting myself up for a fall!)

In any case, I've shaved 3 bit times off the receive data routine (which is about 1/3 the time taken to calculate the CRC).. so that was a prod in the right direction even if it won't immediately help you.
I now write the data to the hub while sending the EOP of the ack packet, rather than writing it all out and then starting to send the ack.. Brings us closer to the spec anyway.

hippy
09-20-2007, 09:05 AM
BradC said...
Can you send me your main spin routine and a detailed set of steps to reproduce it? I'd love to see it fail here. (There's setting myself up for a fall!)


It's not far off your own original USB Demo code. Running the 'send only' routine and typing back characters to the Propeller which never does an rx call, it's after the 33rd character sent there's a stall. Suspiciously near the $1F buffer size, but I haven't investigated your code in too much detail.

Test process ( assuming VID/PID already has a device driver ) ...

Unplug USB.
Burn the code.
Switch off Protoboard.
Unplug PropPlug.

Power up Protoboard.
Wait ~ 4 seconds, plug in USB.
Wait for "Bing-Bong" device detected sound ( Thanks Bill, my XP has now stopped giving that )
Launch HyperTerm, select previously saved 'Use COM4.ht' which is what I have it as.
Wait ~ 15 seconds, displays "0 1 2 3 4" etc
Type "a" 32 times, should keep counting
Type "a" 33rd time and output stalls, wait and it starts up again.

Type "a" 32 times, should keep counting
Type "a" 33rd time and output stalls
Keep finger on the "a" key for auto-repeat and Windows grinds to a halt.

Good luck in making it fail - fingers crossed that it will !

BradC
09-20-2007, 02:25 PM
Ok, that is expected behaviour and I can reproduce it using linux also.

What is happening is hyperterm (or whatever) is trying to send data, the send blocks waiting for space in the transmit buffer (in the OS) to become available. Hyperterminal obviously has a transmit timeout
and after each character times out as not being able to be sent, it goes back to receiving data (the recovery you noted).. notice no break in the number sequence, it just dumps the queued up buffers in as quickly as possible.

Using minicom under linux, it never recovers (as minicom waits forever for space to become available).

This is normal unfortunately. Not a bug, but a "feature". My copy of XP and hyperterm does not go to 100% CPU under any circumstances and windows does not even blink, but I can see how a program might
do that if it's busy looping waiting for buffer space to become available. Solution of course is to intermittently check to see if there is data to receive and just discard it. If you think about it, using RS232 or
similar, the data gets spat out the port whether you are listening for it or not. Maybe my build of XP or hyperterminal is a little more intelligent in the way it copes with a blocked buffer.

...Further testing.. it does make Hyperterminal very slow to respond and laggy while it's trying to send.. once the send times out (takes a while) then it all returns to normal.

Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158)

I've tested with and without the prop-plug connected and I don't notice any difference (as I guess I shouldn't)

I can reproduce exactly your symptoms as described above, but when "Windows grinds to a halt" for you, hyperterminal grinds to a halt for me, windows stays responsive. Hyperterminal then recovers (after anywhere up to 60-90 seconds) and just picks up where it left off.

I can't reproduce the loss of comms errors though. That is perplexing me. I've got 3 different cardbus USB cards (OHCI/EHCI), plus the built in port in the laptop (UHCI), plus the Mac (UHCI/EHCI) and my other laptop (UHCI/EHCI) and it just works flawlessly with all of them. I've even tried it on my server (which is a VIA chipset and prone to bugs).

Did it seem to get more reliable when you commented out the crc16check or was that just an oddity of the test?

I've left it running here and the count has just cracked 4600. I stall it from time to time by holding down a key until it latches up, but it always recovers and picks up where it left off.
Wanna mail me your computer for a week?? ;)

Actually, on that. What _is_ your hardware? Mainboard, chipset and PCI ID's for the USB controller?
Maybe I can scrounge up something locally to reproduce the failure.

BradC
09-20-2007, 08:20 PM
Quick question. Do you perchance have a USB keyboard and/or mouse and are they plugged into the same USB bus segment?
Just found a major oopsie where we were receiving ACK packets that were destined for a USB keyboard or mouse (or any other low speed device on that segment), causing major communication packet loss
between the Prop and PC.

Anything from just dropping packets through to enumeration failures... I, of course was always testing it on its own USB bus segment.. as soon as I plugged it into the HUB built into my Mac keyboard things
got real "interesting"

BradC
09-20-2007, 09:39 PM
Ok, I hope this is the last major revision coz I've well and truly run out of COG ram in the lowlevel routine.

This had 2 major bugs that prevented it from playing nicely with anything else on the same USB segment. Keyboard/Mouse was the first one, then I plugged it into the same
bus segment as my APC HID/UPS and all hell broke loose. This has passed all regression tests and I can't fault it here. Hopefully it'll solve your problems too :)

I had uploaded a half fixed version, but luckily nobody had downloaded a copy when I found the last (I hope) bug, so here is a complete package with the latest code.

hippy
09-20-2007, 10:02 PM
BradC said...
What is happening is hyperterm (or whatever) is trying to send data, the send blocks waiting for space in the transmit buffer (in the OS) to become available.


So does the Propeller USB stack always ask for data, or is data sent from the Host and a 'buffer now full' / 'sorry, buffer is full, could not accept data' reply cause the stalling ?

I'm guessing the later because 'rx' and 'rxcheck' do not kick anything to provoke the host into sending data ( or that's handled at the lower level whenever the buffer is not full ). Hence 32 bytes fill the Propeller buffer, then the 33rd does not get accepted, HyperTerm goes to the Land of Nod.

In effect -- The host does stream data out while it can, and then stalls when the Propeller indicates, "now hold on, we have not dealt with the last stuff sent" ? If that's so, it would be possible to have the Propeller USB stack throw away incoming data if the buffer were full and there would consequently be no stalling ( accepting that data would be lost forever ) ? This is not something I'm asking to be implemented, but would probably suit my application.

I'm afraid I'm only slowly getting up to speed on USB - fascinating stuff, and your code has been really beneficial to understanding what's going on, but it hasn't all sunk in yet. Never, ever dreamed I'd be doing anything with bit-banged USB or USB stacks !


BradC said...
Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158)

Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_rtm.040803-2158 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158) - Same as yours


BradC said...
What _is_ your hardware? Mainboard, chipset and PCI ID's for the USB controller? Maybe I can scrounge up something locally to reproduce the failure.


If I've not given the information you need, just let me know, Win XP innards are as new to me as USB is ...

Celeron 1GHz + 384MB
GA-6VEM motherboard ( GigaByte ) and according to manual ...
Chipset : VT8601T HOST/AGP/Controller + VT82C686B
I/O Control : VT82C686B

And it does look like VIA USB controllers, both USB 1.1 I believe. I have a "motherboard_drivers_chipset_via_4in1433v.exe" on disk which I am sure I had previously installed, but forgot to when I did the re-install a day ago ...

"USB Root Hub" ( two off )

Device Instance Id :
USB\ROOT_HUB\4&1E8F7657&0

Hardware Ids :
USB\ROOT_HUB&VID1106&PID3038&REV001A
USB\ROOT_HUB&VID1106&PID3038
USB\ROOT_HUB

Matching Device Id :
usb\root_hub

Service :
usbhub

"VIA Rev 5 or Later USB Universal Host Controller" ( two off )

Device Instance Id :
PCI\VEN_1106&DEV_3038&SUBSYS_12340925&REV_1A\3&61AAA01&0&3A

Hardware Ids :
PCI\VEN_1106&DEV_3038&SUBSYS_12340925&REV_1A
PCI\VEN_1106&DEV_3038&SUBSYS_12340925
PCI\VEN_1106&DEV_3038&CC_0C0300
PCI\VEN_1106&DEV_3038&CC_0C03

Matching Device Id :
pci\ven_1106&dev_3038&cc_0c0300

Service :
usbuhci


BradC said...
Quick question. Do you perchance have a USB keyboard and/or mouse and are they plugged into the same USB bus segment?"

No, both are traditional PS/2, so my turn for a "...next" retort http://forums.parallax.com/images/smilies/smile.gif http://forums.parallax.com/images/smilies/smile.gif

I only have one pair of USB ports exposed on sockets so everything on the same Host Hub / Segment; FTDI PropPlug on one, Propeller USB on the other. No passive / active hubs used.

I'll try your latest USB_002 and see how that affects things. I'll then also run the "VIA 4 in 1" chipset driver install and see if that does anything to help.

Many thanks for taking the time to look into this and helping someone who is pretty much still stumbling around in the dark, but the light's getting brighter !

BradC
09-20-2007, 10:14 PM
Ok.. what happens with the CDC-ACM driver is this..
Hyperterminal places a byte in the windows transmit buffer. Windows queues up an OUT packet with that byte in it (or up to 8 bytes depending on what is available).
If the prop has buffer space available, it processes the OUT packet and sends an ACK, to let windows know it's all good.
If it does _not_ have buffer space available it sends a NAK, which says to windows.. I'm busy right now and have no way to process that packet, try me again soon.
It will continue to try for all intents and purposes forever sending an OUT and getting a NAK. This is where windows is chucking a wobbly. Your understanding is good young Jedi!

Yes, it would not be terribly difficult to have the app level routine say, buffer full.. have not had space available for 2 seconds, let's chuck the packet away.
I've not done it this way as I built the whole thing from the ground up _not_ to lose _any_ data _ever_.. but I could probably add a timeout there that you can set as an option to allow it to chuck data away.
The easy way though is in your app, just periodically call usb.rxcheck and that will read data from the buffer if there is any to read and just toss it away if you don't do anything with it.
It also won't block if there is nothing to read.

I've been thinking about a timeout in the tx routine also.. as for example in my thermostat, if the PC stops or minicom dies or anything happens that stops the PC pulling data from the prop,
then the main routine will stall on the tx() and my AC will never change state (not pretty).. but I've got to think about the best way to do that without getting to complex or ugly.
Was thinking of a timeout in the tx() spin routine itself..

Bummer about the no usb keyboard or mouse.. I'm rapidly running out of ideas...
I do have an old machine here somewhere with a VT82C686 on it though, so I'll dig it out and see if I can reproduce some of the problems you are seeing.
It's an _old_ machine.. I wonder if WinXp will install in 32MB of ram?? ;)

hippy
09-20-2007, 10:44 PM
@ BradC : Once again, many thanks for the explanations. The fog thinning it is.

timeouts : I wouldn't really need them. I suspect others would be more interested in seeing other USB device classes coded up than getting bogged down in tweaking the interfaces. Hope I haven't side-tracked you too much already.

Win Xp : I think it needs 64MB minimum.

BradC
09-20-2007, 10:45 PM
Paul Baker (Parallax) said...
Kill all cat? that's not a very nice thing to do, but at least you were well rested before you did it http://forums.parallax.com/images/smilies/tongue.gif .


I always sleep well prior to feline abuse, better after however :)

It's funny, I guess I'm so used to the command line syntax I just never think about what I'm actually typing.
I recall a very offended blonde secretary who took great offence to receiving mail from root.

There's a number in every crowd..

BradC
09-21-2007, 02:05 AM
hippy said...
@ BradC : Once again, many thanks for the explanations. The fog thinning it is.

timeouts : I wouldn't really need them. I suspect others would be more interested in seeing other USB device classes coded up than getting bogged down in tweaking the interfaces. Hope I haven't side-tracked you too much already.

Win Xp : I think it needs 64MB minimum.


Hrm.. I'm more interested in getting the bugs beaten out of the low level driver before working on new classes and objects..
Once the low level driver is working solidly then we have a decent foundation to build upon.

As to being side tracked.. I'd rather spend time getting it _right_ first, then we can look at adding features http://forums.parallax.com/images/smilies/smile.gif
I don't mind being side tracked if it helps get things working smoothly.. in any case.. I've only spent some time writing/tweaking code, it's *you* who completely re-installed windows! Who's sidetracked?? http://forums.parallax.com/images/smilies/tongue.gif

I've managed to scrape another 14 longs free in the low level code with some nasty hacks/tweaks.. and I've located a 6Mhz resonator in an old board I had floating around, so I'll look
at building a lowlevel variant to run at 96Mhz tomorrow as well.

I really do appreciate all the time you've put into this..

I'm having fun anyway..

hippy
09-21-2007, 02:13 AM
Added : Our posts crossed in the ether ... I'm not baling out, just needing a bit of a break http://forums.parallax.com/images/smilies/smile.gif

Okay ... where we currently stand, having tried lots of things and various combinations. This is with USB_Serial_004 and USB_LowLevel_007, only Prop USB connected, PropPlug unplugged from USB, no apps running other than HyperTerm.

With the Propeller doing send only and nothing being sent its way to stall transmission, comms stays up from between 5 seconds and 15 minutes, usually lasting around 5 to 10 minutes before it just stops, and that appears always to always be after the first character of the number I'm displaying ( the first byte sent after a 500mS delay ) is shown by HyperTerm.

Installed Bus Hound from Perisoft and that showed interesting things, but not as to how the failure arises or events surrounding it. It appears though that when the Prop USB goes down WinXP starts a USB enumeration again of some kind. Every minute or so it reports something different to the previous commands, but I didn't understand what ( STAK:READ event data changes ). I'm not sure if failures are related/synchronised to this or not.

I also now suspect that the blue (Tx) Led flashing on the PropPlug may be WinXP searching unopened serial ports to find new modems or something like that, but didn't investigate. It only happens after the Prop USB has died.

I'm going to put this to one side for a while, but will almost certainly come back to it. If anyone else could give this an endurance test to see how long it stays up for it would confirm that it's something with my PC or setup not a general problem.

The only other thought I have is that it could be mains borne interference or electrical noise. I'll try running my ProtoBoard from a 12V SLA and see how that does.

BradC
09-21-2007, 02:26 AM
Ok, I've fired up an XP machine, I'm running an identical configuration now.. I'll let it run overnight and see what happens..

I doubt it's mains, but then I've been wrong once or twice before.. I guess when you get to this point anything is possible..

BradC
09-21-2007, 03:51 AM
I was completely out of ideas, until I remember that VIA controllers had a bug with Babble.. (sending more bytes than they should) .. did a bit of source digging and googling and the early UHCI VIA silicon
turns out to be quite buggy.

This is one error condition I don't check for, and if we get more than 12 bytes (token + 8 + 2 for crc is max we _should_ get) then we will start overwriting ram and things
go south.. I've got to really think about this a bit as I can't actually make it happen, but I need to test the check for it properly..

Anyway, looks like the VIA silicon I have here is newer than what you are running.. I'll let it run tonight and see what happens, if I can't get it to lock up I have an old K6-II 300 on a Via 86C586 chipset that I'll break
out and try an XP install on.. they don't get much older than that with USB anyway. XP on an original ISA Monochrome VGA card with 32 MB of ram.. I can see this being fun...

Lucky Friday is my weekend..

Chad George
09-21-2007, 07:08 PM
Brad,

Great walk-through on recompiling the ubuntu kernel. Worked perfectly. Although as you mentioned I did lose my restricted drivers stuff.
Rebuilt the nvidia drivers ok. VMWare still doesn't work, but hopefully a reinstall will fix that too. Wireless works ok still.

And the USB driver seems to work too. cool.

BTW, I tried to run it in a WindowsXP virtual machine (linux as host) and it recognized and installed the driver ok. I thought maybe this would
get around needing to recompile the kernel but no luck. It didn't error out or anything, but when windows tried to write to the port the transmit
would just hang in the tx buffer. I'll try it again once I get VMWare back up and running.

EDIT: one more thing...
I saw it mentioned (maybe in the code don't remember) that there was the possibility for a new linux driver that doesn't require a kernel rebuild.
What is involved in getting this to work? Even after doing it myself, I think a kernel rebuild (and everything that subsequently breaks) is a little
much to ask for a long term solution.


-Chad

Post Edited (Chad George) : 9/21/2007 12:15:42 PM GMT

BradC
09-21-2007, 08:20 PM
Heya Chad, you can run Windows in a VM and use the USB serial port, but only _after_ you have patched the linux kernel.

As for the no-patching thing.. it's kinda in-progress, but will not hit mainline for another revision or two, so you won't see it in a distribution for probably 6 months.. so there is a long term solution in the works..
A re-install of VMware shoule re-compile the kernel module and you should be good to go.
I use Virtualbox, and a simple /etc/init.d/vboxdrv setup - and I was back on line.

@hippy.. I've managed to reproduce what I _think_ is your failure.. I've had it die 3 times now.. the problem is it takes a minimum of 2 hours, which makes debugging slow.. but we'll get there.
I could not get it to fail on my newer VIA based machine, so I loaded Win2k on my old VIA 586 based board with a huge 32MB of EDO ram.. the windows install alone took 3 hours.. *BUT* I can get it to fail!

Cheers lads!

hippy
09-21-2007, 08:40 PM
@ BradC : It's not often one gets to say, "It's failed, Yippee !"

Good luck with the bug hunt.

tom sparks
09-22-2007, 09:49 AM
have any of you tested it on a non PC based system
eg game console (gp2x [http://en.wikipedia.org/wiki/GP2X] has a USB host 1.1 mode)

BradC
09-22-2007, 05:52 PM
Short answer : no

Long answer : I don't own any kind of gaming console, and I'm head down chasing a _very_ annoying bug related to the low level driver right now which will likely take me a week or so.
Until I have that bug nailed I can't say how well it might work.

Once I've got that sorted, I'd be more than happy to knock something up you can use to test on a game console if you have one.

Alternatively, if you want to play with the existing code, go right ahead. It's 99.9% certain that the interface between the App level and low level code will remain stable for the
immediate future and you can always update to the latest low level code when I have it working properly.

What can you plug into a console anyway ?

tom sparks
09-23-2007, 08:00 AM
custom made data glove (http://en.wikipedia.org/wiki/Wired_glove)/ head tracking system / 1990's VR setup, etc
I currently dont own a Propeller chip/board :(

BradC
09-30-2007, 12:46 PM
Ok, I _think_ I have this pegged. It's taken a while (I took an entire week off to chase this down) and I now thoroughly detest Windows, its driver model and USB stack

New versions have an added parameter in the Start() routine to pace outbound packets to stop Windows crapping itself on old VIA chipsets.
Users of sane operating systems may leave pace==0 while VIA chipset users should set pace==1. In all reality, the measured throughput difference is small enough
to leave pace==1. (Almost so small as to be insignificant actually)

Also, lowlevel has now been broken into _80Mhz and _96Mhz versions. It's passed all my regression tests, but my 96Mhz version was developed with a resonator pulled
from an old board with leads tacked onto it.. so if it does not work for you, let me know and I'll source a crystal to test with..

(Why do I get this horrible feeling that as soon as I press the Submit button the bug will re-surface on my test rig??)

Read on for a long winded description of the Windows bug

PS. Hyperterminal's connection time counter wraps at 24 hrs..

<snip>

Windows does strange stuff with old VIA controllers.
Devices will enumerate properly and run until they lock up.

In the process of recovering, the root hub stops separating commands between the ports, and
windows confuses the devices with simultaneous resets and enumeration commands, which prevents
successful re-enumeration of the Propeller (and sometimes everything else plugged into that bus).

This does not appears to occur on later silicon VIA chips. (Or is far less frequent) And I've not seen
it at all using Intel chips.

I've tested this on Rev $02, Rev $61, Rev $80 and Rev $81 of the via 3038:1106 USB controllers.

I've used different hubs, different configurations of ports and different controllers.
Thus far, I've spent about 90 hours chasing this bug and I think I finally have it pegged.
In the process I had to build a low-speed USB bus analyser so I could actually watch the bits
on the wire, which was a learning experience in itself.

Low-Speed BULK violates the USB spec, pure and simple. Linux by default prevents this on UHCI
controllers and has to be patched to allow it to occur, but Linux on exactly the same hardware listed
above behaves perfectly in every respect for as long as I care to test.

Windows appears to choke intermittently when receiving bulk packets in response to IN tokens.
It *always* happens on the second consecutive data packet. Windows will recieve the 1st packet
successfully, then it will delay the next IN token quite significantly. It will receive and sometimes
ACK the second packet, then it will just stop polling the bus (sending IN tokens). 300-330ms later
it will complain loudly that the device has stopped responding (when in reality it's stopped asking
for a response!). At this time, it confuses the root hub such that when it tries to reset and
re-enumerate the device, anything else on that bus will also get confused and start colliding.

Nasty stuff.


The Rev $02 controller is the worst.. it locks up anywhere between 5 mins and 5 hours into a test run.
It seems to get progressively better from there on, and I've only seen one un-reproducible lockup
on a Rev $80 and Rev $81 device.



At this point, I *think* the way to work around the problem is not to send consecutive data packets.
I've built packet pacing into the low level stack which can be enabled by setting the "par" in coginit
to anything other than zero. The driver will make the required changes on bootup. This will reduce
the throughput of the device, however it does appear to stop it locking up on Windows with VIA chipsets.



Now, why did I not detect this during the initial development? Well, firstly my limited Windows testing
was done on an old Intel chipset based laptop. Secondly, my test case involved pumping masses of
data through the propeller in both directions. My theory on this is that each packet of data leaving the
propeller was paced by a packet of data entering the propeller. The test devised by Hippy simply involved
outbound packets. Due to the speed "limitations" involved with using a SPIN routine to feed the buffer, a
simple usb.dec(12345) is slow enough that the usb system will send a packet with a "1" in it, then possibly
another with "23" then "45", and it will do this in three consecutive packets. This is where it was locking up.


Interestingly enough, VIA has a patch for this particular scenario available on their website (lockup while
transfering large amounts of data), however it would not install on my main affected machine (something
to do with being unable to modify an .inf file). I suspect this would also affect Full-Speed transfers under
the same conditions, but have no way of reliably testing that theory as I don't possess a Full-Speed bus analyser.


I will note installing the Via 4-in-1 chipset drivers appeared to make the situation slightly harder to trigger,
however it still hits.

Best of luck

hippy
09-30-2007, 04:30 PM
@ BradC : Many thanks for putting so much time into this. It really is appreciated, and especially when it's not a bug on your part.

Your analysis makes sense and the chaos on recovery after failure fits with my observations of other USB devices getting 'shaken up' after the link went dead. That my tests were sometimes failing incredibly quickly is probably an issue of OS / Driver timing with my particular PC.

I haven't looked at the new code yet but presume that pacing involves replying to an IN then waiting for Windows / VIA to have asked for another before sending another. I don't see that as a problem for myself and an acceptable price to have to pay.

I'll upgrade to the new USB object, run my tests again and let you know how I get on.

BradC
09-30-2007, 04:57 PM
Actually.. it kinda works like this....

USB being a master/slave bus, the device *never* speaks unless it's asked to by the controller. So Windows sends an IN. If we have data to send, we send the data.. if not we send a NAK

Previously.. It would go like this..

IN | Nak
IN | DATA | ACK
IN | DATA
<Lockup>

Now we do
IN | NAK
IN | DATA | ACK
IN | NAK
IN | DATA | ACK
IN | NAK
IN | DATA | ACK

and so on.. in all reality, my tests here for raw speed really don't show any loss in throughput.. I still get about 7k/sec.
The reality is most of the holdup is in the serial high level cog, so we do tend to skip IN packets anyway when it's under load.
I'll look at a more intelligent algorithm at some point in the near future and probably make it the default.

I've just had a lightbulb moment, and managed to shave another instruction out of each component of the RX loop. enough so I can now time the rx loop with waitcnt rather than nops..
this means I've got it auto-switching to cope with 5/6Mhz crystals.. It detects the clock speed at cog init time and configures itself accordingly.. so there will be a new lowlevel update in the
next day or so I suspect. No functional changes to do with any other part of the system though. Hopefully means Chad can use it on his bots now.

Using my serial loopback benchmark, I get a good 7kb/sec at 80Mhz, which increases to 7.6kb/sec at 96Mhz.. so the app level throughput is certainly a factor.

As you can see by the counts on hyperterminal in my desktop shot.. I've run each test for at least 24 hours continuously, so at least here.. it behaves itself now.

BradC
09-30-2007, 07:18 PM
Forgot to mention, the _other_ issue that hit me very hard on the VIA controller, is the pullup resistor must be 1.5k or less. 2.2k/3.3k was causing the propeller to bounce
on and off line.. which just confused Windows even further!

It's mentioned in the changelogs, but thought it best to make it bleedin' obvious as it took me 2 days to figure out what was going on.. frustrating..

hippy
10-01-2007, 08:55 AM
Okay had a chance to try the new release; unfortunately the news isn't as good as I had hoped it would be.

Firstly, can we clarify the hardware connections ...




N/C --< Vusb

___
P0 <>---|___|----.----<> D-
68R |
___ |
P1 <>---|___|----|----<> D+
68R |
___ |
P2 >----|___|----' .--> 0V
1K5 _|_


Correct Hardware Configuration




Edited : Circuit corrected as per BradC's posting below

Running with USB_Serial_005 and USB_LowLevel_80_008, with the new configuration, when I plug in the USB cable Windows brings up a USB icon in the Sysem Tray, and clicking on that shows an "Unknown Device". Using the earlier configuration the device connection is detected and it all works as before.

I'll admit I used a 1K2 not 1K5 because I don't have any 1K5. Is 1K2 plus 680R causing the problem ?

Anyway, with the latest software ( and pace := 1 ) but earlier hardware, results are about the same as before; HyperTerm shows nothing being transmitted after 800-1100 numbers displayed.

With your comment as to VIA not liking the 3K3 I'm not sure if the problem I have is related to that or something else. Any suggestions on moving forward ?

Post Edited (hippy) : 10/1/2007 12:50:01 PM GMT

BradC
10-01-2007, 12:23 PM
Ok, those are supposed to be 68Ohm 68, not 680. And the 1.5k connects to the D- side of the cable, not the prop pins.. that would certainly be causing issues..

I've re-read the .spin file and I can see how it looks like 680 as the O in ohm is hard up against the numbers 68Ohm. I'll change that.
I've used anything from 45 Ohm to 100 Ohm here and it works.. but 68 seems to be closest to the specs.

With a 680 and the 1.5k connected to the port pin you will be seeing random disconnects.. which is somewhat consistent with what you saw before.

I've used a 1.2k here with no problem.

If that fails, well then I've only got one wrist left....
http://forums.parallax.com/images/smilies/eyes.gif

Post Edited (BradC) : 10/1/2007 6:06:00 AM GMT

hippy
10-01-2007, 07:43 PM
BradC said...
Ok, those are supposed to be 68Ohm 68, not 680 ... I've re-read the .spin file and I can see how it looks like 680 as the O in ohm is hard up against the numbers 68Ohm. I'll change that.


I guess that's what "R" is for ( http://forums.parallax.com/images/smilies/smile.gif ) but I'll also accept dyslexia on my part. I also managed to sneak 680R through on an earlier circuit but with you being neck deep in nS timings and Windows detritus trying to fix bugs it's no surprise that one snuck through. I'll go back through the posts and correct the circuits. Then I'll re-do my hardware and have another go -- You're still on my virtual Christmas Card list.

On the plus side, if I hadn't ballsed-up so badly then I may never have had the problems I've encountered and the nasty buggettes with the VIA hardware and Windows may not have surfaced until much further down the line. There's a silver lining to be found in most things.

BradC
10-01-2007, 08:35 PM
Oh, look.. I literally spent 90 hours at the keyboard/breadboard chasing these bugs.

In the process I learned an awful lot about Windows (Or is that a lot about awful Windows) and it's abortion of a USB stack.

I flushed about 5 non-compliance bugs with the upper and lower level stacks, got to build a low-speed USB analyser and made the code more compliant and smaller
at the same time. All in all it's been a very productive bug hunt. If it does not fix it for you though, maybe it'd be cheaper if I just fedex'ed you a new mainboard/processor ;)

I _am_ having a swine of a time with the 96Mhz stack timings.. but that is due to the resonator I'm using being unstable rather than anything else.. I'll get myself a 6Mhz crystal
to test with which is bound to make it better.

I always postulate you never stop learning until you are 6 feet under.. this has been a fun chase, but man I hope it's over :)

Do very much appreciate the feedback though.. once we get this nailed and stable, I have some fun additions in the works..

hippy
10-01-2007, 09:26 PM
I've often found that the elation of success is entirely proportionate to the difficulty of getting there, but that doesn't mean there isn't a point where the pain outweighs the gain. From my own bug hunting marathons I know exactly where you're coming from when you say, "I hope it's all over".

hippy
10-02-2007, 07:28 AM
@ BradC : I think we're almost there. My test program ran for an unheard of length of time so I'm pretty certain you've got whatever was causing me problems beaten.

I say almost there because there's one particular issue I've got to overcome. As an object within my test code it's fine, but as an object within my real application ( modified to a send incrementing number loop after initialisation completes ), whereas the older code runs, this always stops after sending the first byte. That's regardless of pace setting. Weirdly the receive character / echo it back tests work and that involves multiple consecutive sends.

I haven't started pruning my application's code down nor really investigated further yet, but I will look into it. I don't think I'm trampling on any Hub memory during initialisations, so my gut feeling is some sort of alignment issue depending upon how/where the object ends up loaded. I cannot see any obvious alignment issues in the USB code, so it could be something with my code. I'll let you know how I get on, but I can now see a bright light at the end of the tunnel.

James Newman
10-02-2007, 09:06 AM
BradC> I haven't downloaded this, but I'm curious. How hard would it be for me to use this to setup a HID device with a few buttons, and a couple axises that would work pretty well on Linux? I'm wanting to basically build my own USB HID based gamepad. I've been looking into the usb stuff the last few days, and then I decided to look on the forum http://forums.parallax.com/images/smilies/tongue.gif. Also, you wouldn't, by any chance, be able to link me to some good information on all of this would ya? My first thought was to use a serial connection, and a program that used that and then communicated with PPJoy to do the gamepad stuff, but I would rather have something that would work on Linux too.

Thanks for any help.

BradC
10-02-2007, 10:08 AM
Good question James. The HID based joystick / gamepad is next on my list of things to play with. I've just not had a great deal of luck finding hardware to
plug it into :)

It would not be overly difficult to do. The hard part really is writing the HID descriptors and ensuring that Linux, MacOS and Windows can properly parse and validate them.
I can't really point you to any decent information other than the original USB HID document (and it's pretty cryptic if you've not done HID descriptors before).

There *was* some code floating around on the net from a guy who did a HID joystick using an AVR, but his site has been down for months and I never got a chance to see it.

BradC
10-02-2007, 10:19 AM
hippy said...
@ BradC : I think we're almost there. My test program ran for an unheard of length of time so I'm pretty certain you've got whatever was causing me problems beaten.

I say almost there because there's one particular issue I've got to overcome. As an object within my test code it's fine, but as an object within my real application ( modified to a send incrementing number loop after initialisation completes ), whereas the older code runs, this always stops after sending the first byte. That's regardless of pace setting. Weirdly the receive character / echo it back tests work and that involves multiple consecutive sends.



Just for giggles, try USB_Serial_004 with USB_lowlevel_008. They should work ok together (though you will have to add the pace bit in I think).

I've changed the way I handle enabling/disabling the transmit routine in the cog, maybe that has something to do with it. (It now follows the DTR state)

I'm almost smiling now.. let's see if we can get this last little bit licked..

hippy
10-02-2007, 07:51 PM
BradC said...
Just for giggles, try USB_Serial_004 with USB_lowlevel_008.

I'm almost smiling now.. let's see if we can get this last little bit licked..


Woo-Hoo http://forums.parallax.com/images/smilies/roll.gif

Went for the giggles, and with correcting the call to the low-level PUB start() it's dancing like it should be.

I think you've cracked it and can probably take the knife away from your second wrist.

BradC
10-02-2007, 08:33 PM
Ok, I'll make some changes to Serial to go back to the way I was running it before.. and I'll have a new serial/lowlevel out in the next couple of days..
It'll be fully compatible with what you have now, so no real changes there..

THANKS HIPPY!!!!!

Chad George
10-04-2007, 09:51 PM
I was able to confirm that there is something weird in version 005. Seems to work with Serial version 004 though.

I've been able to get both the 96Mhz and 80Mhz versions working. Although I haven't tested them extensively.

I'm now able to connect to my robot and at least echo characters to a terminal. Next I'll be writing a boot loader that can program the propeller via the USB serial object.

I did run into one weird problem. When my PropPlug is connected to the board at the same time as my USB cable the Propeller based USB connection keeps dropping and resetting. At first I thought it was my cable because I had to make a new one, but after checking everything out I think it's made ok. Although I don't remember this problem before (but when I find my old cable I will try it on that one). When I unplug the prop plug from the propeller everything seems to be ok. I'll also try this on linux and see if it does it there too.

Not really a big deal. Just thought I'd mention it in case its not something I did silly.


Is there any way for the propeller side to know the status of the USB port and Serial port connection ie. disconnected/enumerated and open/closed?

Thanks a lot for the 96Mhz version!
-Chad

hippy
10-05-2007, 12:40 AM
Chad George said...
I did run into one weird problem. When my PropPlug is connected to the board at the same time as my USB cable the Propeller based USB connection keeps dropping and resetting.

I get the same problem. I pulse a LED on my board after reset and can see something is repeatedly resetting the board. Nothing has the COM Port the PropPlug is on open.

For extra weirdness, I can open a Terminal Emulator, select the PropPlug Port but don't use it, close the Emulator and no more resetting happens.

Power cycle the Proto Board and resetting starts again.

Post Edited (hippy) : 10/4/2007 5:45:58 PM GMT

BradC
10-05-2007, 01:47 AM
Ok, if you can give me detailed steps to reproduce, I'll have a good crack at reproducing/fixing it after Saturday..
I've not seen the problem, but then my Prop plug and board are usually plugged into a Linux box with the prop plug redirected into a VM running windows.
I'll fire up the XP box and try to reproduce it though..

Chad, with the serial005 code I can tell you when the port is open/closed.. but that does not appear to do the right thing for you guys..
I can set a flag when it's enumerated though.. so yeah.. In the new revision code you'll be able to ask it for enumerated 0/1 ... see what I can do about the
open/closed.. but I'm gonna need more debuggin on that.. can one of you send me some code that works with 004 and fails with 005 for me to test on a demo or proto board?
(Have both).

hippy
10-08-2007, 08:14 AM
@ BradC : More good news from my perspective and maybe others - I've managed to get the Propeller Serial USB working under Windows 98SE.

Not entirely sure how; it was a few hours of hacking various .INF files, Win98 crashes, and trying to get Windows to forget what it thought the VID/PID meant and use what I'd like it to. The bottom line is that I have a WDM Modem Enumerator and a new Serial Port device.

It's using usbser.sys, ccport.sys, vmm32.vxd (ntkern.vxd) and wdmmdmld.vxd - These came in the "WMD Modem and USB Modem Kit" ( wdmmdm.exe ), and the .inf files were pulled semi-randomly off the internet and kicked into shape.

There's no way so far to adjust COM Port from Device Manager but it does appear as an extra COM Port which can be opened, and what's more it seems to work.

Once I get the hacked .inf files in better shape and installation repeatable I'll publish them here along with the necessary device drivers.

BradC
10-08-2007, 11:34 AM
Actually, Win98SE has the usbser.sys hidden in on of its cab files.. I've read it's possible to get it installed manually, but that's winding the clock too far back for me :)

Nice work indeed!

Sapieha
10-08-2007, 01:26 PM
Hi BradC, hippy.

If you interested I have orginal support files to Win95-98 to USB

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.

Sapieha

hippy
10-08-2007, 10:23 PM
@ Sapieha : Thanks, but I think I have all the files needed.

Attached are the .inf and driver files needed if anyone wants to try Propeller USB under Windows 98SE. They work for me but no guarantees.

Installation is two step a process; firstly Windows finds a USB/Composite device, then installs the driver for that (CDC), then after a short delay it will go looking for a Modem Device, installs the driver for that (MDM) which turns it into a normal port. Point the installation to the directory where the files have been extracted to and it should just be a click-through of the default options.

The 308349usa8.exe is a Microsoft fix to stop Windows 98 hanging on shutdown when USB Modems are used. You'll probably want to run that.

I got one driver displaying a property page, but it was hardware FIFO setting options, and I couldn't get a COM Port change option to appear. Someone may have better knowledge than I do on that front.

If experimenting with drivers, remove the drivers to ensure changes are detected - With Propeller USB connected, delete the aichip*.inf files from \WINDOWS\INF\OTHER, remove "Propeller Chip USB" from "USB Devices" ( not "Ports" ), power-cycle the Propeller and it should provide a clean re-install.

Sapieha
10-08-2007, 10:27 PM
Hi hippy.

No problem.

But my drivers is tu have full USB HUB control

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.

Sapieha

dfletch
02-19-2009, 03:24 PM
This is excellent, thanks so much!

One thing I found. I happen to have a mouse on the same root hub. If I move the mouse during California Dreaming output, it skips chars and sometimes goes into a weird endless loop. I hit numlock again and it restarts fine.

I'm on Windows XP SP2

Thanks for this killer driver. I think it's going to reduce the cost by a bunch on this a board I'm working on.

Cheers,

--fletch

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto (http://propeller.wikispaces.com/Join+us+on+IRC%21)
spinc - open source Spin compiler (http://sourceforge.net/projects/spinc)

dfletch
02-19-2009, 03:30 PM
Update: if I put the mouse on another root hub there is no interference, so that seems key.

By the way, I'm using USB_lowlevel_006.

Cheers,

--fletch

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto (http://propeller.wikispaces.com/Join+us+on+IRC%21)
spinc - open source Spin compiler (http://sourceforge.net/projects/spinc)

BradC
02-19-2009, 03:42 PM
Oh, wow people still play with this stuff? I'm up to USB_lowlevel_011 now. 9,10 & 11 had _major_ stability improvements with regard to odd bus behaviour. Give me a couple of days to get it cleaned up and I'll post the new stuff. The new lowlevel code is not quite API compatible with the old stuff as I had to break compatibility when I re-worked some bits. I have updated all the demos (keyboard/CDC-ACM and now HID) to use the new code though. I just need to get it sorted, tested (I've not modified it for probably 6 months now) and published again.

The problem you are seeing is related to the low level code responding to address broadcasts its not supposed to respond to. I had the same thing when I stuck it on the same HUB as my HID UPS. It's fixed in the latest code.

bst[cl] on Linux and Win32 have native support for loading and playing with the prop using a HID bootloader already. I never released the Prop code as I still don't have it working on OSX though. I must get around to doing that. I just kinda got sidetracked with other stuff. The HID bootloader runs entirely from 2 cogs and only uses the last 8 longs of shared HUB ram for IPC. I also have an official VID/PID pair for use on this stuff tucked away somewhere..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

dfletch
02-19-2009, 03:49 PM
Thanks for the quick response! I look forward to the new version.

Stop by the IRC chan if you want to chat.

Cheers,

--fletch

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto (http://propeller.wikispaces.com/Join+us+on+IRC%21)
spinc - open source Spin compiler (http://sourceforge.net/projects/spinc)

Mike Huselton
02-21-2009, 02:51 PM
BradC,

What do you think of the notion of your driver code controlling a USB WiFi plug-in stick adapter?

I don't see it looking promising, but I thought that I would ask.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

BradC
02-21-2009, 03:20 PM
James Michael Huselton said...
BradC,

What do you think of the notion of your driver code controlling a USB WiFi plug-in stick adapter?



The short answer is no.

The longer answer is still no, but with an explanation.

Almost _all_ the available USB sticks today offload most of the processing into the driver. It's not like just passing packets and some control information, but the raw IEEE802.11 frames get passed directly to the driver for processing. On top of that you need to be able to load the firmware blob into the device and know how to control its low level IO hardware.

Some great example code for lots of widely available WiFi hardware exists in the later Linux kernel sources (Including the SDIO cards - of which there are very few with sufficient documentation to drive). You will find a far better idea of what you are up against trying to drive WiFi hardware directly if you look at some of the existing driver source and the various stacks a packet must go through before it even hits the device.

My USB code was written from the point of view of a gadget rather than a host. To make it work the other way is possible I'm positive, but it's a case of either hard coding it for a specific device or adding a _lot_ of enumeration code to deal with the variations in devices. The other issue is my media layer is strictly low speed USB. This precludes you from doing all sorts of fun things (like bulk packets which are the mainstay of most data-transfer devices like ndis network interfaces or flash disks)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

Mike Huselton
02-21-2009, 03:24 PM
That's what I imagined the answer to be.

Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Erik Friesen
02-25-2009, 05:06 AM
Here is some HID code created from some of brads later work. With his permission I am posting it here. To run this demo, follow the wiring details. D- is white, and D+ is green, at least according to usb specs. Any text program should work, you will just have to change it to your code.

Here is a link to a program that will test it. www.lvr.com/files/SimpleHIDWrite3.zip (http://www.lvr.com/files/SimpleHIDWrite3.zip)

This will echo back using control transfers. To send an interrupt transfer from the prop, you have to load the inreport buffer(remember all buffers are described from the host perspective) and call usb.send

The vid/pid is a pair I bought from somewhere, just keep it at home and it should be fine, or change it to something else, just be warned.

trodoss
03-04-2009, 06:57 AM
@BradC

I have been playing around with the code for a little bit, and have had quite a bit of fun.· Definately looking foreward to the updated code related to CDC-ACM.

BradC
03-04-2009, 07:59 AM
trodoss said...
@BradC

I have been playing around with the code for a little bit, and have had quite a bit of fun. Definately looking foreward to the updated code related to CDC-ACM.


What sort of updates are you looking for? I've certainly made some huge reliability updates, but as for features it's pretty much just a single serial port. I looked at upgrading it to dual emulated ports, but got sidetracked.

Linux still needs a kernel patch, and windows needs the .inf file. At least it's plug and play with OSX ;)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

trodoss
03-04-2009, 10:04 PM
@BradC

I had built a crude datalogger on a protoboard for a friend that interfaces with an RS232 serial·null modem connection to an old·lab machine.· He would like to be able to connect directly from a PC (using USB, running Windows XP) to the device at times using HyperTerminal.· I had expirmamented with the older code on the thread.· The root hub interference problem explains the random dropped data I was seeing.··What I had gotten to work was fun though.· I had been contemplating just buying a new USB-based (FTDI) protoboard and rebuilding the device. [Edit:] Most of it is just "playing around" with old/surplus equipment.· So, if it dosen't work, it is not a big deal.· I had just suprised myself that with code examples/etc. that I found on the forums I could get as far as I did, never having an electronics course in my entire life--just lots of tinkering with BS2/SX/Propeller chips.

I will probably try the code that I have based on the USB_lowlevel_010 in the HID-USB Demo code and see if that works better.

Thanks!· I really appreciate the work you have put into all of this.

Post Edited (trodoss) : 3/4/2009 3:15:05 PM GMT

BradC
03-05-2009, 06:30 AM
trodoss said...
I will probably try the code that I have based on the USB_lowlevel_010 in the HID-USB Demo code and see if that works better.



That won't work at all I'm afraid. Lowlevel_010 was a significant API change between the levels.
Try the attached file with lowlevel_010 and see how you get on. I've been using it for about a year and found it pretty reliable.
You'll need to change the reference to Lowlevel_011 to Lowlevel_010 to get it to work. Lowlevel_011 is my current devel version but it's really not much different from 010 right now. I've only just started to get back into USB after a year or so hiatus.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

trodoss
03-06-2009, 01:19 AM
@BradC:
Thanks! Saved me hours of guessing and/or frustration!

hippy
03-19-2009, 01:34 AM
Finally, I've got a real application the Propeller should excel at, but I'm not sure it will. Probably one for BradC but anyone can throw in their two euro if they wish.

I'm replacing my chunky, clunky, noisy, power guzzling PC with a modern lean-machine, but unfortunately it's USB only, two sockets. I need to keep the external hardware as is and want to minimise space and costs in buying other cables and adapters -

* PS/2 keyboard
* 9-way serial trackball ( standard serial mouse compliant )
* 9-way serial out to a serial-to-relay controller
* game port input from two push button sensors

The game port inputs could be received through the same serial interface as used by the relay controller and each should be easily handled by its own cog.

The big questions are - can all this be thrown together on a single USB cable to the PC, and how hard is that going to be ?

To me it's just a composite keyboard / mouse plus a serial channel so should be possible but I bet I don't know the half of it http://forums.parallax.com/images/smilies/smile.gif

Bill Henning
03-19-2009, 01:41 AM
The "easy" path would be:

4:1 powered USB hub
2 USB to Serial converters for the trackball and relay controller
1 PS2/USB converter dongle (if the keyboard supports it) or cheap USB keyboard
1 propeller pretending to be an HID converting the old game controller if the low level drivers will work for this (over a hub)


hippy said...
Finally, I've got a real application the Propeller should excel at, but I'm not sure it will. Probably one for BradC but anyone can throw in their two euro if they wish.

I'm replacing my chunky, clunky, noisy, power guzzling PC with a modern lean-machine, but unfortunately it's USB only, two sockets. I need to keep the external hardware as is and want to minimise space and costs in buying other cables and adapters -

* PS/2 keyboard
* 9-way serial trackball ( standard serial mouse compliant )
* 9-way serial out to a serial-to-relay controller
* game port input from two push button sensors

The game port inputs could be received through the same serial interface as used by the relay controller and each should be easily handled by its own cog.

The big questions are - can all this be thrown together on a single USB cable to the PC, and how hard is that going to be ?

To me it's just a composite keyboard / mouse plus a serial channel so should be possible but I bet I don't know the half of it http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

hippy
03-19-2009, 02:25 AM
Thanks Bill; that is the easy path, though does anyone know if WinXP will actually detect and use a 9-way serial mouse (trackball) if it comes in via a USB-serial cable ?

Rather than do HID on the Prop just for a game port it would be easier to use a $1 micro and send data up the same USB-serial cable used for the relay controller - Both are used only by the same PC App so no problem with pairing them up. So -

* Hub
* USB-to-keyboard cable
* USB-to-serial cable for trackball
* USB-to-serial cable, TX to relay control, RX from sensor micro

If I can get another micro to convert the trackball 9-way to PS/2 I can use a USB Y-cable for keyboard plus mouse and that gets me down to two cables, no hub -

* USB-to-keyboard+mouse cable, with trackball to mouse converter
* USB-to-serial cable, TX to relay control, RX from sensor micro

BradC
03-19-2009, 06:00 AM
hippy said...
Thanks Bill; that is the easy path, though does anyone know if WinXP will actually detect and use a 9-way serial mouse (trackball) if it comes in via a USB-serial cable ?



That is a great question actually. Windows detects a serial mouse using PnP which plays with the modem control lines in specific timing sequences and I'm not entirely sure if it will manage that properly over a USB-serial connection. Years ago I had a serial mouse that had a broken PnP implementation and I do recall being able to force windows to use it on a particular port, but that was back in the Win95 days and I'm a little rusty on Microsoft stuff these days.

Now, my shipping container arrived yesterday and I've got some PL2302 USB-serial converters and a serial mouse hiding in one of my 66 boxes, so when I locate that particular box I can test it for you.

USB-Joystick is something I've been working on, on and off for a while. I was planning a HID compound device with Mouse / Keyboard / Joystick on it but it appears I've run out of endpoints. (Plus the compound device Descriptors are somewhat more complex than a straight HID descriptor).

So you are dropping Win98?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

hippy
03-19-2009, 07:41 AM
So you are dropping Win98?

Not entirely, and reluctantly being dragged into the new century.

The new toy ( Asus Eee Box B202 ) needs XP because SATA drivers for 98 are apparently dog-slow, while work has meant I've had to use XP on a daily basis so have rewritten most of my apps to work with that. I still prefer 98 but XP does have its advantages - particularly on the USB and WiFi front - though some things are a step backwards from 98 IMO. Even with as much eye candy turned off it still has the feel of 'My First Computer' http://forums.parallax.com/images/smilies/smile.gif

jazzed
07-17-2009, 11:27 AM
BradC,
I have your California dreaming demo running with the USB_03.zip. I can't seem to get the USB_Serial_005.spin code to work though. I see USB_Serial_009.spin here but not some of the other dependencies. What would it take to make a USB serial port work? Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

BradC
07-17-2009, 07:16 PM
jazzed said...
BradC,
I have your California dreaming demo running with the USB_03.zip. I can't seem to get the USB_Serial_005.spin code to work though. I see USB_Serial_009.spin here but not some of the other dependencies. What would it take to make a USB serial port work? Thanks.


This is the latest serial code (when I say latest it's probably nearly a year old and has been 24/7 to my linux server)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

heater
07-17-2009, 07:41 PM
Brad, in that package you mention that 2 kernel mods are required for this to work under Linux.
What might they be?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC
07-17-2009, 08:51 PM
heater said...
Brad, in that package you mention that 2 kernel mods are required for this to work under Linux.
What might they be?


On page 1 of this thread you will find a post from me with a usb patch attached. If you can't get that to apply, let me know what kernel version you are compiling for and I'll knock one up specifically.

Basically in drivers/usb/core/config.c you need to comment out the code that converts low speed bulk endpoints to interrupt endpoints.
In /drivers/usb/host/uhci-q.c there are two places that return -EINVAL if an attempt is made to queue a bulk URB with a low speed device that need to be commented out.

These days my server runs an nvidia chipset which uses the OHCI driver, so I only need to make the change to config.c, but the uhci changes don't hurt in any case.

I've had a crack at submitting a patch to the kernel that allows blatant spec violations, but it got rejected (for very good reason) with comments and 12 months later I've not got around to fixing it and resubmitting it. I'll get there one day. In the mean time, linux needs the patches and windows needs the .inf file. MacOS users are golden :)

<edit> Oh my, the kernel has changed quite a bit since I did the original USB stuff. You'll need the attached patch also.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

Post Edited (BradC) : 7/17/2009 1:56:35 PM GMT

jazzed
07-17-2009, 09:05 PM
HI Brad. Thanks for the updated .zip. What do I do about the CDC-ADM-HACK driver install? Where do I get it?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

BradC
07-17-2009, 09:09 PM
jazzed said...
HI Brad. Thanks for the updated .zip. What do I do about the CDC-ADM-HACK driver install? Where do I get it?


The avrcdc.inf file in the top post should work in theory. It matches based on VID/PID and I've not changed them. I've not actually plugged it into a windows box since hippy was helping me with it early on, but the CDC interface and descriptors have not changed such that it should make a difference.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

jazzed
07-17-2009, 09:32 PM
http://forums.parallax.com/images/smilies/blush.gif <HomerSimpson text="Doh!"/>

So, the USB_Demo_Main_001.spin should work with some changes to start and including the right driver?
I see the device installed as COM9 and PST actually recognizes it, but I don't get characters echoing back.
Any ideas?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

BradC
07-17-2009, 09:40 PM
jazzed said...
http://forums.parallax.com/images/smilies/blush.gif <HomerSimpson text="Doh!"/>

So, the USB_Demo_Main_001.spin should work with some changes to start and including the right driver?
I see the device installed as COM9 and PST actually recognizes it, but I don't get characters echoing back.
Any ideas?


Yes it should. No I have no idea. Having said that, I built an XP VM yesterday so I could test some other stuff, so if you give me the weekend I'll fire it up and make sure it works as it should on Windows.

Given Windows has detected the port you are 95% of the way there. That used to be the hard bit. The fact she's not running is probably something I've modified that works on Linux and OSX but causes Windows to quirk out. I'll get it sorted.

Oh, you are using PST. Does toggling the DTR help? From memory I've put DTR control in there and it won't send if the DTR is low.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

jazzed
07-17-2009, 09:57 PM
Yup, setting DTR fixed it :) Is it possible to ease that requirement ?
Thanks Brad.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

BradC
07-17-2009, 09:59 PM
jazzed said...
Yup, setting DTR fixed it :) Is it possible to ease that requirement ?


Completely untested in all forms, but try changing the following




IF_NZ or _out, #2 ' We are off hook, enable data transmission

IF_Z andn _out, #2 ' Stop transmission of DATA


to
or _out, #2 ' We are off hook, enable data transmission





That _should_ make it completely ignore the DTR state, while still recording and acking it properly to keep Windows happy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

BradC
07-17-2009, 10:04 PM
You _should_ be able to get nearly 8KB/s in theory. Over 200MB loopbacks I think I averaged about 6.5KB/s from memory. It's been a while since I tested it. Half duplex should be about 8KB (single 8 byte data packets, plus overhead at 1000 packets per second). This is the absolute best you can expect to get from low speed USB. I built a 57,600baud->USB converter for giggles and the USB kept up with the inbound serial stream with no problems.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!

jazzed
07-17-2009, 10:18 PM
Cool :)
Looks like we need to transmit an end of line $a or $d for a usb.str(...) to work. That behavior is reasonable based on history.
A txflush would be useful in such cases. I'll play around with the other "serial" functions.

BTW: Excellent Work!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Chad George
07-22-2009, 06:34 AM
BradC said...
bst[cl] on Linux and Win32 have native support for loading and playing with the prop using a HID bootloader already


Brad what does this mean ... maybe I'm overlooking something obvious but whats an "HID" bootloader and what capabilities will it have?

BradC
07-22-2009, 12:03 PM
Chad George said...

BradC said...
bst[cl] on Linux and Win32 have native support for loading and playing with the prop using a HID bootloader already


Brad what does this mean ... maybe I'm overlooking something obvious but whats an "HID" bootloader and what capabilities will it have?


HID means Human Interface Device. It's a specification that allows devices to be accessed using standard OS supplied methods and not need user installed drivers (think keyboards, mice, joysticks).

I still have that code in bst, but to be honest when it takes 7 seconds to load the prop over the FTDI interface, and about 45 over the USB interface I just stopped working on it.

I still have the bootloader code around here somewhere. It takes 2 cogs, 3 pins and communicates using the last 16 longs of ram. It allows you to play with the propeller while the bootloader is still active, provided you don't use the last 16 longs and only 6 cogs. I set it up so it can read/write ram/eeprom plus launch new binaries on the fly.. but then I must say I lost interest as it's still _slow_. Once I got the bit packed, double baud rate downloads working the serial interface is just so much faster.

Plus, I never got it working on OSX (not that I tried extremely hard).

If I ever get around to getting libusb to work properly on OSX, I might get back into it, but it's not high on my list.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>

TexFly
02-15-2010, 04:37 AM
Hello,

Would you please publish a quick tutorial to make the keyboard emulator working?

I mean: Propeller pins connection to computer (to emulate the keyboard) and steps to take with the software...

Thanks!

Post Edited (TexFly) : 2/14/2010 9:42:40 PM GMT

BradC
02-15-2010, 06:13 PM
Recently tested working code attached

http://forums.parallax.com/attachment.php?attachmentid=49667

Change this line :
OK := ll.start(Pcrcmask, epb, 0,1,2)

To whatever you have D- / D+ / Enable connected to.

Load propeller and your machine should detect a USB keyboard connected. The caps lock key will make it type out the lyrics to California Dreaming.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

TexFly
02-16-2010, 08:03 AM
Thanks Brad!

I see three files inside the zip archive...what do they do exactly?
Do I need to load all of them?

Alex

Cluso99
02-16-2010, 08:40 AM
Brad: I guess we could use a program to capture text and use it to send data to the pc http://forums.parallax.com/images/smilies/smile.gif

IIRC you have played with this sort of USB thing for a while. The hardware is so simple http://forums.parallax.com/images/smilies/smile.gif

Are you able to do a simple serial (both directions) with it to the pc ??

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)·
· Prop OS: SphinxOS (http://forums.parallax.com/showthread.php?p=819353)·, PropDos (http://www.orrtech.us/propdos/) , PropCmd (http://obex.parallax.com/objects/440/)··· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBlade Props: www.cluso.bluemagic.biz (http://www.cluso.bluemagic.biz)

BradC
02-16-2010, 02:11 PM
@Cluso99, the Serial object as been doing serial between the prop and a linux PC 24/7 for about a year and a half now. So I guess the answer is yes.

OSX works out of the box, Win32 requires an .inf file (it's in this thread somewhere) and Linux requires a kernel patch (in this thread)

A generic text to keyboard object has been on my todo list for a while (as has a joystick emulator, touchscreen emulator and all manner of funky hid things). I guess I got caught up and side tracked elsewhere :)

@TexFly, unzip them somewhere and load the California_Dreamin object in a tool, compile and load.

The CRC and low level objects are pulled in automatically.

I forget now, but it's either num/scroll/caps lock any or all that will cause it to spit out the lyrics. As soon as the prop starts though it should enumerate as a keyboard (evident using lsusb or similar).

The lowlevel object is the one than handles the usb communication while the other object sits above it at the application level. The low level cog is common to the serial and hid objects. The CRC was put into a separate object simply so I could use it commonly across all the objects and not worry about updates.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

Cluso99
02-24-2010, 05:33 AM
BradC: I have just been re-reading this thread.

I got sidetracked from my SphinxOS & RamBlade with a thought about using Bluetooth. Don't ask how that happened because I don't know. I didn't even have a project in mind :-(

Anyway, I was thinking if it would be possible to use a prop to drive a USB Bluetooth adapter (just as a serial device) so we could communicate with other Bluetooth devices (firstup PC - dare I say XP or Vista). I don't care if it is non-compliant as long as it works. see http://forums.parallax.com/forums/default.aspx?f=25&m=429977

I note the circuit is a little more that I expected. I intended to use an existing PS2 socket but I would need to add a third prop pin via a resistor and maybe change the series 100R to 68R and remove the 2x10K pullups. Use a PS2 to USB adapter or replace the PS2 connector with a USB-A connector.

Reading your thread indiates that the adapters are using the PC for more work. Is that likely with the USB Bluetooth ??? Might this work ???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)·
· Prop OS: SphinxOS (http://forums.parallax.com/showthread.php?p=819353)·, PropDos (http://www.orrtech.us/propdos/) , PropCmd (http://obex.parallax.com/objects/440/)··· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBlade Props: www.cluso.bluemagic.biz (http://www.cluso.bluemagic.biz)

BradC
02-24-2010, 06:12 AM
Cluso99 said...

I note the circuit is a little more that I expected. I intended to use an existing PS2 socket but I would need to add a third prop pin via a resistor and maybe change the series 100R to 68R and remove the 2x10K pullups. Use a PS2 to USB adapter or replace the PS2 connector with a USB-A connector.

Reading your thread indiates that the adapters are using the PC for more work. Is that likely with the USB Bluetooth ??? Might this work ???


Not very likely I'm afraid. For a USB host you'd need to run the Prop at precisely 96Mhz, and at best you'll get low_speed USB which is not allowed to have bulk endpoints. Have you looked at some of the source for a usb-hid bluetooth stack? It's enormous. Just the enumeration and configuration of the bluetooth dongle is a huge task.

Not sayin' it can't be done... but there are plenty of cheap bluetooth-serial modules available for *far* less effort.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

Cluso99
02-24-2010, 06:24 AM
Thanks Brad. Just thought it would be nice if it was doable.

I had incorrectly assumed the bluetooth code would be handled within the bluetooth device.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)·
· Prop OS: SphinxOS (http://forums.parallax.com/showthread.php?p=819353)·, PropDos (http://www.orrtech.us/propdos/) , PropCmd (http://obex.parallax.com/objects/440/)··· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBlade Props: www.cluso.bluemagic.biz (http://www.cluso.bluemagic.biz)

BradC
02-24-2010, 06:35 AM
Cluso99 said...

I had incorrectly assumed the bluetooth code would be handled within the bluetooth device.[/quote

Oooooh no... Like Microsoft with their "WinPrinters" the whole thing surrounding USB originally was that it was (is) a completely dumb bus. The devices that connect to the end of it are also dumb (unlike firewire) and therefore it wins by default on the back of it being cheap. Slow & CPU intensive but cheap.

Most USB devices are nothing more than interfaces between the software and the minimal hardware required to perform the task. All the smarts lie in the driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

Cluso99
02-24-2010, 09:27 AM
BradC said...
Oooooh no... Like Microsoft with their "WinPrinters" the whole thing surrounding USB originally was that it was (is) a completely dumb bus. The devices that connect to the end of it are also dumb (unlike firewire) and therefore it wins by default on the back of it being cheap. Slow & CPU intensive but cheap.

Most USB devices are nothing more than interfaces between the software and the minimal hardware required to perform the task. All the smarts lie in the driver.
I didn't understand, so I fed your reply into the internet language translator and this is what it translated to...

Hardware is reduced. Software is moved from a controller to the PC as a driver. The driver is way more complex as it has to interface to bloatware, so becomes bloated itself. Cost is increased. Then the supplier has to have it approved and Bill receives a big chunk of $$ for this. Now the supplier is hooked Bill brings out a new version of the OS and the supplier has to jump through hoops to make his driver work again. For this luxury, Bill receives another big chunk of $$.

Meanwhile, the customer sees that the hardware is now tiny and thinks the supplier is ripping him off. Every time Bill releases a new version of the OS, the customer complains to the supplier that his driver is crap.

Is this what you meant to say http://forums.parallax.com/images/smilies/shakehead.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)·
· Prop OS: SphinxOS (http://forums.parallax.com/showthread.php?p=819353)·, PropDos (http://www.orrtech.us/propdos/) , PropCmd (http://obex.parallax.com/objects/440/)··· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBlade Props: www.cluso.bluemagic.biz (http://www.cluso.bluemagic.biz)

BradC
02-24-2010, 09:41 AM
Cluso99 said...

BradC said...

Oooooh no... Like Microsoft with their "WinPrinters" the whole thing surrounding USB originally was that it was (is) a completely dumb bus. The devices that connect to the end of it are also dumb (unlike firewire) and therefore it wins by default on the back of it being cheap. Slow & CPU intensive but cheap.

Most USB devices are nothing more than interfaces between the software and the minimal hardware required to perform the task. All the smarts lie in the driver.
I didn't understand, so I fed your reply into the internet language translator and this is what it translated to...


Hardware is reduced. Software is moved from a controller to the PC as a driver. The driver is way more complex as it has to interface to bloatware, so becomes bloated itself. Cost is increased. Then the supplier has to have it approved and Bill receives a big chunk of $$ for this. Now the supplier is hooked Bill brings out a new version of the OS and the supplier has to jump through hoops to make his driver work again. For this luxury, Bill receives another big chunk of $$.



Meanwhile, the customer sees that the hardware is now tiny and thinks the supplier is ripping him off. Every time Bill releases a new version of the OS, the customer complains to the supplier that his driver is crap.



Is this what you meant to say http://forums.parallax.com/images/smilies/shakehead.gif


Actually, no it's not. What I meant to say was :
Hardware is cheap and cheery making all the intelligence reside in the driver. This has 2 "benefits" :
A) It slows the machine down requiring faster processors (Intel Wins - after all they played a large part in designing it)
B) The manufacturers tie up all their intelligence in a windows-only binary driver and don't release the specs on how to actually use their product meaning you need to be using windows to use their product (Microsoft Wins).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

Cluso99
02-24-2010, 01:07 PM
Actually, I cannot wait until everything goes back onto the Internet servers and we just use a dumb terminal. No virus software to soak half the performance, etc, etc.

Then maybe our Prop or PropII will be the frontline processor of choice for the masses. http://forums.parallax.com/images/smilies/smile.gif Well, we can always hope anyway http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)·
· Prop OS: SphinxOS (http://forums.parallax.com/showthread.php?p=819353)·, PropDos (http://www.orrtech.us/propdos/) , PropCmd (http://obex.parallax.com/objects/440/)··· Search the Propeller forums (http://www.google.com/advanced_search?q=+site:forums.parallax.com&num=20&hl=en&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBlade Props: www.cluso.bluemagic.biz (http://www.cluso.bluemagic.biz)

BradC
02-24-2010, 01:41 PM
Cluso99 said...
Actually, I cannot wait until everything goes back onto the Internet servers and we just use a dumb terminal. No virus software to soak half the performance, etc, etc.



I don't like that from a loss of control perspective more than anything. Thin clients were all well and good, but I like to have as low level control over my environment as possible.

Trust no-one.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

Ale
07-29-2011, 09:21 AM
I just discovered this, I was planning in modifying an old joystick to act as a keyboard (to play team fortress 2!, as I am old-skool where all was done with 5 keys and not keys+mouse!)... I have to figure how to use this lowlevel object...

Cluso99
10-22-2011, 06:08 AM
Ale: Did you get anywhere with this? I am currently trying. I have a simple demo program just echoing what it receives from the pc back to the pc, but no-go yet. I am on XP SP2. The .inf file has been loaded ok.

BradC: Are you still around???

Trac
05-04-2012, 01:03 PM
Is it possible to use the CTRL, ALT, SHIFT keys together with an other key with the California keyboard? I can't seem to manage it.

For those interested in the Generic keyboard code, i posted it in this thread: http://forums.parallax.com/showthread.php?97027-California-Dreamin&p=1095274

Would be nice to have this working so I can use this propeller-keyboard to send macro's.

Cluso99
05-05-2012, 12:01 PM
I havve been giving the CDC a try today again. I wasAble to get data in one direction only (pc to prop IIRC). I have just been reading the previous page here and noticed a comment and patch for DTR. I must try that in the morning.

Cluso99
05-06-2012, 02:08 AM
The patch works for the serial virtual comm (CDC) with XP. Don't forget the ini file for the driver.

Here is the working code - crude demo but it works.

92283

Roadster
10-19-2013, 02:39 PM
Has anyone got this to work with window 7

Cluso99
10-20-2013, 10:45 PM
Haven't tried it on W7.

Roadster
10-21-2013, 01:56 PM
I have tried 4 different machines with windows 7 and all of them fail to install the device driver, I guess I'll re-build one of machines to windows xp just to make sure that works.