Thread: xbox360 chatpad, awsome backlit mini keyboard

that looks promising

Originally Posted by wmpwi

Would something like this be of any use? here

i referenced that already quite a few posts up

Hence where i posted the link to page one

Originally Posted by thermoptic

Turbocad6, I don't own one of these (yet) and unfortunately I am way too busy to dig into yet another side project. I have to debug my LCD kit first... Since you are probing connection on the PCB, I thought I would discuss what I would do. From the teardown, we know the chatpad is using the Microchip PIC16F883 28-pin SSOP package.

PIC16F883 Datasheet
http://ww1.microchip.com/downloads/e...Doc/41291B.pdf

The SSOP pin-out is listed on page 3 and Table 1-1. The white silkscreen dot near C1 denotes pin 1. The Make website disassembly review states there are four data signals and three audio signals on the connector. You can trace the four data signals to the J1 main connector with a DMM. This will reveal how the device is connected to the parent controller interface, which we know is using USB.

I suspect they are using the Master Synchronous Serial Port (MSSP) module in Chapter 13 of the datasheet for Serial Peripheral Interface (SPI) or Inter-Integrated Circuit (I2C) control. As an SPI slave device, the data connection would use SCK, SDI, and SDO, and maybe SS_. See Figure 13-1. I2C only requires two signals. With a ground, you would have a total of three signals. The I2C interface is discussed in Section 13.4 and Figure 13.6. It could also be TX and RX from the EUSART dicussed in Section 12.0.

With an unlocked PIC design, we could read the microcontroller code and better understand what is happening and pull the keyboard matrix timing details and port to another microcontroller with direct USB support. I imagine Microsoft set the PIC security bits, so this is no longer possible. Treating the chatpad as a blackbox, we can attach a SPI/I2C monitor and watch the traffic with keystroke presses. This would entail hardware such as the LA1034 logicport logic analyzer with interpreter logic.

LA1034 Logicport Logic Analyzer
http://www.pctestinstruments.com/

SPI/I2C/RS-232 Interpreter
http://www.pctestinstruments.com/log...terpreters.htm

Let's say the interface is SPI. After mapping the keystrokes to SPI sequence, we can leverage an existing SPI-capable microcontroller with USB interface and simple HID compliant driver. The Atmel AT90USBKEY evaluation module should fit the bill. A direct pairing may even allow us to skip the SPI monitoring as we may be able to do this directly in the AVR tools?

Atmel AT90USBKEY ($32)
http://www.atmel.com/dyn/products/to...p?tool_id=3879
http://www.atmel.com/dyn/resources/p...ts/doc7627.pdf
http://www.digikey.com/scripts/us/dk...=AT90USBKEY-ND
http://www.avrfreaks.net/index.php?m...v&objectid=133

When its all said and done, all we really want is this sweet little keyboard. The more elegant solution would eliminate the PIC16F883 altogether, at least for the keypad matrix, and map the Atmel AT90USB1287 uC directly to the keypad matrix. This would involve more work, thus reading the SPI command should be easier. Granted that the chatpad may require an initialization sequence from the master controller, but this will be captured in the monitor session. The example Atmel code should make it easy to translate the PIC16F883 SPI or I2C sequence into a USB character recognized by the Windows XP driver. Someone familiar with AVR could knock this out quickly.

I ran some keyword searches on a few electronics forums (“PIC16F883 SPI chatpad”) but I didn’t see anything. We could leverage an Atmel forum or apps group to do the work, however there may be issues with DMCA and reverse engineering. Atmel could sell quite a few AT90USBKEY devices if they are indeed viable. I believe they use the SPI port for iin-circuit programming, so the development environment would have to use another I/O option (such as JTAG).

Forums
http://www.avrfreaks.net/
http://forum.microchip.com/
http://forum.servomagazine.com/

I would enjoy developing a solution to enable Windows XP chatpad usage but I have to sleep sometime. It would be nice of Microsoft to release the PIC 6F883 code for use by the hobbyist sector. I'm not holding my breath.

Here are some related links I found during my Google searches:

http://jledger.proboards19.com/index...ead=1188926392
http://www.instructables.com/id/Hacking-a-USB-Keyboard/
http://www.obdev.at/products/avrusb/index.html
http://www.beyondlogic.org/index.htm#USB
http://www.microsoft.com/whdc/device/input/default.mspx

I haven't seen anything from c0nsumer, the original poster of the teardown pictures. I think somebody will solve this issue before Microsoft releases the PC drivers.

holy ****, that was the most technical conversation I've ever read. You should be down here where I live working on Space Rockets

yeah man, I could make my car fly before I could figure that out

I get it. Hell I'd give it a shot if i had the time/resources.

My solution? Figure out how the keypad talks to the PIC, then desolder and replace with our own programmed PIC

Originally Posted by turbocad6

yeah man, I could make my car fly before I could figure that out

I dunno, looks pretty easy to get a car to fly:

[media]http://www.in-site.co.nz/rocktec/links/objects/Trebuchet.wmv[/media]

LOL.

Originally Posted by greatwhite

I dunno, looks pretty easy to get a car to fly:

[media]http://www.in-site.co.nz/rocktec/links/objects/Trebuchet.wmv[/media]

LOL.

They fly for awhile, my problem is they always come back down

Originally Posted by inh

I get it. Hell I'd give it a shot if i had the time/resources.

My solution? Figure out how the keypad talks to the PIC, then desolder and replace with our own programmed PIC

Does PIC offer direct USB interface in their microcontroller product line? I haven't played with PICs in a long time. The Atmel AVR looks very USB friendly with complete HID driver compliant code. HID Keys is a 17-key USB keypad controller example for the AVR-USB:

HID Keys
http://www.obdev.at/products/avrusb/hidkeys.html

My thought is to cut out the keypad matrix decode logic and replace with the UART keypress data, which we read from the chatpad PIC. The chatpad PIC firmware already does the hard work of monitoring the keypad matrix to create the character. You press 'a', the PIC 16F883 decodes the keypad matrix and sends ASCII letter 'a' (0x61 hexadecimal) on the TX UART line. With one start bit, eight data bits, one stop bit, and no parity (known as 8-N-1) the 'a' would be sent out to the XBOX 360 controller on the TxD line as follows:

START BIT + EIGHT DATA BITS + STOP BIT
1 + 0 1 1 0 0 0 0 1 + 0

The AVR code decodes the 'a' character on its RxD UART line, sends the 'a' through the USB link to the HID USB device driver, and the OS drops an 'a' character into the active application. Piece of cake, right?

This assumes the PIC 16F883 sends simple ASCII characters for key presses. The protocol could be more complex. My approach also assumes the HID Keys example runs on the AT90USBKEY with little porting effort. The biggest part of this project is simply allowing the two pieces to communicate. It should be easy, but I am assuming many things.

UART Transfer
http://en.wikipedia.org/wiki/UART#Se...llel_Algorithm

ASCII Table
http://www.asciitable.com/

Google Bot has already found this thread (so many keywords). Excellent! Let's hope somebody picks up this project.