I got it working on a PIC16F628... So it should be too difficult to convert. I use RB0 for the clock, as it would (in the future) allow me to use interrupts for the clock. I use RA6 for the data input. I know how risky it is to show code on this list, because one is bound to get comments on coding style, but it might be helpful. Here is the code to get the scancode (not ASCII) from the keyboard, and store it in "Keyboard".
getKeyboard
movlw 0x08 ; Eight bits to a keyboard byte
movwf t2 ; Store
KeyboardNextBit
btfsc PORTB,0 ; Wait for clock line to change
goto $-1
bsf STATUS,C ; Assume a 1
btfss PORTA,6 ; Check the data bit
bcf STATUS,C ; It wasn't 1, so 0
rrf Keyboard,f ; Move the carry into the keyboard
btfss PORTB,0 ; Wait for the clock line to change
goto $-1
decfsz t2,f ; Get the next bit
goto KeyboardNextBit
btfsc PORTB,0 ; Ignore the parity bit
goto $-1
btfss PORTB,0 ; Make sure clock becomes high
goto $-1
return
Let me see... People will probably comment the use of goto $-1 (as it isn't compatible with >16F PICmicros) although it makes for very concise waits. Then there are several hardcoded numbers (like the number of bits in a scancode byte, and the location of the ports) that probably should become defines in some way. Then there is the badly named "t2" from "teller twee", and there are various pieces of code that might be better if they were a macro ("KB_WAIT(state)" is an idea). Of course, as said originally, the whole thing would look much better in an interrupt on clock line change anyway. One advantage of this code: I tested it and it works.
Greetings,
Maarten Hofman.
Are you doing this for the experience? Or do you have a need to be met
(or both)?
I have the 'F84 code to take an AT style keyboard as input and output to
an LCD screen and RS-232. It isn't original - I got it from someone
whose name escapes me at the moment (it's been a looooong time ago!). It
had a few minor bugs that are easily remedied - mostly with the keyboard
translation. I think I still have the repaired code also. I never quite
finished everything I set out to accomplish with this code since it was
for personal use and I had other obligations at the time.
It DOES work, however. If you want it, send me your email address
offline and I'll forward it to you.
What I like about the coding style is the use of COMMENTS!!! Makes the
code very readable to me. I've recently been struggling to port some code
written for Windoze to C18. There's maybe 3 or 4 lines of comments per
page, a 1 line comment at the top of a block of code with no comments on
the lines of code. After several days of messing with it, I finally said,
"I think this is what it's supposed to do" and wrote about 20 lines of
commented C to replace the 7 pages of stuff. Seems to work. Also, years
ago, I taught a class in PDP-8 assembly language programming (using
Teletypes and punched tape!). I had students get their code working
without comments, then add comments for my benefit (and for their grade's
benefit). Unfortunately, by the time they added the comments, they forgot
how the code worked, so the comments did not describe what the code was
doing...
> Rochester, 26 augustus 2005.
>
> Dear Lukas,
>
> I got it working on a PIC16F628... So it should be too difficult to
> convert..
> I use RB0 for the clock, as it would (in the future) allow me to use
> interrupts for the clock. I use RA6 for the data input. I know how risky
> it
> is to show code on this list, because one is bound to get comments on
> coding
> style, but it might be helpful. Here is the code to get the scancode (not
> ASCII) from the keyboard, and store it in "Keyboard".
>
> getKeyboard
> movlw 0x08 ; Eight bits to a keyboard byte
> movwf t2 ; Store
> KeyboardNextBit
> btfsc PORTB,0 ; Wait for clock line to change
> goto $-1
> bsf STATUS,C ; Assume a 1
> btfss PORTA,6 ; Check the data bit
> bcf STATUS,C ; It wasn't 1, so 0
> rrf Keyboard,f ; Move the carry into the keyboard
> btfss PORTB,0 ; Wait for the clock line to change
> goto $-1
> decfsz t2,f ; Get the next bit
> goto KeyboardNextBit
> btfsc PORTB,0 ; Ignore the parity bit
> goto $-1
> btfss PORTB,0 ; Make sure clock becomes high
> goto $-1
> return
>
> Let me see... People will probably comment the use of goto $-1 (as it
> isn't
> compatible with >16F PICmicros) although it makes for very concise waits.
> Then there are several hardcoded numbers (like the number of bits in a
> scancode byte, and the location of the ports) that probably should become
> defines in some way. Then there is the badly named "t2" from "teller
> twee",
> and there are various pieces of code that might be better if they were a
> macro ("KB_WAIT(state)" is an idea). Of course, as said originally, the
> whole thing would look much better in an interrupt on clock line change
> anyway. One advantage of this code: I tested it and it works.
> Greetings,
> Maarten Hofman.
>
> On the subject, does anyone know the current draw of the keyboard?
Yes, that was something that concerned me too, as I'm building a battery powered device. I did lots of research on this topic, and came to the conclusion that keyboards draw a LOT of current. The lowest I found so far was 35 mA. Dell keyboards are actually pretty good, at 75 mA. Most clone keyboards draw 250-300mA. Of course, part of the draw are the LED, so if you make sure the LED are off then the only time the high current is drawn is when the keyboard boots up (it lights up all three LEDs during that time). The worst keyboard I found drew 2A. Note that these are all peak draws, specified by the manufacturer. Normal use might be lower.
Maarten Hofman wrote:
>>On the subject, does anyone know the current draw of the keyboard?
>
> Yes, that was something that concerned me too, as I'm building a battery
> powered device. I did lots of research on this topic, and came to the
> conclusion that keyboards draw a LOT of current.
I have NO measurements to report, but FWIW, I've been running an IBM
(brand) PS/2 keyboard off of a 9V battery with a PIC, and I've had it
running for many 5-10 minute intervals and one or two times I
accidentally left it on for maybe an hour. Still running off the same
9V. Typically, the LEDs are off (I don't use them, though I can't
remember if they're ever turned on by the keyboard itself).
> What I like about the coding style is the use of COMMENTS!!!
> Makes the code very readable to me. I've recently been
> struggling to port some code written for Windoze to C18.
> There's maybe 3 or 4 lines of comments per page, a 1 line
> comment at the top of a block of code with no comments on the
> lines of code. After several days of messing with it, I
> finally said, "I think this is what it's supposed to do" and
> wrote about 20 lines of commented C to replace the 7 pages of
> stuff. Seems to work. Also, years ago, I taught a class in
> PDP-8 assembly language programming (using Teletypes and
> punched tape!). I had students get their code working without
> comments, then add comments for my benefit (and for their
> grade's benefit). Unfortunately, by the time they added the
> comments, they forgot how the code worked, so the comments
> did not describe what the code was doing...
>
> So, THANKS FOR COMMENTING YOUR CODE!
I'll echo that. But I must say that I expected to find that I was reading a
reply from Olin...
...I was rather surprised when my eyes next came to:
>
> Harold
>
The PC specification says that they may draw as much as 300 ma. As a
practical matter, I've yet to find one that draws anywhere near that.
The one's I've measured come in between 80 and 110 ma. But they would
not be out of spec to draw considerably more.
> Maarten Hofman wrote:
>
>>> On the subject, does anyone know the current draw of the keyboard?
>>
>>
>> Yes, that was something that concerned me too, as I'm building a
>> battery powered device. I did lots of research on this topic, and
>> came to the conclusion that keyboards draw a LOT of current.
>
>
> I have NO measurements to report, but FWIW, I've been running an IBM
> (brand) PS/2 keyboard off of a 9V battery with a PIC, and I've had it
> running for many 5-10 minute intervals and one or two times I
> accidentally left it on for maybe an hour. Still running off the same
> 9V. Typically, the LEDs are off (I don't use them, though I can't
> remember if they're ever turned on by the keyboard itself).
>
> I can do a simple check with a meter this weekend if anyone's interested.
I'll be glad to post the code, only I didn't write the original - just
added some things to it and fixed a few bugs.
The code was written by a gentleman from Switzerland, named Peter
Luethi. I got it off the 'Net - thought SURE it was from the PICLIST
Ring!!. If you wish, I'll try to relocate it. It would DEFINITELY fail
Olin's perusal (as it did mine). However, I wasn't in the mood to
re-invent the wheel, so I used it in it's present form.
Additionally, I have a personally modified version that runs on a 16F74
that also processes digital I/O and analog inputs, sending the results
up the RS-232 link to a PC. Got a few bugs to iron out of it when I have
some spare time & I can contribute that also.
You're quite welcome. Unfortunately I did some additional testing at home, and it turned out that there WAS a bug in my code. It turns out that the PS/2 keyboard sends a "start" bit, which my code did not remove. I therefore recommend either adding code to check this start bit (better way), or increasing the number of bits in a keyboard byte to 9:
> getKeyboard
> > ; movlw 0x08 ; Eight bits to a keyboard byte -> WRONG!
>
movlw 0x09 ; Nine bits to a keyboard byte (start bit + 8 bits)
> movwf t2 ; Store
> > KeyboardNextBit
> > btfsc PORTB,0 ; Wait for clock line to change
> > goto $-1
> > bsf STATUS,C ; Assume a 1
> > btfss PORTA,6 ; Check the data bit
> > bcf STATUS,C ; It wasn't 1, so 0
> > rrf Keyboard,f ; Move the carry into the keyboard
> > btfss PORTB,0 ; Wait for the clock line to change
> > goto $-1
> > decfsz t2,f ; Get the next bit
> > goto KeyboardNextBit
> > btfsc PORTB,0 ; Ignore the parity bit
> > goto $-1
> > btfss PORTB,0 ; Make sure clock becomes high
> > goto $-1
> > return
>
Denny Esterline wrote:
>>I can do a simple check with a meter this weekend if anyone's interested.
>
> Yes, please.
When I have just the PIC16F688 and keyboard drawing power, it's around 6
mA total. I can see a slight change when I press keys - maybe 0.2 mA.
This is with all LEDs off on the keyboard; I never send any commands to
turn them on, so they're off after the keyboard starts up and they stay
off even if I press Caps Lock, Num Lock, or Scroll Lock.
--
Timothy J. Weber http://www.lightlink.com/tjweber tjweberspam_OUTlightlink.com
piclist.com 1-619-652-0593 phone
