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.
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 »