about those switches ...

You said there are six terminals on the switches, so they're clearly encoded. I've got some encoded switches here, of which some have six terminals, two of which are common, but which provide either positive, in one case, or negative, in the other, logic for the BCD outputs. If that's what you've got, then encoding them will take one common connection per switch, and four BCD bits for the lot of them. If you try to do it the other way, i.e. with the common pins common to all digits, you'll suffer from the interaction of the various switches.

That seems like ten pins, worst case, on your MCU, for the switches. I could be wrong about the configuration of your switches, of course, but only you can determine what it is that you've got. BTW, I'm curious what, exactly, it is that you plan to do with those switches. I don't recall that a chess clock has any switches for setting anything. Of course, it's been a long time since I was actively playing the game.

One way to do that is to use all 32 of the available pins on a 40-pin MCU to do the display job, namely, 29 pins for the display, and three to communicate with other MCU's. That means two MCU's for the displays. For the switches, you need six common pins and four data bits. If you drive the data bits high, which is automatically done if you use them as inputs with their weak pullups, then you can drive the six commons, one at a time, to a low level, and thereby detect which switches are set such that the connection to common is "on."

Additionally, you can do the timing and sense the two players' pushbuttons on the same MCU that senses these BCD switches, since the other two MCU's will simply be display drivers. Most of the "intelligence" will reside in this third MCU.

Going back to an earlier stage ... a lot depends on whether you can obtain the appropriate 7-segment LCD's, mount them on a board, and package the whole thing appropriately. It also depends quite a lot on how well you can compute the rate at which this thing has to operate. If you operate the "third" MCU at, say, 1 MHz, it's probably fast enough, and if you clock the display-driver MCU's with the switch/timing MCU's ALE, it will then probably be fast enough. I doubt that will use a lot of power.

That's only one approach to the problem, but from where I sit, it offers the most potential of actually being complete with a minimum of effort at the hardware level, leaving plenty of time and resources available for the packaging design, power management, etc, as well as cosmetic features, which often are a major factor in the success/failure of a product. When this proven concept is to be "productized," it will clearly be best to do the entire job with a single high-pin-count MCU, since that's likely to be lower in cost and power consumption. If you're going to raise money to make this into a working and successful product, however, you've got to put one on the table first.

RE