How shimanto008/master-slave-dice-roller works
1. What this repository is
- This is a simulation-oriented embedded systems project, not an application server or desktop app.
- The core architecture is a two-node ATmega32 system: one MCU acts as Master, the other as Slave, connected by USART serial communication and executed in Proteus 8.
2. Top-level repository boundary
- The repository is split into three meaningful parts:
- Master firmware source and build outputs
- Slave firmware source and build outputs
- Proteus circuit design that wires both MCUs and their peripherals together
- The committed .hex files are part of the runtime deployment path for Proteus simulation.
3. Master MCU subsystem
- The Master ATmega32 owns the actual game logic.
- Its inputs/outputs are:
- Push button on PD2 / INT0 for dice rolls
- 7-segment display on PORTC for the current dice value
- Three LEDs on PB0/PB1/PB2 for game-status signaling
- USART TX on PD1 to send game events to the Slave
- This side is the control plane of the system.
4. Slave MCU subsystem
- The Slave ATmega32 is a display-only companion.
- It receives serial data on PD0 / RXD and renders the roll history and status messages on a 16x2 HD44780-compatible LCD.
- It does not drive the game state; it mirrors the Master’s updates.
5. Data flow between the two MCUs
- The main architectural boundary is a one-way Master → Slave data stream.
- Every roll event is packaged into a 5-byte USART frame:
- start marker 0xFF
- dice value
- player ID
- status byte
- end marker 0xFE
- This framing is the key interface to diagram, because it defines how state leaves the Master and becomes display data on the Slave.
6. Game-state behavior
- The Master implements the turn rules:
- 1–5 ends the turn
- 6 grants an extra turn
- two 6s in a row continues the bonus sequence
- three 6s in a row eliminates the turn and resets the sequence
- These states are encoded into the status byte and reflected physically by the LEDs and logically by the serial packet.
7. User interaction path
- The user interacts with the system only through the Master-side push button.
- A button press triggers a dice roll, which updates:
- the Master’s local outputs immediately
- the serial packet sent to the Slave
- There is no direct user input on the Slave side.
8. Display responsibilities are intentionally separated
- The Master shows the instantaneous dice result on the 7-segment display and status via LEDs.
- The Slave accumulates and formats the roll history on the LCD, such as player roll sequences and messages like “Roll Again!”, “Turn Done!”, or “ELIMINATED!”.
- This separation makes the diagram clearer: one MCU handles real-time game control, the other handles session history display.
9. Hardware / simulation layer
- Both MCUs run at 8 MHz using external crystals, which matters because USART timing depends on clock setup.
- The entire circuit is intended for Proteus simulation, not a general-purpose runtime environment.
- The circuit project is the integration boundary that binds MCU firmware to physical-like peripherals in the simulator.
10. Build and deployment artifacts
- Each MCU has its own Atmel Studio project:
- master.atsln / master.cproj
- slave.atsln / slave.cproj
- The resulting hex files are loaded into the Proteus schematic, so the architecture is effectively:
- source code → compiled hex → simulated MCU instances
11. Repo organization as architecture
- The repository structure mirrors the system decomposition:
- Codes/Master = control logic and output driving
- Codes/Slave = serial receive and LCD presentation
- Circuit Diagram = wiring and integration
- That separation is important for drawing the architecture diagram accurately: this is a two-firmware, one-circuit system with a serial interface between independent MCUs.
Main entry points: Proteus_Circuit.pdsprj Proteus Schematic · Master-Slave Dice Roller System Dice System · Master Master Firmware · main.c Game Logic
Components 15
Codes
Firmware sources and build artifacts for the two ATmega32 nodes.
- Master Firmware · Control-plane firmware for dice logic, local outputs, and USART framing.
Master-Slave Dice Roller System/Codes/Master - Game Logic · Implements dice rolls, turn rules, LEDs, and serial packet creation.
Master-Slave Dice Roller System/Codes/Master/main.c - Master HEX · Compiled image loaded into the Proteus master MCU instance.
Master-Slave Dice Roller System/Codes/Master/master.hex - Slave Firmware · Display-plane firmware that receives frames and formats LCD history.
Master-Slave Dice Roller System/Codes/Slave - LCD Logic · Parses serial data and updates turn history and status messages.
Master-Slave Dice Roller System/Codes/Slave/main.c - Slave HEX · Compiled image loaded into the Proteus slave MCU instance.
Master-Slave Dice Roller System/Codes/Slave/slave.hex
Circuit
Proteus schematic that integrates both MCUs and peripherals.
- Roll Button · User push button on PD2/INT0 that triggers a dice roll.
- Master Outputs · 7-segment dice value on PORTC and three status LEDs on PB0-PB2.
- USART Link · One-way master TX to slave RX communication boundary.
- 16x2 LCD · HD44780-compatible character LCD for roll history and status messages.
- Proteus Schematic · Integrates both MCUs, crystals, serial wiring, button, LEDs, 7-segment display, and LCD.
Master-Slave Dice Roller System/Circuit Diagram/Proteus_Circuit.pdsprj
Other components
- Dice System · Two-node master/slave dice roller built for Proteus simulation.
Master-Slave Dice Roller System - Master ATmega32 · Executes roll control, drives the 7-segment display and status LEDs.
- USART Frame · Master-to-slave packet with start byte, dice value, player ID, status, and end byte.
- Slave ATmega32 · Receives USART data and renders history on the LCD.
Connections 18
- Dice System → Master Firmware: contains · Repository groups the master firmware subsystem.
- Dice System → Slave Firmware: contains · Repository groups the slave firmware subsystem.
- Dice System → Proteus Schematic: contains · Repository includes the Proteus integration schematic.
- Master Firmware → Game Logic: implements · Master source defines the game control logic.
- Game Logic → Master HEX: builds to · Atmel Studio project compiles into the deployable HEX image.
- Master HEX → Master ATmega32: loads into · Proteus runs the compiled master image on the simulated MCU.
- Roll Button → Master ATmega32: triggers · Push button on INT0 initiates a roll on the master side.
- Master ATmega32 → Master Outputs: drives · Master updates the dice display and status LEDs immediately.
- Master ATmega32 → USART Frame: encodes · Roll result and status are packaged into the framed USART message.
- USART Frame → USART Link: transmits over · Framed bytes move one-way from master TX to slave RX.
- USART Link → Slave ATmega32: receives · Slave ATmega32 listens on RXD for master updates.
- Slave Firmware → LCD Logic: implements · Slave source defines serial parsing and LCD presentation.
- LCD Logic → Slave HEX: builds to · Atmel Studio project compiles into the deployable HEX image.
- Slave HEX → Slave ATmega32: loads into · Proteus runs the compiled slave image on the simulated MCU.
- Slave ATmega32 → 16x2 LCD: renders to · Slave presents roll history and status text on the LCD.
- Proteus Schematic → Master ATmega32: instantiates · Proteus schematic hosts the master MCU and its peripherals.
- Proteus Schematic → Slave ATmega32: instantiates · Proteus schematic hosts the slave MCU and its peripherals.
- Proteus Schematic → USART Link: wires · Schematic connects the USART boundary between both MCUs.