Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

AT keyboard with 8051 µC

Status
Not open for further replies.

mcs51mc

Member
Hi there,

I managed to connect an AT keyboard to a 8051µC :D
At the start of the code I managed to lid the led's one by one and then turn them all off at once. So far so good :D

Now I'm trying to lid the NumLock led when the NumLock key is pressed.
Eveything works fine but when I look at the signals on the scoop I noticed some strange things.

File NumLock key pressed
0) Data line is first set low by keyboard, then comes the clock.
1) When all data is send the data line remain at a high level.
2) The 520µs Clock low at the end of the zoomed area is due to processing time of received byte.

File NumLock key released
Reveiving bytes 0F0h and 77h from keyboard, data line high at start, 2 times 11 clock pulses and finally processing time by µC while clock driven low by µC
First strange thing:
Why is the data line going low after processing the second byte??? First byte ok but not second one :(

File NumLock LED On
Three packages:
1) Command 0EDh to keyboard
2) Data for led's
3) ACK from keyboard
Second strange thing
Why is the data line going low BEFORE the falling edge of the clock when sending the data for the led's?

The signals I measure don't match the ones described here: **broken link removed** especially the ones for µC to Keyboard :(

Do I need to send something more to the keyboard, set/reset the data line myself after receiving data, ... ...?

All suggestions are welcome :eek:
 

Attachments

  • NumLock key pressed.jpg
    NumLock key pressed.jpg
    258.5 KB · Views: 909
  • NumLock key released.jpg
    NumLock key released.jpg
    258 KB · Views: 569
  • NumLock LED On.jpg
    NumLock LED On.jpg
    260.7 KB · Views: 572
Almost one week later, still no reactions :(
No one ever did such thing?

No longer worry about it, problem solved :)
Instead of using the keyboard in mode 2 (default) I set it up in mode 3 with only make code!
 
All is writting in assembly.
About the tutorial, if anyone has a specific question about this matter I'm always prepared to answer or at least tell how I do it :)

I can already tell you that:
A) P1.1 is used for Keyboard Data line
B) P3.2 is used for Keyboard Clock line
C) The code is interrupt driven on the clock signal of the keyboard
D) All keys a-z; A-Z; 0-9, and other printable characters returns the equivalent ascii code to the main program.
E) All other keys return a specific code from 0A0h to 0C7h so that the main program knows what key is pressed (see list below)
F) Some special keyboard codes like "Reset ok (0AAh)", "Acknowledge (0FAh)" and "Reset failed (0FCh)" are handled others not :eek:

The major advantage of interrupt driven code instead of waiting on clock edges with
Code:
jnb     KEYB_CLOCK, $
jb      KEYB_CLOCK, $
is that there is no waste of processor time :)
The time before the keyboard generates a clocksignal after the µC initiate a write cycle can vary from 94µs to 2.2ms.
As you know 2.2ms is a lot of instructions :D:D

Own codes for all nonprintable keys:
Code:
Keyb_Esc			equ	00A0h
Keyb_F1			equ	00A1h
Keyb_F2			equ	00A2h
Keyb_F3			equ	00A3h
Keyb_F4			equ	00A4h
Keyb_F5			equ	00A5h
Keyb_F6			equ	00A6h
Keyb_F7			equ	00A7h
Keyb_F8			equ	00A8h
Keyb_F9			equ	00A9h
Keyb_F10		equ	00AAh
Keyb_F11		equ	00ABh
Keyb_F12		equ	00ACh
Keyb_23			equ	00ADh
Keyb_Backspace		equ	00AEh
Keyb_Tab		equ	00AFh
Keyb_Enter		equ	00B0h
Keyb_Percent		equ	00B1h
Keyb_Pound		equ	00B2h
Keyb_ShiftL		equ	00B3h
Keyb_ShiftR		equ	00B4h
Keyb_CtrlL		equ        00B5h
Keyb_WindowsL		equ	00B6h
Keyb_Alt			equ	00B7h
Keyb_AltGr		equ	00B8h
Keyb_WindowsR		equ	00B9h
Keyb_ShortCutMenu	equ	00BAh
Keyb_CtrlR		equ	00BBh
Keyb_PrintScr		equ	00BCh
Keyb_Pause		equ	00BDh
Keyb_Insert		equ	00BEh
Keyb_Home		equ	00BFh
Keyb_PageUp		equ	00C0h
Keyb_Delete		equ	00C1h
Keyb_End		equ	00C2h
Keyb_PageDown		equ	00C3h
Keyb_ArrowUp		equ	00C4h
Keyb_ArrowLeft		equ	00C5h
Keyb_ArrowDown		equ	00C6h
Keyb_ArrowRight		equ	00C7h
 
interface AT keyboard

hi all,

I have done a project which interfaced AT keyboard and television set.
The project used microcontroller AT8952 as central proccessing unit.
I used C language to writting the code.
My code could posibly identify the normal key press, but there was
problem when it received the extended key press. For example:
E0 75 (arrow key). I had some question:
Did each of these (E0 or 75) transmit with a frame of 11 bits yet?
How could I posibly identify these extented keys?
I looking forward to hearing from all of you.
My email : belcooo@yahoo.com.vn

thanks,
 
hey.. mcs51...

Hi,

you look superb in designing with 89c51..

Please Answer some general Questions that can help me..

1. Can we interface ps2 keyboard with same easiness as we are interfacing AT keyboard..

2. is everything available at beyondlogic.org..

Regards,

Simran..:)
 
@simrantogether:

Are you asking us to visit beyondlogic.org and report back to you what we find?

You appear to be connected to the internet....
 
belcooo said:
I had some question:
Did each of these (E0 or 75) transmit with a frame of 11 bits yet?
Yes
belcooo said:
How could I posibly identify these extented keys?
By decoding all incoming bytes of course :)

That's the problem with a keyboard in normal mode :(
Some keys send 1 byte for make code, 2 for break code
Some keys send 2 bytes for make code, 3 for break code
One key send 8 bytes for make code, 9 for break code

Another problem is the order of the bytes
1 byte keys make code: 15 vs break code F0 15
2 byte keys make code: E0 14 vs break code E0 F0 14 : Why not F0 E0 14 :(

That's why I used mode 3:
One byte for each key and no break code.
Depends on what you intend to do with the keyboard but I think mode 3 is fair enough for a µC application...
 
Last edited:
simrantogether said:
1. Can we interface ps2 keyboard with same easiness as we are interfacing AT keyboard..
Explain me the difference between ps2 and AT first...
I think ps2 is hardware related, you know type of connector (ps2 vs DIN plug)
AT is .... (key lay out?)

simrantogether said:
2. is everything available at beyondlogic.org..
Depends on what you want :D
 
mcs51mc said:
Another problem is the order of the bytes
1 byte keys make code: 15 vs break code F0 15
2 byte keys make code: E0 14 vs break code E0 F0 14 : Why not F0 E0 14 :(

Don't think of the byte "E0" as a make code, think of it as a prefix for "Extended" keyset. Then the make code becomes 14 and the break code is F0 14. Makes good logic sense to me.

Whenever you see "E0", switch to use another lookup table to translate the make code and break code.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top