Usb Keyboard driver
Pasha
Posts: 56
Hello, I have the PropRPM board, which has video, but no keyboard or mouse control options. I do not have a ps/2 head lying around, so i would like to build a driver that uses usb, which could be connected simply by using a usb extender cable which can be bought for only a dollar. I think it aught to work, but I can't find the usb protocol anywhere. Can anyone help me.
PS. I know that usb is 5V, but i am using a 5V power supply, so i can take the voltage from there.
PS. I know that usb is 5V, but i am using a 5V power supply, so i can take the voltage from there.
Comments
It is simply incapable of being a USB host, however. That is more difficult.
The best way to use a USB keyboard would probably be a FTDI Vinculum. I beleive that they can emulate a PS/2 keyboard, but I don't know how to configure them to do so
You'll see why I put "gentle" in quotes when you get there. All that to connect a keyboard or mouse, insane !
And by the way why do they call it a "bus" when it only handles point to point connections without the help of a hub?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
On as my wife would say, "3.3" it's the new 5.0!
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.
Don't ever let it out as it's·very difficult·to get it back in."
@ heater : USB is quite complex, but then it does a lot and serves multiple purposes. How "insane" depends on how you look at it; whether designed and over complicated to connect a keyboard or mouse or designed as a communication technology and then used for keyboard and mouse. "Bus" I think is valid as it's a common and generic term used to describe any inter-connection over which information is passed.
It seems to me that USB is quite complicated, needing a good understanding of all the protocol layers and the general overview, with a hardware level protocol which pushes a processor to its maximum. That needs quite a skill set and understanding which is perhaps why (AFAIK) only BradC has delivered anything for USB and no one seems to have taken his work any further.
I expect those who want to use USB, simply want it, don't appreciate the complexity nor have the skills to implement it themselves. Few have the skills to do USB and those who could have other projects or don't have the time to commit. It does look like quite an uphill struggle for anyone who has only minimal knowledge of USB.
Maybe we need a 'working group' and some 'USB Champion' who could push development of Propeller USB forward ? "A problem shared ...", as the adage goes.
Usb powers at 5.0v and the signals are at 3.3v.
Usb is not easy and if it is just a matter of not having the connectors, I am afraid you will spend more time and money than it is worth getting this to work.
I've been meaning to pick the USB stack back up. I have a completely universal HID implementation now that is usable for keyboard/mouse/joystick and general HID traffic (it also works as a debugger/bootloader using 2 cogs), but I've been kinda sidetracked the last couple of months with some other projects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Why is the bit timing for a Host more critical than that of a Slave? Both receive, or send an USB packet, timed by it's own, without a sync clock or something similar from the host. Is it not easier to implement a host, because you can decide when you will send a packet, and then you have a lot of time to decode the respond, until you start the next request?
What I don't know: Are all mice and keyboards Low Speed devices, or in other words: Is Low Speed a part of the HID spec for mouse and keyboard?
Andy
Because the USB spec says so. Hosts must be incredibly accurate, while low speed devices are allowed +/- 1.5%, a host/hub of any kind is 0.05% (USB2 spec clause 7.1.11)
No. There are strict timing requirements that a device must expect from the host. If the host violates those timings then the device state may well be indeterminate.
No, a HID device may be any speed from low to high. Most keyboards and mice I've seen that are single function devices are low speed, but there are certainly no guarantees.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I saw the implementation of a USB to PS/2 adapter or something like that with an atmega8 or 32. I thought it was some work but straightforward to reproduce. I'll post the code I downloaded if I do not find the link.
There was a thread about this in mikrocontroller.net
instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html#software
"SIAM32 USB HC
Software Implemented Atmel Mega32 Universal Serial Bus Host Controller"
I think, it's only possible to implement a low speed host for mouse and/or keyboards, which is not defined by any USB specs.
A full USB host has certainly much higher demands.
If a host driver is made for only a mouse, then you don't need to request all the descriptors. Just give the mouse an address ("Enumeration light") and request the data packets for X,Y and buttons. To keep the mouse alive a EOP (End of packet) is needed all 1 .. 3 ms. IMHO this should be doable.
Today such a driver is not really necessary, because one can still buy PS2 devices. But new computers have no PS2 ports, and some day only USB devices will be available.
Andy
Actually, is there such a thing as a "low speed" usb serial adapter? it would be wonderful if it was possible to get rid of the usb<->serial chips... and there may be enough time for Chip to add such a usb-serial driver to the rom in Prop2....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Not a hope I'm afraid. Hub enumeration is _way_ out of the question.
No, not really. All usb-serial adaptors use bulk endpoints, and bulk on low-speed violates the spec. It won't even work on linux without patching the kernel.
Having said that, the cdc-acm driver floating about in the forums _does_ work. I've been using it to have my thermostat communicate with my server now for months without issue (but I had to patch the kernel to allow it).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Calling it a "bus" still grates with me. Old electric "bus bars" were called that because they distributed power to many points. Later the term bus was applied to address and data buses which again had many devices attached. In networking "bus topology" is defined as many nodes connected to a central cable. So "bus" just does not seem correct for USB.
Bah - I'm becoming a pedantic old man.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I agree with BradC, that 2 pins is very difficult. Perhaps it's possible with 3 pins: 1 shared D+, and 2 separate D- lines.
The only low speed USB-to-Serial "chip" I know, is the AVR software solution from:
www.recursion.jp/avrcdc/
That the needed low speed bulk transfer is not specified, is not the main problem, because if one makes a host driver, he can decide what is implemented.
But I don't see the advantage to use a USB Bridge for a serial communication. The propeller can handle many Serial Ports direct, and if the pin count is the problem, an I2C-to-serial solution would be easier and faster (needs also a custom programmed Controller).
I hope the Prop2 will be able to support full speed USB, either with bit-banging, or with an appropriate Input-shifter hardware.
Andy
The advantage in my case is I have 3 pins on the propeller + 3 resistors and I can plug into a USB port on Windows/MacOS/Linux and pretend to be a serial port.
Linux still needs a 2 line kernel patch, and Windows needs an .inf file however. But certainly no external USB-Serial hardware required.
With the USB HID bootloader, no driver/.inf files on Windows required, Linux is just plug and go and MacOS requires the installation of LibUSB (I'm trying to work around this however).
So you can just plug and go on almost any OS.
For RS232 you require (well, kinda) level shifting hardware and 2 prop pins
For USB-Serial you require a USB-Serial converter + level shifting hardware (or a propplug/clip) and 2 prop pins
For USB direct you require 3 resistors and 3 prop pins.
I see an advantage [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
We speak not from the same thing. Yes I see certainly an advantage, for a propeller slave to use CDC and emulate a serial port.
But Bill has asked for a propeller host, that supports connected USB to serial chips (ie. FTDI). And for that I don't see an advantage, regardless of that it's not possible with an FTDI.
Andy
I apologize, I understood Bill to be suggesting the Prop come with a USB bootloader rather than talking to a USB-Serial converter.
I'm with you on that one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
That's not quite correct, what I was looking for is something like what Brad has... I was trying to eliminate an FTDI
Best Regards,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
So you mean a "low speed usb serial adapter" in software inside the propeller for communication with a PC?
This must be an USB slave then, and BradC has already done this.
http://forums.parallax.com/showthread.php?p=675351
Andy
I'll have to check it out - sounds great. I am hoping Chip will use something like it for Prop II
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html
http://www.mikrocontroller.net/topic/30029
The code can be downloaded from the Japanese page
Ale
Everything is hard coded, no error checking of any kind is done and the returned data is not really parsed, but it's still a big achievement. There are hard coded areas for each device as while they are all USB compliant, each one responds slightly differently and without actually processing the returned data properly it's hard to know what the device is expecting.
Using 2 or 3 cogs, it's probably possible to do a passably better job with a propeller, but then you start to run into the kind of compatibility problems the author did with regard to different devices responding with different timing and parameters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
If so there is either something very wrong with the Prop architecture or it's programming languages/environment. I find that disturbing. To connect a keyboard and a mouse I've just consumed most of my wonderful Propeller. Would not be worth it.
Now I know almost nothing about USB except that it takes: 1) Some very slick bit banging assembler level code if you want to do the lowest hardware level in software, which we do. 2) A big pile of less slick code, in preferably some higher level language to handle the higher protocol levels.
That much I can discern from looking at the AVR-USB code. www.obdev.at/products/avrusb/index.html
Now looking at the Prop, we see that the bit banging assembler is quite possible, as your USB stack demonstrates, and that there is probably quite enough room for the higher level slower code. Problem is we can't do both from a single COG at the same time, in SPIN at least.
So to get around this don't we need to use LMM ?
Do the bit banging in neat assembler which then jumps into the LMM kernel to run the higher level code when required.
This would require being able to fit the USB bit banging code and a small LMM kernel into a single COG. The LMM code can take as much space as it needs from HUB RAM.
In my small way I have resorted to doing this with my 8080 emulator. Most 8080 instructions are interpreted by neat assembler but, as I ran out of COG space, a few less used ones are farmed out to LMM code. The LMM kernel is tiny.
I have not really looked at the ImageCraft LMM kernel for C, I suspect they have not left enough room for any more code in the kernel. Perhaps it can be stripped down, I don't know.
Or we need a much simpler high level language that will run with a very small LLM kernel. Or just an LMM assembler.
What do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No, no, no.. if you want to perform the hack they are doing with the AVR, then sure you can probably do it in one cog. You just won't get the functionality you are actually after (and certainly not the reliability of being able to plug any old USB mouse or keyboard into it and having it work)
If you want to do it _properly_ you will need some more horsepower.
By properly, I mean at least with some very basic error checking and parsing enough information to be able to make use of more than one particular make/model of device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!