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