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