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
Received on Wed Jun 04 07:52:19 2003
This archive was generated by hypermail 2.1.8 : Tue Dec 02 2003 - 18:40:52 EST