I am working with a serial Keyboard and I would like to use my MCU as a middleman, which can forward the char along the uart to my PuTTY client. My first question is - How can I have two devices hooked up to the RxD/TxD lines? I believe my keyboards TxD needs to go to the MCU's RxD, and the MCU's TxD needs to go to the USB's RxD(Green?). That is one lane of communication covered. Now, the USBs TxD(Yellow?) goes to the MCU's RxD...which is already hooked up to receive from the keyboard. So even if I implement some sort of firmware switching, there are bound to be collisions. Same problem arises for transmitting from the CPU.

My second question is - Does the communication HAVE to be two way between the Keyboard and MCU, and the MCU and the PC? My gut tells me yes so that at bare minimum one can know when the other is ready?

Thanks in advance for all your help!

Hi Twarter,

UART is not really meant to be a bus protocol. It's built for communicating between two devices. I believe ther are ways to multiplex them, but it will require some thinking.

Are you sure your keyboard is using a UART protocol? Old style PS/2 keyboards use a very simple clocked protocol. You can (with a little bit of work) write your own reader for it.

If you don't take into account programming the chip, and you only need to send data from your chip to the computer, then you are correct that you only need one pin. The same would be true the other direction with your keyboard if in fact it is using a UART protocol (and the interface is such that the keyboard just sends the characters without needing any sort of commands from the chip)

Humberto

I am pretty sure it is UART. The pinout I have come across doesn't show a CLK line at all.

We have

DB9F Signal Cradle Signal 1 CD
2 RXD 6 TXD 3 TXD 8 RXD 4 DTR
5 GND 1 GND 6 DSR 10 Gen.Purpose Output 7 RTS 5 CTS 8 CTS 7 RTS 9 RI
Shield 10nF capacitor to ground
4 HotSync switch 9 HotSync switch live (to 3.3V via 330 ohms) 3 Gen.Purpose Input 2 NC

It is my understanding that I use RTS from the Keyboard to the MCU to let the MCU know that the Keyboard wants to send. Then the MCU sends back a response on the CTS line. When the Keyboard gets the signal on CTS it transmits the byte along the TxD line, which in turn is received by the MCU's RxD line.

I don't strictly NEED my computer to be able to send a response back to the MCU. If I can get a character to go from the keyboard to the MCU and have the MCU forward it (if required)to my PC.

I am noobalicious when it comes to determining protocols and such. I figured that the RxD/TxD and the RTS/CTS combination meant it was RS232 (serial). If this is incorrect, or there is an easier way to do this then please let me know, because I have read of people successfully integrating this keyboard for a Morse Coder, which essentially performs MORE functions than I need, because I don't need to translate the code before I forward it.

For those of us that are more visual, here is the keyboard I am working with

Hmm, the table I inserted got messed up, here is a link that describes how the palm proprietary connector is connected. http://pinouts.ru/PDA/palm_pilot_pinout.shtml

That definitely looks like some sort of UART like interface. Have you tried a simple interface connecting just the NerdKit to the keyboard and printing on the LCD. Eliminating the complexity of sending the characters back out will at least let you figure out what it is you need to work with the keyboard.

Humberto

Given that the keyboard was designed to be used with a very low end model of the Palm (the M100) I think they chose to go with UART so they could double book their only COM port. Also the unit was produced when USB still suffered from the PnP nightmares of old. So they probably wanted a reliable way to handle both: memory writes, and I/O from external devices...why not, right?

I agree that a simple interface is what I need to do first. Would it be the same as reading from any other UART stream? I just set up the a continuous loop to look for a code to come in?

Also the RTS/CTS are listed by wiki as Optional. So, for the simple interface I shouldn't need them, but I may if I want to multiplex two (or more) UART streams on the same RxD/TxD Ports...sound about right? Okay, I am off to experiment. hopefully I don't kill my keyboard or my MCU! Twarter

If it is in fact a normal uart interface, you should be able to read and write to it from the UART module on the chip. The only tricky part is going to be getting the baud rate right.

Humberto

Yeah, I read somewhere (on something only mildly related) that the max baud rate for the Palm M100 was considerably slower than that of the MCU. I think my battery is almost dead, because I am only getting lines 1 and 4 to show up on the LCD. Either that, or one of my connections is loose. I will say, the LCD has been a hindrance, and a blessing, while trying to debug. A blessing for all the obvious reasons. But a hindrance because, it tends to come loose. And coming loose looks identical to an under powered battery to me!

Here is the code for the simple interface I have so far.

// Keyboard.c
// for Interfacing Palm Keyboard with ATMega168
// twarter@gmail.com

#define F_CPU 14745600

#include <stdio.h>

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/uart.h"

int main() {
  // init LCD
  lcd_init();
  FILE lcd_stream = FDEV_SETUP_STREAM(lcd_putchar, 0, _FDEV_SETUP_WRITE);
  lcd_write_string(PSTR(" NerdKits ServoSquirter "));

  // init keyboard input
  uart_init();
  FILE uart_stream = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
  stdin = stdout = &uart_stream;

  char tc;
  while(1) {
    lcd_line_two();

    // Wait for a character to be sent to the uart.
    tc = uart_read();
    fprintf_P(&lcd_stream, PSTR(" char: %c "), tc);

  }

  return 0;
}

Oh and I meant Lines 1 and 3 not 1 and 4