PIC, Keyboard, and USART

I'm going to try to program a simple keyboard translator using the PIC2455
which has a built in EUSART. At this point I just want to get the keyboard
codes into the pic and I just want to run this by you guys to make sure I'm
on the right track.

1. Setup hardware. Basicaly just have to connect the Data and Clock lines to
the EUSART pins on the pic
2. Enable the USART on the pic for Asynchronous mode and enable auto baud
rate dection(to make it easy).
3. Read the RCREG in the interrupt and do whatever with it(like make an LED
blink on certain codes).

Is that basicaly all I have to do? Do I need to use pullups or anything
when connecting the lines or even use transistors to source/sink more
current?

(I'm running the keyboard off a 5V supply that can source up to .5mA or so)

Any potential pitfalls with this?

Thanks,
Jon

On Thu, 23 Mar 2006 11:38:05 -0600, "Abstract Dissonance"
<(E-Mail Removed)> wrote:

>I'm going to try to program a simple keyboard translator using the PIC2455
>which has a built in EUSART. At this point I just want to get the keyboard
>codes into the pic and I just want to run this by you guys to make sure I'm
>on the right track.

Are you talking about a PC keyboard?

><snip>
>Is that basicaly all I have to do? Do I need to use pullups or anything
>when connecting the lines or even use transistors to source/sink more
>current?

Is this a PC keyboard?

>(I'm running the keyboard off a 5V supply that can source up to .5mA or so)

1/2 an mA???

>Any potential pitfalls with this?

Could be. Is this a PC keyboard and are you really supplying it with
at most half a milliamp??

Jon

"Jonathan Kirwan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Thu, 23 Mar 2006 11:38:05 -0600, "Abstract Dissonance"
> <(E-Mail Removed)> wrote:
>
>>I'm going to try to program a simple keyboard translator using the PIC2455
>>which has a built in EUSART. At this point I just want to get the
>>keyboard
>>codes into the pic and I just want to run this by you guys to make sure
>>I'm
>>on the right track.
>
> Are you talking about a PC keyboard?
>

Yes, Ofcourse... isn't it obvious?
>><snip>
>>Is that basicaly all I have to do? Do I need to use pullups or anything
>>when connecting the lines or even use transistors to source/sink more
>>current?
>
> Is this a PC keyboard?
>
>>(I'm running the keyboard off a 5V supply that can source up to .5mA or
>>so)
>
> 1/2 an mA???
>

Ofcourse not!!! .5A

>>Any potential pitfalls with this?
>
> Could be. Is this a PC keyboard and are you really supplying it with
> at most half a milliamp??
>
> Jon

Jon

Abstract Dissonance wrote:
> I'm going to try to program a simple keyboard translator using the PIC2455
> which has a built in EUSART. At this point I just want to get the keyboard
> codes into the pic and I just want to run this by you guys to make sure I'm
> on the right track.
>
> 1. Setup hardware. Basicaly just have to connect the Data and Clock lines to
> the EUSART pins on the pic
> 2. Enable the USART on the pic for Asynchronous mode and enable auto baud
> rate dection(to make it easy).

No. You will need *synchronous* slave mode which uses the external
clock from the keyboard.

> 3. Read the RCREG in the interrupt and do whatever with it(like make an LED
> blink on certain codes).
>
> Is that basicaly all I have to do? Do I need to use pullups or anything
> when connecting the lines or even use transistors to source/sink more
> current?

Yes, use pullup resistors.

> (I'm running the keyboard off a 5V supply that can source up to .5mA or so)

The keyboard takes a lot more than 0.5mA!

Dave

I assume that you are talking about PC/AT keyboards here (or simply
known as "AT keyboards.") I think the original PC keyboard was
incompatible with the AT keyboard, but that all clones since that
advent are now following the AT keyboard arrangement and I doubt you
could even find a PC (non-AT) keyboard these days. Of course, I have
long since forgotten, for sure. Do check on what I'm saying.

Regarding AT keyboards, there is a very detailed electrical spec of
the hardware to be found in the IBM Technical Reference, Personal
Computer AT set (4 volume set, which I will protect with my life!)
That spec is the schematic itself, on page 17 of 22. They use '07
open-collector drivers tied to an RC filter, with 10k and 47pF.

+5
|
/
\ 10k
/
|
|\ |
>----| >-----+--------------+---O (either connector pin 1 or 2)
|/ | |
| |
--- |
--- |
| 47pF |
| |
--- |
/// |
|
|
<---------------------------'

That spells out the exact details of both pin 1 and pin 2. You should
be able to note that the IBM PC can use either line is input or
output. There is a reason for that design. If you intend to operate
the keyboard correctly, you will need to mimic it.

You will _also_ need to fully understand how the keyboard is properly
operated from the PC. It is discussed on pages 1-31 to 1-44 and all
of chapter 4 of that Technical Reference I mentioned. But in
particular there is the capability to observe aborts in transmission
and to deal with conflicts in securing the interface from one side or
the other.

I think that the technical details on the AT keyboard were fairly well
considered by IBM before laying them out and the proper operation of
the interface isn't entirely trivial, if you plan to get it right.
There are very specific timing issues you need to be aware of. Have
you searched the web for all this info? You should be aware of
something called the "BAT" and the power up exchanges, graceful
operation in the face of communication aborts, how to deal with
moments when both you and the keyboard decide to talk to each other,
etc.

Jon

"Jonathan Kirwan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I assume that you are talking about PC/AT keyboards here (or simply
> known as "AT keyboards.") I think the original PC keyboard was
> incompatible with the AT keyboard, but that all clones since that
> advent are now following the AT keyboard arrangement and I doubt you
> could even find a PC (non-AT) keyboard these days. Of course, I have
> long since forgotten, for sure. Do check on what I'm saying.
>
> Regarding AT keyboards, there is a very detailed electrical spec of
> the hardware to be found in the IBM Technical Reference, Personal
> Computer AT set (4 volume set, which I will protect with my life!)
> That spec is the schematic itself, on page 17 of 22. They use '07
> open-collector drivers tied to an RC filter, with 10k and 47pF.
>


Sheesh... that would be helpful to have. I wonder if one can download these
online now?



> +5
> |
> /
> \ 10k
> /
> |
> |\ |
> >----| >-----+--------------+---O (either connector pin 1 or 2)
> |/ | |
> | |
> --- |
> --- |
> | 47pF |
> | |
> --- |
> /// |
> |
> |
> <---------------------------'
>
> That spells out the exact details of both pin 1 and pin 2. You should
> be able to note that the IBM PC can use either line is input or
> output. There is a reason for that design. If you intend to operate
> the keyboard correctly, you will need to mimic it.
>

What is pin 1 and pin 2? The pins from the connectors? i.e., Data and Clock?
Is that an inverter(buffer I guess)? (i.e. a bidirection link with a
pullup and LP filter?)


> You will _also_ need to fully understand how the keyboard is properly
> operated from the PC. It is discussed on pages 1-31 to 1-44 and all
> of chapter 4 of that Technical Reference I mentioned. But in
> particular there is the capability to observe aborts in transmission
> and to deal with conflicts in securing the interface from one side or
> the other.
>
> I think that the technical details on the AT keyboard were fairly well
> considered by IBM before laying them out and the proper operation of
> the interface isn't entirely trivial, if you plan to get it right.
> There are very specific timing issues you need to be aware of. Have
> you searched the web for all this info? You should be aware of
> something called the "BAT" and the power up exchanges, graceful
> operation in the face of communication aborts, how to deal with
> moments when both you and the keyboard decide to talk to each other,
> etc.
>

What I have found on the net is not completely technical but just what
someone says works. Although they did point out certain issues they do not
go into the details.

> Jon


Thanks for the info. Its good to know there are technical specifications
out there for this... now I just have to get my hands on it.

Thanks again,
Jon

"David L. Jones" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Abstract Dissonance wrote:
>> I'm going to try to program a simple keyboard translator using the
>> PIC2455
>> which has a built in EUSART. At this point I just want to get the
>> keyboard
>> codes into the pic and I just want to run this by you guys to make sure
>> I'm
>> on the right track.
>>
>> 1. Setup hardware. Basicaly just have to connect the Data and Clock lines
>> to
>> the EUSART pins on the pic
>> 2. Enable the USART on the pic for Asynchronous mode and enable auto baud
>> rate dection(to make it easy).
>
> No. You will need *synchronous* slave mode which uses the external
> clock from the keyboard.
>

Why is this? Wouldn't the auto baud rate detect and interrupts work? I will
look at it though and see... I'm not to familiar with the different methods.
I was thinking that each time the clock pulsed it would trigger an interrupt
and you could read the data off the data line and store it... or something
like that.



>> 3. Read the RCREG in the interrupt and do whatever with it(like make an
>> LED
>> blink on certain codes).
>>
>> Is that basicaly all I have to do? Do I need to use pullups or anything
>> when connecting the lines or even use transistors to source/sink more
>> current?
>
> Yes, use pullup resistors.
>
>> (I'm running the keyboard off a 5V supply that can source up to .5mA or
>> so)
>
> The keyboard takes a lot more than 0.5mA!
>

Sure

> Dave
>

Thanks,
Jon

On Thu, 23 Mar 2006 15:48:39 -0600, "Abstract Dissonance"
<(E-Mail Removed)> wrote:

>"Jonathan Kirwan" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>>I assume that you are talking about PC/AT keyboards here (or simply
>> known as "AT keyboards.") I think the original PC keyboard was
>> incompatible with the AT keyboard, but that all clones since that
>> advent are now following the AT keyboard arrangement and I doubt you
>> could even find a PC (non-AT) keyboard these days. Of course, I have
>> long since forgotten, for sure. Do check on what I'm saying.
>>
>> Regarding AT keyboards, there is a very detailed electrical spec of
>> the hardware to be found in the IBM Technical Reference, Personal
>> Computer AT set (4 volume set, which I will protect with my life!)
>> That spec is the schematic itself, on page 17 of 22. They use '07
>> open-collector drivers tied to an RC filter, with 10k and 47pF.
>
>Sheesh... that would be helpful to have. I wonder if one can download these
>online now?

Not that I'm aware of. I would suppose that IBM still holds the
copyright to it -- it's not _that_ old, yet. I'd be happy to scan
them in and post them up, if permission to do so could be found. It's
irreplaceable. The set also includes _complete_ BIOS listings, as
well. It's fairly complete, as I said.

>> +5
>> |
>> /
>> \ 10k
>> /
>> |
>> |\ |
>> >----| >-----+--------------+---O (either connector pin 1 or 2)
>> |/ | |
>> | |
>> --- |
>> --- |
>> | 47pF |
>> | |
>> --- |
>> /// |
>> |
>> |
>> <---------------------------'
>>
>> That spells out the exact details of both pin 1 and pin 2. You should
>> be able to note that the IBM PC can use either line is input or
>> output. There is a reason for that design. If you intend to operate
>> the keyboard correctly, you will need to mimic it.
>
>What is pin 1 and pin 2? The pins from the connectors? i.e., Data and Clock?
>Is that an inverter(buffer I guess)? (i.e. a bidirection link with a
>pullup and LP filter?)

As I understand the connector from the schematic (no, I haven't done
keyboard experimentation on my own, so this isn't first hand), the
5-pin round DIN connector has pin 1 as clock and pin 2 as data. 3 is
no-connect, 4 is GND, and 5 is the +5 supply.

>> You will _also_ need to fully understand how the keyboard is properly
>> operated from the PC. It is discussed on pages 1-31 to 1-44 and all
>> of chapter 4 of that Technical Reference I mentioned. But in
>> particular there is the capability to observe aborts in transmission
>> and to deal with conflicts in securing the interface from one side or
>> the other.
>>
>> I think that the technical details on the AT keyboard were fairly well
>> considered by IBM before laying them out and the proper operation of
>> the interface isn't entirely trivial, if you plan to get it right.
>> There are very specific timing issues you need to be aware of. Have
>> you searched the web for all this info? You should be aware of
>> something called the "BAT" and the power up exchanges, graceful
>> operation in the face of communication aborts, how to deal with
>> moments when both you and the keyboard decide to talk to each other,
>> etc.
>
>What I have found on the net is not completely technical but just what
>someone says works. Although they did point out certain issues they do not
>go into the details.

Bad news.

>Thanks for the info. Its good to know there are technical specifications
>out there for this... now I just have to get my hands on it.

Yes. It should be available somewhere. I've not looked around. But
it should be out on the net, I'd hope.

Jon

On 23 Mar 2006 13:16:40 -0800, "David L. Jones" <(E-Mail Removed)>
wrote:

>Abstract Dissonance wrote:
>> I'm going to try to program a simple keyboard translator using the PIC2455
>> which has a built in EUSART. At this point I just want to get the keyboard
>> codes into the pic and I just want to run this by you guys to make sure I'm
>> on the right track.
>>
>> 1. Setup hardware. Basicaly just have to connect the Data and Clock lines to
>> the EUSART pins on the pic
>> 2. Enable the USART on the pic for Asynchronous mode and enable auto baud
>> rate dection(to make it easy).
>
>No. You will need *synchronous* slave mode which uses the external
>clock from the keyboard.
><snip>

Actually, the clock line should also be able to be driven by the
non-keyboard end of things, as well. The other end is responsible for
it's own clock driving action. These are bi-directional lines
supporting bi-directional communication and there is a negotiating
protocol that should be supported.

Jon

On Thu, 23 Mar 2006 21:56:06 GMT, I wrote:

><snip>
>>What is pin 1 and pin 2? The pins from the connectors? i.e., Data and Clock?
>>Is that an inverter(buffer I guess)? (i.e. a bidirection link with a
>>pullup and LP filter?)
>
>As I understand the connector from the schematic (no, I haven't done
>keyboard experimentation on my own, so this isn't first hand), the
>5-pin round DIN connector has pin 1 as clock and pin 2 as data. 3 is
>no-connect, 4 is GND, and 5 is the +5 supply.
><snip>

By the way, I'm not talking about USB keyboards. And I think the PS/2
keyboard connectors (which didn't exist when IBM was putting out that
doc set) are 6-pin, not 5. But the mapping should be findable on the
web. It's probably quite simple. (I have PS/2 to AT connector
adapter plugs that I'm pretty sure just route lines.) It's slightly
possible that the PS/2 keyboards have added to the specifications for
the older DIN 5 connector types, adding more protocols.

The older DIN-5 connector only used 4 conductors. Two power and two
signal. I have a weird USB-looking to PS/2-looking connector adapter
that shows a mouse symbol embossed on the PS/2 end. No idea what it
does, but it looks like it adapts something with a USB connector on it
so that it plugs into a PS/2 mouse adapter hole on a IBM PC/AT system.
So this makes me wonder about USB mice that can actually plug into a
plug normally designed for PS/2 mice. If so, I'm baffled as it seems
to suggest that USB might have been originally designed as an
electrically compatible, but software incompatible, interface. If so,
then it would be possible for a mouse with a USB connector on it to be
plugged into a PS/2 mouse port and to auto-detect which it is talking
with and switch protocols. So now I'm curious about that and
interested in looking much more closely at the USB electrical spec.

Jon