Chess computer design advice

Hi,

I want to build a chess computer, like the kind that were popular in the late '70s. Something like this: http://www.boris-is-king.com/homepage.htm#110179313 . I have a few questions about the best approach.

The chess engine will run on a computer, like a Raspberry Pi or a BeagleBone Black. The chess engine will be a subprocess of a python program that will handle communication with the interface. The human interface will be 8 digits of Alphanumeric LED (like DL2416 or DL1414) and a matrix keypad.

I have built some i2c interfaces for the LED displays, using MCP23017 i/o expanders, and I imagine I could also read the keypad matrix using an i/o expander or an i2c keypad matrix decoder.

So here is the question that I'm thinking of. Should I use a microcontroller to interface with the i2c user interface elements (the LED displays and the keypad), and then interface the microcontroller with the computer? Or should I directly control the i2c bus from the computer? If I went with a microcontroller, I was thinking of using a uC with a usb interface to connect to the computer. Maybe something based on a ATMEGA32U4? Maybe a Teensy?

What are the tradeoffs I should consider. I thought maybe it would be easier for me to base the interface on interrupts is I used a microcontroller rather than i2c tools through the python program.

Thanks for any ideas or comments you may have.

Jimmy

mixographer:
What are the tradeoffs I should consider. I thought maybe it would be easier for me to base the interface on interrupts is I used a microcontroller rather than i2c tools through the python program.

Almost correct.

The idea of using the MCU to collect inputs and outputs, translating them to alphanumeric codes is good and makes sense but please try and just completely forget about interrupts.

Interrupts exist to handle important and time critical events, such as "ticks" of your timing clocks (including serial protocols), or disc access where you are using that. No HID event, either input or output, is of any importance whatsoever under a thirtieth of a second (one video frame), all of these are performed more than adequately by polling.

Even worse is the matter of switch bounce, which you need to handle by algorithmically slowing the response to a signal from a push-button. The "newbie" tendency to connect push-buttons to interrupts can cause absolute mayhem as each switch generates volleys of interrupts.

Thanks for the info. I'll go with my approach and see where I get.

(Edit: I mean go with my approach, but use polling...)

Cheers,

Jimmy