Re: 9100 keyboard wedge (udpate 2)

<x-flowed>
The 9100 does not care very much for the timing. I have been successful
using a PC with a terminal program to convert regular keyboard data to the
code required by the 9100. Kev had laid out the code a number of months
ago, I have a copy if you would like that.

Reading from one of my old IBM PC service manuals it is pointed out that
the keyboard actually sends TWO codes, when the key is pressed it sends a
'closed' scan code, and when it is released it sends an 'open' scan code.
Perhaps as the 9100 does not care about the 'open' scan code that as soon
as the 'close' scan code is sent then the Atmel converts that and it
ignores the 'open' scan code. That should be fast enough should it not?

Do you not have a 9100 with the keyboard interface? Or are you missing the
video card?

I would be happy to be a beta tester for the interface, I can hack the PCB
together from your diagram and program the Atmel chip with one of my
programmers if you send me the code. I have a 9100 sitting beside me with a
monitor hooked up...and no programmers keyboard.

John :-#)#

At 10:27 PM 03/06/2003 -0700, David Shoemaker wrote:

>Only problem is that the UART is only going to be used to feed the fluke.
>And the 9100 is a single wire interface so no handshake. The question will
>be just how accurate I can keep the timing on the output in software, and
>how sensitive the receiver in the 9100 is to timing. With Chris's help I
>found an app note on Atmels site about writing a software UART, it disables
>interrupts while transmitting, so no keyboard input can come in while it is
>sending a character.
>
>Going to have to figure out if that is going to cause too much trouble.
>
>Its going to take some playing with I am sure but software is my thing so I
>should be able to come up with some adaptation.
>
>Now comes a BIG question. Anyone have a real programmer's keyboard I could
>borrow for a bit (figure 1 to 2 months) while I work on this? I imagine it
>would be easier to verify I am doing everything right if I could throw a
>logic analyzer on the keyboard data stream and compare it to what I am
>spitting out.
>
>David
>
>----- Original Message -----
>From: "Zonn" <zonn@zonn.com>
>To: <techtoolslist@flippers.com>
>Sent: Tuesday, June 03, 2003 4:44 PM
>Subject: Re: 9100 keyboard wedge (udpate 2)
>
>
> >
> > On Tue, 03 Jun 2003 13:38:58 -0500, Rodger Boots
><rlboots@cedar-rapids.net>
> > wrote:
> >
> > >You may want to change your crystal frequency to some handy multiple of
> > >1200 baud. There's a good reason all those old com port boards used a
> > >1.8432 MHz crystal---it divided nicely to common baud rates.
> >
> > And I strongly recommend you go with the 2313 and use the UART in an
>interrupt
> > driven mode. This would allow you to write a software synchronous
>routines for
> > the PC keyboard and run the UART in the background without the loss of
> > characters. Asynchronous routines (UARTs) are much more complicate to
>write
> > that the Synchronous routine needed by the PC, having written both.
>(Though not
> > for the Atmel series since 99% of their parts have UARTs, I've always
>chosen a
> > part that has one if needed.)
> >
> > To receive a character in a software UART you must oversample the input
>bit by
> > at *least* four times to somewhat reliably read a character (hardware
>UARTs
> > oversample a minimum of 16 times), this pretty much means a very tight
>loop
> > during which you will miss keys being pressed on the PC's keyboard. UART
> > transmit routines are a bit simpler, though much stricter timing is
>required
> > than a synchronous port.
> >
> > On the other hand synchronous routines (where you generate a clock and
>data) are
> > not timing critical, so if a character is received by a hardware UART,
>causing
> > an interrupt to occur in the middle of your software synchronous routine,
>the
> > extra delay won't hurt anything, and no loss of characters will result.
> >
> > If you're worried about what to do with the extra I/O lines of the 2313,
>connect
> > LEDs to them and blink them as status lights as characters pass through
>the
> > board. *Everybody* likes blinking status lights. ;-)
> >
> > -Zonn

</x-flowed>
Received on Wed Jun 04 09:41:29 2003