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
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
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.
I've used the larger Atmel ATmega range a fair bit, and a lot of other micro's (I do embedded development), and I'd recommend choosing the cheapest part with the hardware UART built in, for this kind of project. It will save you some work, be portable to other processors easily, and have absolutely no issues with lost keypresses, weird interrupt bugs, and buffering storage of multiple keypresss or codes coming from the keyboard (either fast typing or multi-byte key commands). In the long run to make a low volume it should work out a lot easier... Best regards, Marc
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
Also being a microcontroller programmer (mostly with PICs), I agree to using the larger more advanced part with the built in hardware UART. Its just not worth trying to squeeze everything out of a lower capability part unless you are trying to save costs for thousands of units. I would be glad to help if a PIC is chosen with code (ASM or C) and testing. I have an ICE with pods for 16c5x, 16c6x and 16c7x. I have a Fluke Programmers keyboard and 2 programmers stations (ie, with video cards) for testing. I can also program nearly any microcontroller (Labtool-48) and can route out some proto boards with the PCB mill. I'm happy to help with this project.
This is going to sound real naive, but why not just slap two connectors on a BASICstamp? The routines for sending the data to the Fluke is already there. The circuit board is already there. (Just a suggestion, I'll go hide under the coach while you all tell me why that doesn't work). Corey Stup wrote:
Also being a microcontroller programmer (mostly with PICs), I agree to using the larger more advanced part with the built in hardware UART. Its just not worth trying to squeeze everything out of a lower capability part unless you are trying to save costs for thousands of units. I would be glad to help if a PIC is chosen with code (ASM or C) and testing. I have an ICE with pods for 16c5x, 16c6x and 16c7x.
I have a Fluke Programmers keyboard and 2 programmers stations (ie, with video cards) for testing. I can also program nearly any microcontroller (Labtool-48) and can route out some proto boards with the PCB mill.
I'm happy to help with this project.
Well I have no experience with microcontrollers of any nature. And the circuit I found that started me on this path used a PIC, then I found the atmell app notes. Figure if someone already has done the hard work I can put the package together. I bet ya the basic stamp would work fine. I just don't have one. :) David ----- Original Message ----- From: "Rodger Boots" <rlboots@cedar-rapids.net> To: <techtoolslist@flippers.com> Sent: Wednesday, June 04, 2003 11:54 AM Subject: Re: 9100 keyboard wedge (udpate 2)
This is going to sound real naive, but why not just slap two connectors on a BASICstamp? The routines for sending the data to the Fluke is already there. The circuit board is already there.
(Just a suggestion, I'll go hide under the coach while you all tell me why that doesn't work).
Corey Stup wrote:
Also being a microcontroller programmer (mostly with PICs), I agree to using the larger more advanced part with the built in hardware UART. Its just not worth trying to squeeze everything out of a lower capability part unless you are trying to save costs for thousands of units. I would be glad to help if a PIC is chosen with code (ASM or C) and testing. I have an ICE with pods for 16c5x, 16c6x and 16c7x.
I have a Fluke Programmers keyboard and 2 programmers stations (ie, with video cards) for testing. I can also program nearly any microcontroller (Labtool-48) and can route out some proto boards with the PCB mill.
I'm happy to help with this project.
Been a while but thought I would send an update. I got the Atmel STK500 dev board, not bad, though would have liked some prototype area on it. I have tried the CodeVisionAVR C compiler and ImageCraft ICC C compiler. ICC is slightly better but that isn't saying much. DAMN, are all embeded tools this rough? I am a windows programer by occupation, used to nice robust MS Visual Studio development IDE. ICC costs more than MSVS but isn't even the quality level of MSVS 1.0. And debuging by flashing led is a big step back in time for me from what I am used to :) I have sucessfully proof of concepted the wedge, I can now take PC keyboard (AT102) input and output ASCII serial using an 8515 part. As a note this has taken me about 20 hours so far. Building the keyboard adapter (10 hours lost when I had a wire in the wrong spot but thought it was a software bug). Finding / downloading / installing various C packages in hopes that one didn't suck too bad. Next steps: Check on the status of the loaner 9100 keyboard that is on the way. Determine the keys I want to emulate from the 9100 keyboard. Expect all but perhaps not. Build the AT102 -> 9100 keyboard map table up (what 9100 keys map to what AT102 keys) Build the scancode to 9100 table (useing Kev's table) Figure out what the 9100 expects in response to a keyboard reset. At that point I should have a workable solution using the 8515. This is a 40 pin part and way overkill. Then I will start on the cost reduction part. Move to the 2313 (20 pin part with UART, still overkill). Then finaly try to move to the 2323 (an 8 pin part) with a software UART. As an asside, I will be trying to convince MSVS to build a project using the AVRGCC compiler as an external build step. I have a couple of other projects with hard stop deadlines of the 4th of July so will be setting this stuff on the shelf temporarily. Oh one last thing. For someone who has a working program station setup. If you hook the monitor up but not the keyboard do you get anything on screen? What about if you hit the EDIT button on the 9100? I am trying to see if my monitor is going to work or not (Commodore 1084-D) and am getting nothing on screen. David
You will not get the machine to go to the EDIT without a working keyboard, as the keyboard sends a simple response to the RESET signal (when you press the EDIT key). I have been able to fool the 9100 by simply plugging in a keyboard as I press the EDIT key. It will often switch to the blue screen then - and be completely unusable of course without the keyboard - the 9100's built-in keyboard is inactive for some stupid reason at this point....why I don't know - would have been a nice option. John :-#)# At 10:40 PM 23/06/2003 -0700, David Shoemaker wrote:
.... Oh one last thing. For someone who has a working program station setup. If you hook the monitor up but not the keyboard do you get anything on screen? What about if you hit the EDIT button on the 9100? I am trying to see if my monitor is going to work or not (Commodore 1084-D) and am getting nothing on screen.
David
participants (6)
-
Corey Stup -
David Shoemaker -
John Robertson -
Marc Alexander -
Rodger Boots -
Zonn