Searching \ for 'Anybody interfaced an AT Keyboard with a PIC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Anybody interfaced an AT Keyboard with a PIC'.

Truncated match.
PICList Thread
'Anybody interfaced an AT Keyboard with a PIC'
2000\05\29@165802 by John Hansen

flavicon
face
<x-flowed>I'm working on a project that involves interfacing an AT keyboard with a
PIC.  I'm following the documentation on
http://www.beyondlogic.org/keyboard/keybrd.htm
I've applied 5 volts to the keyboard and placed pull-up resistors across
both the data and clock lines from the keyboard.  When I look at the clock
output on a scope, I get just what I'd expect.  Looking at the data line,
however, always produces a low logic level.  This occurs even when I don't
have the data and clock lines attached to anything (except the
pull-ups).  Something in the keyboard is clearly pulling the data line low
and keeping there.  Pushing keys on the keyboard doesn't change anything,
the data line stays low.  Is it necessary to send a sequence to the
keyboard to get it to wake up and start sending data in response to
keypresses?  Thanks in advance for any assistance you might be able to provide.

John Hansen

</x-flowed>

2000\05\29@181841 by Mark Willis

flavicon
face
My guess:  You have a short in there somewhere.  That's an OC or OD
(open collector or open drain) driver, should never be held low like
that...  Pulled low sometimes when toggling the clock line, yes, but not
always.  Your pull-up resistor's tested good, I assume <G>

Cycling power should cause some activity from the keyboard (LED's should
flash and a little more) - NEVER should data be held low, as then the
host computer cannot talk TO the keyboard.  Something's wrong.

 Mark

John Hansen wrote:
{Quote hidden}

--
I re-ship for small US & overseas businesses, world-wide.
(For private individuals at cost; ask.)

2000\05\29@183752 by John Hansen

flavicon
face
<x-flowed>At 03:17 PM 5/29/00 -0700, you wrote:
>My guess:  You have a short in there somewhere.  That's an OC or OD
>(open collector or open drain) driver, should never be held low like
>that...  Pulled low sometimes when toggling the clock line, yes, but not
>always.  Your pull-up resistor's tested good, I assume <G>
>
>Cycling power should cause some activity from the keyboard (LED's should
>flash and a little more) - NEVER should data be held low, as then the
>host computer cannot talk TO the keyboard.  Something's wrong.
>
>   Mark

I have two keyboards that are behaving like this.  Both work well when
hooked to a PC.  One sticks the data line low, the other sticks it
high.  The first one has all LED's stuck on, the second has them
blinking.  A third keyboard, which I tried after the original post, seems
to work fine with exactly the same test set-up.   That is, on this third
board I get pulses on the scope for both data and clock lines when I push a
key.  Yet all three keyboards work fine when hooked to a PC.  Clearly the
two that don't work are older than the one that does, because they have the
older style din plug.  For the newer keyboard I'm using a minidin to din
adapter.  I'm wondering if there wasn't some sort of reset procedure
required on these older keyboards.

At least I now have one that's working that I can experiment with.

John Hansen

</x-flowed>

2000\05\29@213639 by Mark Willis

flavicon
face
mot-sps.com/mcu/documentation/pdf/an1723.pdf is a good additional
data source I just found on UseNet, BTW.

 Mark

2000\05\30@045628 by Alan B Pearce

face picon face
Your keyboards that keep the data line low are probably awaiting a reset command
from the PC before coming alive on the interface. Check the documentation
available on the web for how the PC resets these.

2000\05\30@051118 by Mark Willis

flavicon
face
I don't think that can be the case.  That's pretty durn inconsistent
with "S.O.P." on keyboards...  Said reset command, comes in via the
clock AND DATA lines - and REQUIRES the data line to be open collector
so (non-zero) data can be sent to the keyboard!  This is like having a
Dallas 1-wire device which pulls the single line low, then expects a
command to somehow manage to arrive in over that same line...
Something's broke or latched up or ???  (<EG>  This is also rather akin
to supergluing someone's hands to a Rhino, then criticizing them *when*
they don't wave goodbye <EG> but that's getting somewhat OT!)

