Building a home gym timer display Moderators: adafruit_support_bill, adafruit

[blindedscience]

I'm in the planning phases for a home gym timer display. I want this to be able to display either a standard start/stop timer, or start a tabata, and I figure I can do that with button A and button B input, but ultimately, I want to drive a LED panel through the Matrix Portal M4 to display the time, where the clue TFT would just display what timer cycle is running.
I haven't done a two-board design before - I'm still relatively new to this and I'm not even sure this is wise. I was thinking I'd use the CLUE for input and sound feedback since I like the buttons on that better than the M4, and use I2C to send button state (start/stop clock A/B) to the M4. I'm considering other functions (use the CLUE sensors to send a go-to-sleep signal when there's no light in the gym, or send temperature and humidity data for idle cycle display).
Is I2C, as I'm thinking, the best way to do this, or should I be considering/looking at something else? Should I be using two boards, or is there an alternative for driving everything from the CLUE that would replace the M4?
I'm pretty sure I can get this to work as I have it planned, but I don't want to back myself into any design corners. :)

[mikeysklar]

The MatrixPortal does have buttons and can drive a display via SPI or I2C so the clue is not critical.

i2c is pretty miserable trying to communicate chip to chip. It is awesome for controller <--> peripheral scenarios.

Since the MatrixPortal and CLUE support UART I think that would be the easiest way to share information chip to chip.

[blindedscience]

The MatrixPortal does have buttons and can drive a display via SPI or I2C so the clue is not critical.

i2c is pretty miserable trying to communicate chip to chip. It is awesome for controller <--> peripheral scenarios.

Since the MatrixPortal and CLUE support UART I think that would be the easiest way to share information chip to chip.

The design issue I'm foreseeing with the buttons on the Matrix Portal is that they're side-mounted, and since I want to wall-mount this, I'm thinking it'll be continuously receiving force to the side of the wall-mount, which could eventually lead the wall-mount to tear loose from daily wear and tear.
The CLUE on the other hand, has the buttons on the front, which should minimize the chance for wall mount damage.
But...making all this run inside of the Matrix Portal is probably the preferred way to do this. I've been brainstorming and I figure all I really need is two front-mounted buttons and a speaker to make the core functionality work.
Thank you so much for your feedback on the I2C connection between the two boards! As I said, I'm still relatively new to all of this, so your feedback is really helpful.

[mikeysklar]

Take a look at the Matrix Portal side buttons which have two pads. You could extend those without getting into the other GPIOs if you wish with your own leads.

3BE42213-E4C3-4C29-A2BC-9898FF305CF3.jpeg (244.4 KiB) Viewed 536 times

[blindedscience]

Take a look at the Matrix Portal side buttons which have two pads. You could extend those without getting into the other GPIOs if you wish with your own leads.

3BE42213-E4C3-4C29-A2BC-9898FF305CF3.jpeg

Thank you SO much for helping me to brainstorm this.
I guess for now I really should start with the software prototype, and then tinker with the buttons for the final design once I've got the functionality worked out. Hopefully I'll have pictures of a successful build to post soon!