HOME > > SENSING AND CONTROL MAIN PAGE > > SENSORS > > SENSORS- MISC

Keyboard: How hard can it be?

Maybe there's already something like the following available. I'd love to hear about it, if so. Also, maybe I'm hoping for too much simplicity in what a USB keyboard sends and needs. Any notes "educating" me, or sending me to guidance in less than 10 pages of detail about everything a USB device can do, would be very welcome.

I don't THINK a USB-to-PS/2 converter is quite what I want... unless you can tell me that such a device can used in a "un-hand-shaken", "data-flowing-just-one-way" manner... which WOULD be interesting, even if it doesn't answer my hope for buffering of keyboard events.

Well.... quite hard, it seems, ** BUT **.....

From preliminary feedback, it would seem that my USB- keyboard- to- microcontroller would be a hassle. However, I have managed to cobble together a working prototype of the device described in the "stop press" which is just below here.

My "answer" is currently in a Peter Anderson BasicStamp2, ($25 assembled and tested at 2/08), reading a simple matrix keypad. If there's someone out there interested in working together to test and refine my "answer", and move it to a pre-programmed PIC, I'd be interested in hearing from you. If you want to protect the code in the PIC, I'd have no problem with that. Only the interface to the Arduino (or similar) would need to be published. I would imagine that you would develop your code for the PIC from my BasicStamp code, and have no objection to that either... but I'm not going to give anyone an exclusive license to the ideas.


STOP PRESS....

(Added after everything else was written)... If you can't refer me to, or design, the device I'm asking for, how about a "keyboard controller" which would be mostly what I describe, especially the buffer and interface to the microcontroller, but "fed", instead of by a USB keyboard, by a simple matrix keyboard? 4x4 would be enough. It doesn't have to be clever... no n-key rollover, etc.



I was wondering if the following could be made....

I want a small box with a socket into which you plug a USB keyboard and four wires coming out of it.

The three wires comprise a ground line, a line to feed 5v into the box, and onward to the USB keyboard, and two data lines to connect the box to a microcontroller, e.g. Arduino, BasicStamp, PIC, etc.

One of the data lines would be data from the box to the microcontroller, the other would be for data to the box from the microcontroller. I'll call them FromBox and ToBox in what follows. They only need to be suitable for direct connection to things like Arduinos, PICs and BasicStamps. (I.e.... I think... educate me, if wrong?... simple TTL levels and capabilities. Certainly NOT RS-232 levels.)

I DON'T want anything....

Crude but simple, cheap and reliable will do just fine. Just one major frill, please, which you'll see in what follows. I'll discuss some ways to use extra inputs to the electronics in the box, but they are optional!

As part of my quest for simple and cheap, I'm quite happy for the microcontroller to "miss" keys pressed on the keyboard. I'm also happy to dispense with being able to set the CapsLock, etc, LEDs.

I'm going to use "MC" for "microcontroller" from now on, and Box (with a capital "B") for the thing I want someone to design.

Here's the functionality I hope can be provided...

Picture a just booted system (MC+Box+keyboard). No keys pressed anywhere. At this time, the FromBox line should be high, and the MC should be driving ToBox high. (Or low... design it how you like, but I'll continue the description with things this way "up").

A human presses a key on the keyboard. I want SOMETHING (I imagine it to be a single byte, but would welcome enlightenment from anyone who knows what USB keyboards do) "harvested" AND STORED (this is the frill) in the Box. I DON'T need for the byte to be translated to ASCII, or anything clever like that. I don't even need the same byte to arise from, say, the "A" key on two different keyboards.

This "harvesting" by the Box of data from the keyboard need only happen when the Box's electronics are not busy with what follows. I.e. It is okay to "miss" characters typed on the keyboard. (Of course, if handshaking between the Box and the keyboard can be achieved without much hassle, so much the better. But I think I can live without it.... although something needs to be done to ensure that gibberish isn't "harvested" through "looking" at the data from the keyboard when half a character has already been sent, but "missed".)

As I said... I want the Box to STORE keypresses from the keyboard, but only a few keypresses, in a small FIFO queue.

When the Box has a character in the queue, it should bring FromBox high.

That will be the signal for the MC to bring ToBox low. On seeing ToBox low, the Box should start sending a serial stream over FromBox, carrying a byte from the queue. As soon as the MC sees a positive edge on FromBox, it should bring ToBox high again. MC will be responsible for NOT requesting another byte from the Box until there's been time for the previously initiated send byte to have been completed. A parity bit and stop bits would be "obvious" things to include, I would think... tell me if you disagree for some reason.