I'm thinking to check the rise time on your 5V power for the keyboard
while waiting for me to get there (If it's too slow, perhaps the
keyboards are locking up - On a PC, the rise time's pretty fast IIRC.)

If that's not it, I'd try toggling the clock line to see if that happens
to unlatch things, is all I can come up with at this hour.  I should go
look at all the info I've notebooked together tomorrow.  A look at the
POST code in an AT's BIOS would be the first place I look, now where'd I
lose THAT at?  <G>

It's 2 AM and I'm rather "wiped", so maybe I'm forgetting something, of
course...

 Mark

Alan B Pearce wrote:
> Your keyboards that keep the data line low are probably awaiting a reset command
> from the PC before coming alive on the interface. Check the documentation
> available on the web for how the PC resets these.

2000\05\30@085842 by M. Adam Davis

flavicon
face
Are they all AT keyboards?

-Adam

John Hansen wrote:
{Quote hidden}

2000\05\30@133409 by John Hansen

flavicon
face
<x-flowed>Here are some more symptoms.  Any help would be appreciated.   I created a
program on a F84 that reads the data coming off the keyboard and displays
it on an LCD.  When I press a key on the keyboard (the keyboard that works)
I get 33 bits clocked in.  This is as expected since it should give me a 1C
when the key is pressed followed by an  F0 and a 1C when the key is
released.  Since there is a start bit, a parity bit and a stop bit, this
should produce 33 bits.   So far so good.  However, the bits that are
clocked in are not what are expected.  Instead of a 1C (which is supposed
to be the scan code for "a"), I get an 0x18.  I have the data line hooked
to pin B0 and the clock hooked to B1.  When I switched the data line to A4
(as Steve Lowthar has in his on-line code and schematic) the keyboard gives
me a 0x10.  Now you might be saying that the A4 pin needs a pull-up
resistor, but according to the keyboard documentation, pc keyboards contain
pull-ups on both the data and clock lines.  However, in any case, adding a
pull-up still produces a 0x10.  Interesting that the value read on this pin
changes depending upon whether it is read from pin B0 or pin A4.

I decide to try Steve Lowther's code and schematic for a 16C84 hooked to a
keyboard and an LCD display.  When in doubt, start with something you know
works, I figured.  I wired it up on a protoboard and burned the chip. He
uses B0 for clock (using it as an interrupt) and A4 for data.  It produces
the same 0x10 that I was getting from my code.  Also, the other two
keyboards don't work on his code either, leading me to believe that Mark is
right, no reset is required (Steve's source code doesn't show any).  Well,
the bottom line is that my code seems to be producing the same results as
his.  I conclude that there must be a problem with the hardware somewhere,
yet I've followed his schematic.  I wonder if the fact that I get a
different value from pin B0 and A4 provide any clues.  There is no
variability in the results produced: I always get 0x10 on A4 and 0x18 on B0.

Once again any thoughts would be appreciated.

John Hansen


At 02:10 AM 5/30/00 -0700, you wrote:
{Quote hidden}

</x-flowed>

2000\05\30@173104 by Don McKenzie

flavicon
face
John Hansen wrote:

> I decide to try Steve Lowther's code and schematic for a 16C84 hooked to a
> keyboard and an LCD display.  When in doubt, start with something you know
> works, I figured.  I wired it up on a protoboard and burned the chip. He
> uses B0 for clock (using it as an interrupt) and A4 for data.  It produces
> the same 0x10 that I was getting from my code.  Also, the other two
> keyboards don't work on his code either, leading me to believe that Mark is
> right, no reset is required (Steve's source code doesn't show any).  Well,
> the bottom line is that my code seems to be producing the same results as
> his.  I conclude that there must be a problem with the hardware somewhere,
> yet I've followed his schematic.  I wonder if the fact that I get a
> different value from pin B0 and A4 provide any clues.  There is no
> variability in the results produced: I always get 0x10 on A4 and 0x18 on B0.
>
> Once again any thoughts would be appreciated.

There is a heap of info at:
http://www.dontronics.com/dt102.html

includes source code.
this may help you.

Don McKenzie    spam_OUTdonTakeThisOuTspamdontronics.com      http://www.dontronics.com

The World's Largest Range of Atmel/AVR  & PICmicro Hardware and Software
Free Basic Compiler and Programmer http://www.dontronics.com/runavr.html
The Little "rAVeR!" AVR & Basic Kit http://www.dontronics.com/dt006.html

2000\05\30@230845 by John Hansen

flavicon
face
<x-flowed>One other item.  I seem to be transmitting commands to the keyboard just
fine.  For example, I can command it to turn on it's LED's by sending it an
0xED, waiting for an acknowledgment and then sending a 0x03.  The
acknowledgment, however is supposed to be an FA but I get an F0
instead.  I've noticed that it is sometimes interpreting ones as zeros, but
it is never interpreting zeros as ones.  So the data line isn't high when
it's supposed to be.  I'm pretty sure I'm not missing bits because I am
seeing exactly 33 clock cycles.  I've tried an external pull-up on the data
line and I've also tried enabling the internal Port B pull-ups.  I'm
getting consistent data out of the keyboard... that is, what is supposed to
be FA is always F0, for example.  I've checked the power supply to make
sure it is a solid 5 volts.  Anybody think of anything else worth trying?
... it seems like I'm so close on this.

John




{Quote hidden}

</x-flowed>

2000\05\31@003933 by Andrew

flavicon
face
Hi,

it could be a problem with rise time of the data line. if you are sampling close
to the start of the bit, then you may read a one as zero, try sampling the bit in
the middle, or to be even more sure, sample it several times during each bit.

Andrew

John Hansen wrote:

{Quote hidden}

--
Andrew Thoms
    Software Engineer
    Fac Engineering
    University of Technology, Sydney
    No 1 Broadway, Broadway 2007
    NSW, Australia

2000\05\31@070447 by Bob Ammerman

picon face
Are you sure you are sampling your data on (actually after) the correct edge
of the clock?

Are you grabbing the data too late (or possibly too soon)?

Good luck!

Bob Ammerman
RAm Systems
(high function, high performance, low level software)


{Original Message removed}

2000\05\31@074648 by Kčbek Tony

flavicon
face
Hi,
not really but the other way around ( made an keyboard emulator ).
Take a look at:

www.piclist.com/techref/default.asp?from=/techref/piclist/../micr
ochip/&url=picboard.htm

BTW which seems to be down at the moment ?

Anyway might give You some ideas.

As far as I can recall the data is changed in the middle of an
clockpulse but should not be read until clock goes low.


/Tony



Tony KŸbek, Flintab AB            
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: .....tony.kubekKILLspamspam@spam@flintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ

2000\05\31@124640 by Jason Harper

picon face
> Anybody think of anything else worth trying?

Just a wild guess, but are you sure you're sampling the data line on the
proper edge (rising or falling) of the clock line?

2000\05\31@154701 by John Hansen

flavicon
face
<x-flowed>At 01:28 PM 5/31/00 +0200, you wrote:
>Hi,
>not really but the other way around ( made an keyboard emulator ).
>Take a look at:
>
>www.piclist.com/techref/default.asp?from=/techref/piclist/../micr
>ochip/&url=picboard.htm
>
>BTW which seems to be down at the moment ?
>
>Anyway might give You some ideas.
>
>As far as I can recall the data is changed in the middle of an
>clockpulse but should not be read until clock goes low.

I had thought of that... put at 15 us delay in after sensing the falling
edge of the clock, but no joy.  Thanks for the idea, I'll take a look at
the page referenced.

John

</x-flowed>


'Anybody interfaced an AT Keyboard with a PIC'
2000\06\02@045103 by Kčbek Tony
flavicon
face
Hi again,
Another thing, the timing between the keyboard and PC
can vary between keyboards, You knew that right ?
I.e. the exact communication ( bps ) speed is not fixed.
Loggin my own keyboard ( Keytronic ) is uses an clock rate of 40 us.
I implemented 50us and 65 us and everything still worked aginst my PC.

/Tony




Tony KŸbek, Flintab AB            
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: tony.kubekspamKILLspamflintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ

2000\06\03@112529 by Dan Michaels

flavicon
face
John Hansen wrote:
> I'm working on a project that involves interfacing an AT keyboard with a
> PIC.  I'm following the documentation on
.....
>

Hi, I ran across the following design note in Feb 3, 2000 EDN mag,
which may provide some useful info. Datacq inline with PC keyboard,
using a PIC12C671 - inc schematic and sourcecode.

"Keyboard data-acquisition system is cheap and simple"

http://www.ednmag.com/ednmag/reg/2000/02032000/designideas.htm

best regards,
- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\06\05@103137 by jamesnewton

face picon face
You can also get to that page via
http://www.piclist.com/../microchip/picboard
if you have JavaScript enabled in your browser or via
www.piclist.com/techref/default.asp?url=microchip/picboard
if you don't

---
James Newton (PICList Admin #3)
.....jamesnewtonKILLspamspam.....piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org


{Original Message removed}

2000\06\13@145355 by Andrew Kunz

flavicon
face
Only part of the source code is there.  All the routines that do the real magic
are not in the ZIP file.

Neat idea, though!

Andy










Dan Michaels <EraseMEoricomspam_OUTspamTakeThisOuTLYNX.SNI.NET> on 06/03/2000 11:16:37 AM

Please respond to pic microcontroller discussion list <PICLISTspamspam_OUTMITVMA.MIT.EDU>








To:      @spam@PICLISTKILLspamspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Anybody interfaced an AT Keyboard with a PIC








John Hansen wrote:
> I'm working on a project that involves interfacing an AT keyboard with a
> PIC.  I'm following the documentation on
.....
>

Hi, I ran across the following design note in Feb 3, 2000 EDN mag,
which may provide some useful info. Datacq inline with PC keyboard,
using a PIC12C671 - inc schematic and sourcecode.

"Keyboard data-acquisition system is cheap and simple"

http://www.ednmag.com/ednmag/reg/2000/02032000/designideas.htm

best regards,
- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...