Re: PIC, Keyboard, and USART

Abstract Dissonance wrote:
I was thinking that all I would have to do is switch between master and slave mode for tranmission and reception.

Basically yes, but, with the additional protocol thingy in between to tell the keyboard that it should start clocking data in and not out.

Not sure if this would work though or not... I'd still have to setup the clock speed properly for tranmission but I figure that it shouldn't be to hard to do cause they are two disjoint parts. The main problem is when worrying about collisions.

The way I've seen this and used the keyboard is that the keyboard actually is always master and provides the clock i.e. tells the PC when it can start sending a command byte. But I'm not an AT keyboard specifications guru, maybe the specs provide for a little-known slave mode also.

You can find some valuable background info at
http://www.beyondlogic.org/keyboard/keybrd.htm#1


Yeah, I'm still trying to read up on all this stuff. Its a good site but trying to make some sense of the data*** for the pic. It gives different methods to do the same thing and I'm confused on which is right.

If you only want to receive, and your uC does support full 11 bits UART ("Enhanced USART" sounds like it might, but then maybe that's just marketing bull...) then this should be very easy to do.


Well, I'm not sure. It says 9-bits but not sure if that includes the start and stop bit ;/

I had a quick glance at the PIC18F2455 data*** (I like to spot PIC flaws ;-)), and searched the PDF for "parity". Not many search results.

In section 20.2 EUSART Asynchronous Mode the data*** says that "Parity is not supported by the hardware but can be implemented in software and stored as the 9th data bit.". So the USART might not be that "Enhanced" after all if, it lacks such basic features as parity bit. But it's up to you to check the PIC18 family users guide etc in more depth to see if this is actually the full truth or not (considering it is a PIC, it'd be hardly surprising if the parity feature was really missing ;-)

Anyway, from that one data*** sentence I'd guess the Enhanced USART does only start + stop bit and 7..9 bits of data. So if you want to /receive/, enable 9 bit mode, and ignore the 9th bit (since at only 9600 baud the chance for errors must be really small :)) For transmitting something, do the parity calculation in software.

Just add the pull-up resistors, data line to UART RX, clock input not strictly necessary - until you want to transmit.

? Is that for asynch mode? I'd need to use the clock in slave mode for the getting data? (since I don't know its data rate). I could use asynch mode and auto detect the clock but I'm not sure how reliable this is ;/ and I think there has to be a calibration test or something and I have no idea how to get that done.

Yup, asynch, no need for the external clock when receiving because basically the keyboard is supposed to be sending at 9600baud (IIRC).

Your PIC UART will (or, /should/ ;-) sync up at the start bit automatically, provided you have set the UART to a fixed 9600 baud and don't use any kind of unreliable "automatic baud rate detection" features.

With UART set to 9600 baud the actual data rate or delay between bytes is irrelevant, as long as bit rate of one individual byte is those 9600 baud - and the PC keyboard takes care of that already.

regards,
- Jan
.