A tiny frill: If there are spare inputs for the electronics (another microcontroller, I would assume) in the Box, perhaps at least some of them could be for setting the baud rate.

So... there you have my dream. Do get in touch if anything's unclear, or if you think I'm missing anything in the spec, and more especially please get in touch if you think you could build one of them!

One area someone must know about which I'd love to have clarified: How are the shift, ctrl, etc keys handled? I'm hoping that if you monitor what's coming from a keyboard at the point it passes through the USB plug, you're seeing one byte per character, e.g. a byte when the A key alone is pressed, and a different byte when the A key is pressed when the shift or ctrl key is already down. Hmmm... I know this ISN'T quite the whole story... or maybe even close to being the right story... my PC can "see" when I depress the ctrl key, even if nothing else is depressed. So what, please, someone, IS happening?



My thanks to Paul Badger at http://www.moderndevice.com/ for the suggestion he sent. (He has the Diecimila Arduino, some bare bones Arduinos, an 8x8LED panel and an mini-LCD display.. at a very nice price!) This, with edits from me, is what he said...

"One easy way to do this would be to use an older style WINTEL keyboard, (i.e. I- editor of this page- think a PS/2 kbd). I don't remember what the standard is, but it's pretty easy to implement. The communication is pretty much a straight SPI (synchronous serial protocol) with a chip select line, a clock line and data line. One of my students did this either a Basic Stamp - or just a logic chip. It took her about 5 minutes. (Maybe it was beginner's luck!)"

That answer is very tempting... and provides a use for all those old keyboards in my junk room! I was just hoping to give my "answer" a little more future, by working with USB... but I'll certainly give the PS/2 answer more consideration.

Similar advice arrived from someone else who should know what he is talking about, Alex Zivanovic, who has a neat page with robot and other stuff...http://zivanovic.co.uk/

"Seems to me that a USB keyboard would be very hard to interface to (USB is nasty at low level). I think using a USB to PS2 converter would be best, or simply use a PS2 keyboard. PS2 is much easier to use - it's clocked serial like SPI. A microcontroller I have used in the past (Picaxe) has a command built in to read input from a PS2 keyboard. You could use a microcontroller to provide the buffer in the box you talk about."

He also supplied the following helpful links...

www.computer-engineering.org/ps2protocol... an excellent, full of all the specifics, article about interfacing with PS/2.

... and...

http://www.beyondlogic.org/ article about interfacing to an AT keyboard.

By the way... if I read the first article correctly, an "AT" keyboard is merely a "PS/2" keyboard with a different plug on the end of the cable. I never knew that! I have some old "AT" keyboards that I liked... nice "touch", etc... seems I can start using them again! I have an adapter or two from the days when both types were common. I thought the adapters were "good" only for specific keyboards. (But don't take my word for it... plug things into YOUR equipment at YOUR risk!)



Unimportant PS: Ah for the good old days of programming the BBC Micro. It had a very simple keyboard buffer implemented in the OS, with an OS call available to see how many bytes were in the buffer at the time of the call, one to read the next byte without removing it from the buffer, and another to read a byte and remove it. Am I dim? I've never been able to find the equivalent mechanism in Windows... and Boy, would it be useful at times!



Answers, please??? Either in whatever forum brought you to this page, or for private communication via my email address.. Watch this space for publication of answers I receive. If you send something and you DON'T WANT it published, please make that clear.

There is one "answer" out there already, which may suit others on a similar quest comes Solutions-Cubed. $28, and a demo file is provided for "Single Wire Interface with BasicStamp". It only takes about a dozen lines, and could be run on an Arduino, I think, with only trivial conversion... but it ties up the serial in line of either device. I can't see that the Solutions-Cubed device buffers keypresses.


Ad from page's editor: Yes.. I do enjoy compiling these things for you... hope they are helpful. However.. this doesn't pay my bills!!! If you find this stuff useful, (and you run an MS-DOS or Windows PC) please visit my freeware and shareware page, download something, and circulate it for me? At least (please) send an 'I liked the parallel port use page, and I'm from (country/ state)' email? (No... I don't do spam) Links on your page to this page would also be appreciated!
Click here to visit editor's freeware, shareware page.

Other projects

This is just one of the guides I have published on the net. Please visit any of the following that relate to interests you have....

Delphi Tutorials
Pascal programming tutorials
Electronics for hobbyists and schools
Main Home Page

Here is how you can contact this page's author, Tom Boyd.

Index of sensing and control pages (From there you can also go to other help from the editor of this page.)

Valid HTML 4.01 Transitional Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org



-- Page ends --