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 . 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.
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 [noparse]:)[/noparse]
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.
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..
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..
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?
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.
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).
@ 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.
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 [noparse]:)[/noparse]
@ 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.
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 spinc - open source Spin compiler
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 spinc - open source Spin compiler
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[noparse][[/noparse]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.
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 spinc - open source Spin compiler
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.
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.
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.
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.
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 [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
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. [noparse][[/noparse]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.
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.
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
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
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.
Comments
Thanks for any help.
plug it into [noparse]:)[/noparse]
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.
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..
Woo-Hoo
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.
It'll be fully compatible with what you have now, so no real changes there..
THANKS HIPPY!!!!!
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
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
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).
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.
Nice work indeed!
If you interested I have orginal support files to Win95-98 to USB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
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.
No problem.
But my drivers is tu have full USB HUB control
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
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
spinc - open source Spin compiler
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
spinc - open source Spin compiler
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[noparse][[/noparse]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.
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
spinc - open source Spin compiler
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
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.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Here is a link to a program that will test it. 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.
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 [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
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. [noparse][[/noparse]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
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.
Thanks! Saved me hours of guessing and/or frustration!
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
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)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
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
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.