Work Update

This week my primary goal was to create an overarching design for the software, encompassing both the embedded platform, as well as the central computer. Last week I selected hardware components and began finding software libraries. The work this week built off of that, isolating the software we will need to write from scratch and forming a cohesive architecture.

Last week I found an e-ink screen that was controllable using SPI. I also selected a python library for SPI that I felt would provide a good base for our code. Going forward we will need to write a driver for the screen that is built on top of the SPI library. I spent some time last week going over the docs for both the library and the screen, and preparing to write the driver next week once all of our hardware arrives.

The process for the RFID reader/writer was almost identical to that for the e-ink screen. Again, we will need to write a custom driver on top of the SPI library I found last week.

For resistance measurement, we will need to write a driver on top of a different library—one designed for I2C communication instead of SPI. That shouldn’t be significantly more difficult.

On top of the different sensor drivers there will be a game coordinator layer. On the embedded device this will get the current game state from the central computer, and use the sensor data to update the screen. It will also be responsible for deciding which pieces of data to communicate back to the central computer.

Finally, on top of the game coordinator will be communication layer, built on top of gRPC. This will be a thin abstraction layer so that if we have to make communication changes (e.g. moving to a wired network or USB) we can make them to an isolated part of the system.

For the central computer, there will also be a game coordinator. It will be driven by a state machine representing the game, and take input from each of the player areas. It will send current game information to the player areas, as well as the web server described below. It will also drive the shuffler/dealer.

The audience and player views provided by the central computer will be web-based. There will be a web server (likely Flask) that pulls data from the game coordinator, and serves two different web pages with real-time data.

One thing I have not yet planned is the shuffler/dealer driver. I need to work more with Mark to establish the electrical design of the shuffler/dealer before I can figure out the software.

Please note that the finalized diagram will be presented as part of our design review this coming week.

Schedule Update

Progress is on schedule. As noted during the weekly meeting I swapped this past week with this coming week to accommodate the delivery schedule of our components. Next week I will writing the sensor drivers for the sensors that we currently have.