The goal of this new project is to build a fully functioning Wooden chess computer (Like a Mephisto Exclusive) similar to the one described in this site, but in a simpler way and in a way that others can copy. It is important that the design produces a wooden board that is nice to look at and use.
- Raspberry Pi based, no other processor
- Simplicity/ ease of build.
- Low cost
- Ease of duplication by others.
New Easy to build Electronic chess board design!
Since I first built this project the Raspberry Pi environment has exploded and many new bits of hardware and software modules have been developed. The net result is that it is now easier to build a system using just the Raspberry Pi (without an Arduino) and the alternatives to the Pi such as the Beaglebone Black make no sense. The arrival of the Pi Zero for $5 strengthens the case.
I2c bus connects all major components
My original design had assumed I could use a single I2c bus and hang all devices off that. It turns out that while it is logically possible to connect a very large number of devices to the Raspberry Pi via I2c, It is not electrically straight forward. Many I2c devices are supplied on breakout boards with built in resistors, and devices may run at either 3v or 5v.
The 5v devices usually run displays. The net result of all of this is that in practice you can only directly connect 3 devices reliably without carefully balancing voltages and separating out devices with different voltages.
I found that with the device mix need for this project that I got intermittent failures because of the load place on the bus if 4 or more devices are attached. So the noughts and crosses project worked fine, but this chess project requires a slight adjustment.
The solution, is to connect a TCA9548A I2C multiplexer to the PI and then connect up to 8 devices to the multiplexer. This gives you 8 I2c channels to which each component is connected. All that is required is a small change to the original software. I am building this variation now and will include more detail when its done and tested.
9th December Update:
I have now tested the TCA9548A I2C multiplexer with all devices and it works well and simply. You connect the mux as if it were a 3v I2c device using 3v, Gnd, SDA and SCL.
It normally has an I2C address of x70, but I changed it to x71 by simply taking A0 to 3v, this avoided a conflict with the HT16K33 which is also x70.
On the output side, you connect each device to its own 3v or 5v supply, plus GND and then connect its SDA & SDL leads to whichever of the 8 channels you choose. ( 0 to 7)
You start your code with these lines to set up the mux:
I2C_address = 0x71
I2C_bus_number = 1
bus = smbus.SMBus(I2C_bus_number)
Then before each device you tell it which <12_channel> 0 to 7 to use by using:
the “2**i” calculates binary that gives channel pos, ie channel 0 is 0b00000001 (first channel along) and channel 4 is 0b00010000 (5th channel)
Importantly you don’t change the I2C address of any of your devices from what they were before, except where they might clash with the MUX, in my case no “0x71” allowed.
The great advantage of this device is that:
- You can have up to 8 channels, but the load on the Pi is as if one is connected.
- You can use devices with a mixture of 5v or 3v powered directly from the Pi without the need for a logic level converter.
- Devices can have duplicate I2c addresses provided they are on different channels, the only reserved address is the Mux address.
The only exception to this good news is the Sain Smart I2C LED LCD with Keypad that I used for the noughts and croses project. Unfortunately the Adafruit library it uses seems to have hard coded bus routines in it and I cannot figure how to edit it. I have also decided I want a bigger screen so I am going for an I2c 4×20 Character LCD, which I have tested with the mux and it works, plus another MCP23017 for the four buttons I need.
My next step is the final assembly of all this, however I am off for a month or so soon, so it may take a while before I get around to it.
My new design uses the I2c bus. This means that it connects to the Raspberry PI using just 4 wires. It consists of these elements
- Raspberry Pi (any model including the zero)
- TCA9548A 1-to-8 I2C multiplexer
- 4 x MCP23017 I2c Port expander controlling 64 reed switches
- Adafruit 16×8 LED Matrix Driver Backpack – HT16K33 Breakout**
- Display: I2C 20×4 Character 5v LCD Display
- Buttons: 4 Push switches connected to another MCP23017
Another advantage of this design is cost. The total cost of all the electronic components is shown below. All except the Pi, sourced on Ebay, mainly from China, more expensive if bought locally.
|1||Raspberry Pi Zero (But any pi will work)||3.00|
|1||TCA9548A 1-to-8 I2C multiplexer||6.34|
|5||MCP23017 port expanders||4.00|
|64||Reed Switch Glass Normally Open||6.93|
|1||Adafruit 16×8 LED Matrix Driver Backpack**||1.54|
|64||5mm LED s 3V||3.20|
|32||10mm x 1mm Neodymium magnets (for the pieces)||4.39|
|1||I2C 20×4 Character 5v LCD Display||4.00|
|4||Push Button Switches||4.00|
I will put up more details of the build later, but the connection each of the components above is well documented on the web.This does not include the cost of the chessboard & pieces.
** I used to list the generic HT16K33 board, but I had problems with it. So I think it better to use the Adafruit 16×8 LED Matrix Driver Backpack – HT16K33 Breakout, particularly as they have written the driver for it.
The software for each component is broadly the same as described elsewhere on this site and I have got all the components working separately. I am currently working on finishing the hardware build. Whatever way you design it there are still 64 reed switches and 64 LEDs to solder in place.
Controlling the LEDs can be done with the Adafruit 16×8 LED Matrix Driver Backpack – HT16K33 Breakout it has its own library, which makes programming in Python very easy.
Software that uses the MUX
All the hardware elements work together and have now been tested. I am now in the process of completing the physical build and will then modify the chess software for the PI only build.
In the next few weeks I will publish test software for these Mux elements, but as a taster here are two test programs. Both use the Mux. One tests the 4 MCPS by printing to the monitor the state of a chess board switches eg A1 Open or E4 Close. The other does the same thing, but also turns on and off the corresponding LED using the HT16K33
The Physical Build
Connecting the I2C Hardware
First connect the TCA9548A I2C multiplexer: directly to the PI as if it were a 3v I2c device using 3v, Gnd, SDA and SCL.
It normally has an I2C address of x70, but I change it to x71 by simply taking A0 to 3v, this avoids a conflict with the HT16K33 which is also x70.
Check by typing: sudo i2cdetect -y 1
You should see one device connected with address x71.
You will see that the MUX board has 8 channels labelled 0 to 7. Each channel is a pair of SDA and SDL connections.
Our Connections will be:
|0||KCD Screen and Keyboard||0x3f, 0x20|
|2||MCP23017 Chess col A,B||0x21|
|3||MCP23017 Chess col C,D||0x22|
|4||MCP23017 Chess col E,F||0x23|
|5||MCP23017 Chess col G,H||0x24|
Now connect each of the 4 MCP23017 s to one of the channels by wiring the SDA & SDL leads to the Mux connection as shown in the table above. ie One MCP to one channel. Connect the power and Gnd cable to the 3v and Gnd pins on the PI.
Configure the MCPs to the correct I2C address from the table. see the NOX page for how to configure I2c Addresses.
I suggest you do one MCP at a time, or at least just do one to start with. You can modify the test code in MuxMaxAllMCPV2.py. There are two loops for the MCP, one for set-up and the other for scanning. of the form
for i in range(0,4): # for each of the 4 MCPs
# read the 8 registers
for k in range(0,4):
Change that so for the first MCP it reads i=0 and k=0 (i and k are not the channel numbers, you will see that the program adds “2” to each)
Note that if you run sudo i2cdetect -y 1 now, it will still only show one device at x71, the Mux.
The I2C signal is switched through the mux by the program to the correct channel preserving the I2C address of the device so that the device recognizes the call. As all the MCPs are on different channels we could have given them all the same address, but I made them different so you can test without the Mux if you want to and for clarity.