Background

For a while, I had been interested in learning more about PCB design and 3d printing. I also had been playing around with the idea of building a modular electronic catan board.

The goals for the project was to

  • Create a tile that could communicate with its neighbors
  • Have the tile be able to discover the network topology without input from the user
  • Have the tile set up a valid board of catan
  • Allow for up to 6 players and support a board with enough tiles for a 6 player game
  • Assemble/solder all components myself

I also set some limitations to make the project more feasible. In the past, I've done some fairly simple THT soldering, but I wasn't confident in my ability to manually do SMD soldering and I did not plan on getting a reflow oven, so al the parts needed to be THT. I also had limited experience with arduino language, so I decided to stick with that instead of learning AVR C.

To possibly add some longevity to the project, I decided to split the project into two separate circuits: the catan tile and a generic, reusable network tile. The network tile would be responsible for routing messages between tiles and the game tile. The catan tile would represent a single tile of catan, handle user input, and communicate with other tiles via the network tile layer. Because of my restrictions to use arduino + THT, I settled on using the ATMEGA328P, the same MCU as an Arduino UNO, for both boards.

Network Tile

Each tile needs to communicate with its 6 neighbors and the attached game tile. I wanted to use the hardware serial port for logging/debugging, so I needed some other way of communicating between boards. I had to rule out I2C and SPI because I needed to know the topology of the board in order to set up a valid board. Just having a tile as an address on a bus wasn't enough. I finally settled on the built in SoftwareSerial library for this.

After creating a few arduino-on-a-breadboards, I experimented with using multiple software serial ports to communicate. Once done, I created a protocol that could be implemented to send arbitrary messages over a network of such tiles.

   0                   1                   2                   3  
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Start Code  | Source Address|Destination Ad.| Payload Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               | System Option | System Command|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Start Code:  8 bits
     Used to indicate start of message
   Source Address:  8 bits
     The source address
   Destination Address: 8 bits
     The destination address
   Payload Length: 16 bits
     Size of the a pyload after the header in bytes
   System Option: 8 bits
     Specifies system options to use
   
   System Command: 8 bits
     Specifies network commands to perform

 One caveat of using SoftwareSerial is that it can only listen on one port at a time. To handle networking, I would need the tile to constantly round-robin the ports listening for an incomming message. I created a common library that could ping a destination until acknoledged and then read/write messages.

With several more breadboarded tiles assembled, I began working on network discovery. This would work by having a designated tile attempt to discover the network by attempting a breadth first traversal to discover new nodes. The network is fairly dumb, so the coordinator also needs to distribute updates whenever it receives information about a new node so that the others can also route messages to it.

I quickly ran into an issue, however. It seemed that the single MCU did not have enough memory/power to handle both routing messages using the 7 soft serial ports and coordinating network discovery. Instead of trying a more robust MCU, I decided to offload netowrk topology, discovery coordination, and shortest path calculation to a second MCU on the same circuit. This Pathfinder would be a separate device that the router could communicate with using I2C....

Read more »