Date
Semester 2, May 2025
Goal
Implement a fully functional Simon Says game on the QUTy microcontroller development board, featuring LED display patterns, audio feedback, pushbutton input, serial communication, and high score tracking.
Context
Final assessment project for CAB202 Microprocessors & Digital Systems at QUT. This project combined low-level hardware programming with game logic into something that actually worked and was fun to play.
What I Used
- C Programming (embedded systems)
- ATtiny1626 Microcontroller
- Hardware peripherals (SPI, UART, ADC, PWM, Timers)
- 7-segment display multiplexing
- Pushbutton debouncing with vertical counters
- Linear Feedback Shift Register (LFSR) for pseudo-random sequences
- State machine implementation
- Serial protocol design and parsing
The Challenges (Oh Boy, Were There Challenges)
- Implementing pushbutton debouncing using vertical counter algorithms to handle multiple buttons working simultaneously without false triggers
- Coordinating everything happening at once: display updates, sound generation, user input, timing
- Developing a complex serial protocol parser to handle UART commands, high score entry, and seed management
- Coordinating state machine logic between Simon’s playback, user input validation, and game flow management
How It Went
I ended up with 27.65/30 (92%) and honestly, I was pretty happy with that result. The core game worked well – smooth display animations, spot-on audio feedback, I got the difficulty scaling right, the potentiometer control for speed adjustment worked perfectly.
The bits that didn’t quite make it over the line were some of the fancier serial features – changing the random seed and persistent high score tables. But it was fun being able to play a game I coded on real hardware, that felt like the real win.
Key Takeaways
Start modular from day one. I began small, threw everything into main.c just to get something working, then kept iterating and adding features. Before I knew it, I had this massive monolithic file that worked but was basically impossible to refactor without breaking everything. Rookie mistake.
I also learned to lean on the teaching staff way earlier in the process. These complex embedded projects have so many moving parts that getting stuck on one thing can derail your entire timeline. George from QUT’s Student Success team was an absolute champ throughout the semester, and a few minute chat with him saved hours in debugging.
Watching it all come together from my first 0.5/30 points was incredibly satisfying.
There’s something magical about writing code that controls physical hardware. When you press a button and hear the exact tone you programmed, see the display light up in the pattern you designed… it’s a pretty good feeling. I started imagining what hardware and code things like my electric toothbrush use.
This assignment will sink as much time as you can give it, but seeing a classic game come to life through your own code made the hectic final week sprint worth it.
My advice if you’re doing a similar project: start early, ask for help when you need it, and keep your first version simple. Get basic functionality working, add the fancy features later when you have a working foundation. When debugging, focus on fixing one issue at a time, like gameplay. Don’t make big sweeping changes to multiple things that could break something else unintentionally. Keep backups of code so you can roll back to previous versions easily.
Anyway, onto the next challenge.
