copied for my github readme:
Code for to display Conway's Game of Life on a ht1632c-based 32x8 LED matrix board, controlled by an AVR ATtiny26 microcontroller. The extra I/O pins on the ATtiny26 are used to control 3 multiplexed seven-segment displays to show the generation count. The code has counters of generations that have low differences, and when it reaches a threshold it resets the display with a new "random" pattern. This is to keep it interesting, and to prevent oscillators from staying indefinitely and preventing reset.
- There is a button connected to PB6 of the ATtiny26, which
triggers external interrupt INT0 which can reset the display if the
spectator desires to do so. Using this button with INT0 is optional, and
can be disabled by clearing
- There is the option to have a potentiometer or other analog
sensor (photoresistor/LDR perhaps?) connected to PA7 (ADC6) to control
the PWM brightness setting of the ht1632c-based display! This is also
optional, and can be disabled by clearing
- At startup, when PB6 doesn't have INT0 or it's internal pullup enabled yet, the
init_srand(void)function takes the lower byte of the floating ADC value on ADC9 (on PB6), which should have a bit of interference. It then feeds this byte into C's
srand()function to seed the Pseudo Random Number Generator
rand(), which is used later to put a "random" pattern onto the display when the Game of Life resets in the
reset_grid(void). This is to make it have a hopefully different set of random patterns every time you reboot/reset the MCU.
- If using INT0 for the button on PB6, and the ADC6 input on PA7, the code compiles to exactly 2048 bytes!.
This isn't exactly a feature but is pretty interesting (the ATtiny26
only has 2048 bytes of flash! So be careful with changes to the code, or
it may compile to be too big to fit in the ATtiny26! If unsure, type
make sizeusing the included Makefile to find out flash and ram usage). This may change later if I put some constants into EEPROM instead of PROGMEM (flash), but reads from EEPROM are slower than flash, so I probably won't change that unless I have to. The code can surely be better optimized ( I did as much as I could ), so feel free to do so. (compiler flags were a miracle as well, the
--combine -fwhole-programgcc flags helped shave off many bytes!). NOTE: interesting coincidence, based on my link on Hackaday Projects, my project is number 2048! Very interesting indeed!
Now has been soldered on protoboard pcb!
Project has been posted on Hackaday Projects!
Original development and testing of the code had been done within my driving_ht1632c_AVR repository.