Does there exist a PS/2-Keyboard SENDER?
StefanL38
Posts: 2,292
Hi,
a friend of mine will start an education to become a train-driver. There are various traim-simulation-softwares around. They all are controlled by the PC-keyboard.
Now I have the idea of building a train-cockpit with buttons, levers and steering wheel etc. To control a PC-software the propeller-chip must act as a keyboard.
Which means the propeller-chip is SENDING PS/2-signals (instead of reading them) The propeller-chip pretends to be a keybaord sending PS/2-signals.
Does there exist a PS/2-SENDER-object?
Could the USB-stack-object act as a USB-Keyboard?
best regards
Stefan
a friend of mine will start an education to become a train-driver. There are various traim-simulation-softwares around. They all are controlled by the PC-keyboard.
Now I have the idea of building a train-cockpit with buttons, levers and steering wheel etc. To control a PC-software the propeller-chip must act as a keyboard.
Which means the propeller-chip is SENDING PS/2-signals (instead of reading them) The propeller-chip pretends to be a keybaord sending PS/2-signals.
Does there exist a PS/2-SENDER-object?
Could the USB-stack-object act as a USB-Keyboard?
best regards
Stefan
Comments
I think kwinn's "should not be too difficult" will depend a lot on one's programming experience. I personally think it would be pretty difficult though I like to think I could figure it out. In my limited experience it's a lot easy to write a driver which controls the clock line rather than trying to write a driver which listens to the clock line and sends the bits out on request.
I hope you let us know if you get this to work.
You would have to adapt from a Master role to a slave role, and the really important little known fact is that communications are 12 bit serial in one direction and 13 bit serial in the other (I guess IBM added that to the specification just to sell more IBM keyboards).
Nothing is quite as educational as a reverse-engineerring project like this. Now that you have the clues, good luck.
Since you don't require handling keycodes with the additional complexity of multiple byte keycodes being converted to ASCII, I would use the Mouse driver as a first study and hack model.
thanks for your comments and suggestions,
It sounds difficult and seems to be a lot of work to create PS/2-signals.
@Loopy you are right great project to learn about programming data-transfer-protocols and programming in general.
But that's not my main intention.
So I chosed a different approach to solve the problem:
The propellerchip is connected to the PC through a standard serial connection.
Some years ago I coded quite a lot with delphi. So I started developing an application on the PC that receives the serial data from the propeller and sends keystrokes
from my Delphi-App to the other software running on the PC using keyboard-events. On the PC-side there are several ways to to this: SendInput, Keybd_event, PostKeyEx32 etc.
It's a little bit like in StarTrek NG: There are many ways to improvisate
(just tech-nonsens) Geordi la Forge "if we connect the flux-compensator through a tachyion wire and a magnetic switch with the energyfield-amplifier we can get back control
over the antimaterial-chamber... ;-) ;-)
By the way: this is a typical example how telling what I want to do in the end opens new ways to solve a problem. In the end I want that it is possible that pushing real buttons
and pulling real levers in some kind of locomotive-cabine (cockpit) makes a PC-simulation react on this pushing and pulling.
In the PC-Software this is done through mouse-clicks or keyboard input.
If I would have asked only for "how to create PS/2-signals?" to emulate a PS/2-Keyboard. Nobody could have ever the idea of how the final purpose can be done in others ways.
So in my opinion it is always good to give the forum an overview about a project and a description of what is the final purpose.
best regards
Stefan
But the interface is nothing more than SPI with 12 and 13 bit words instead of tidy 8 bit words. The biggest snag with the PS2 port is that the keyboard and the mouse can require 500ma of requlated 5VDC provided by the Master, but since the Propeller would be in a Slave role, the power requirement is moot. One may have to shift the outputs to +5 logic from +3.3 volt logic.
I supect the USB keyboard mimic would be a bigger headache. First off, you would likely need the USB slave to identify itself as a keyboard or a mouse as opposed to a generic serial port. That means recoding the USB chips EEPROM to identify correctly. Since the Arduiino has a 'USB hide" function, I guess that may make a USB hack much easier.
But the PS2 Slave emulation is certainly not rocket science. One can and should learn to bit-bang generic synchronous and asynchonous serial as fundamental building blocks for a lot of projects.
Taking an 8 bit SPI driver and extending it to 12 or 13 bits is not hard. Combining the input and output signal to one wire is not hard either. But hacking and cracking USB ports and underlying computer BIOS calls are more involved. Name your poison.
Ahh Loopy, I like it, that's just what I would have said!
@Stefan: As Loopy mentioned it's not rocket science, in essence putting aside the handshake and bidirectional part of it then it's only simple clocked serial, something that you could test in Spin in just a few minutes. If you keep it simple and test functionality first without all the possible combinations and functions you will see it is simple, then you can decide which functions and combination you need to implement. After all, keyboard controller chips were traditionally only primitive 8042 8-bit chips and you have the muscle of eight 32-bit 20MIP cores at your disposal.
It's only complicated if you don't understand it and you will never understand until you roll up your sleeves and start learning.
// Arduino code from Arduino.cc/reference
void setup() {
// make pin 2 an input and turn on the
// pullup resistor so it goes high unless
// connected to ground:
pinMode(2, INPUT_PULLUP);
Keyboard.begin();
}
void loop() {
//if the button is pressed
if(digitalRead(2)==LOW){
//Send an ASCII 'A',
Keyboard.write(65);
}
}
It doesn't get any easier than this! The Propeller 2 may end up having some modifications to allow for built in or near built in serial capabilities on USB. Perhaps P2 will also have an HID USB object - that would be cool. Right now, doing USB keyboard on P1 isn't worth the overhead in my opinion, leaving the less optimal PS2 route left. That's why I'm recommending a different chip that has built in USB hardware.
for those interested, here is the thread Tubular mentioned: http://forums.parallax.com/showthread.php/97027-California-Dreamin
since you can read german here some links:
http://www.mikrocontroller.net/topic/114541
http://www.marjorie.de/ps2/ps2_protocol.htm
http://www.rn-wissen.de/index.php/PS/2_-_Schnittstelle
http://www.uni-koblenz.de/~physik/informatik/ECC/ps2.pdf
http://www.mikes-elektronikseite.de/tastaturemulator
http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=35&category_id=6&option=com_phpshop&Itemid=1
IIRC, too much, but it does demonstrate it can be done although only slow. Now to make it less resource hungry and faster.....(I think that's P2 cue).
@ALL: I don't mind writing a sample PS/2 sender as I have written PS/2 and ADB keyboard emulators, except I would do it in Forth. If anyone really wants to then they can convert it to Spin which should be easy enough. (provided it's fast enough).
http://www.mcselec.com/index.php?option=com_content&task=view&id=322&Itemid=57
In Forth? Of course ! ! !. The clock rate doesn't have to be ightning fast as it never was. SPI doesn't require a PASM solution, but it does help that Forth is faster than Spin.