25-08-2017, 09:32 PM
C51Snakes
[attachment=34392]
Description of the Hardware
The project is implemented using AT89S51 controller. The complete circuit diagram can be found in the directory /C51Snakes/ckt in the archive C51Snakes.zip. Here, I shall explain the important sections of the circuit that may require your attention
Crystal
I have chosen a 27MHz crystal for the oscillator. If you wish to use a crystal of different frequency, then you will have to modify the functions „_Delay10ms‟ and „_Delay100ms‟ in the file “SystemFunction.inc”. It may be noted that these functions are heavily used by the application for timing.
It is not advisable to use a crystal of frequency lower than 20MHz lest the timing and real time response of the game should be affected.
The 4.7k – 22uF RC network provides a power on auto. reset feature. You may wonder why an RC network of time constant as large as ~100ms is used. The reset key also has an overloaded feature: wake the MCU from Power Down state (external interrupt keys may also be used for this purpose). The application is then expected to resume from the point where the Power Down occurred. However, in the first design (where I did not incorporate the RC network), the bouncing of the reset key prevented the application from resuming; Often, it would start from the beginning. But now, the RC network also offers a debounce feature. A large RC delay will guarantee that the RESET pin will be held high until even the bounce signal of the worst time period has settled. The diode provides an easy discharge path for the capacitor during a cold reset.
3mm LED Dot Matrix Display
The display is driven by the ports P0, P1 and P2. The anodes of the LEDs are shorted along any column and their cathodes are shorted along any row. The LED rows 0 (bottommost) to 7 (topmost) are connected to P0 pins 0 to 7 respectively. Similarly, the LED columns 0 (leftmost) to 7 and 8 to 15 (rightmost) are driven by P1 pins 0 to 7 and P2 pins 0 to 7 respectively. All port pins are active low.
Coding Conventions
Group of functions that accomplish a particular task will always be moved to a separate file (.inc). Be it a file name, function name, ISR name or even labels, the identifiers clearly manifest their purpose. Each function has been documented, clearly specifying their arguments and return value(s). I have also added comments where ever necessary.
Function naming convention:
The function names will always start specifying the return variable, followed by the identifier and the arguments, if any will also be contained in the name. If a function does not return any value, then the name will begin with an underscore.
Global Variables and Program Constants
All the global variables and the program constants are defined in the source file „ConstAndDataDefs.inc‟. All the 128 bytes of available RAM has been put into use (may be I will have to move on to AT89S52, in case the next version of the game is made). The RAM partitioning and the purpose of each partition is given below.
Display multiplexing
The display is controlled by the ports P0, P1 and P2. Now, we have 128 LEDs and 24 MCU pins altogether to control them. So, we multiplex the display to the port pins ie flash only one of the 16 columns at a time. After flashing this column for a short period, we switch to the next column. Finally, after proceeding in this fashion, when we reach the last column, we circle around to the first column. It takes about 8ms to sweep the whole display once. So, the average display refreshing rate is about 125Hz at 27MHz crystal frequency.
Various modes and their associated source files
Once the System Power Administration block kicks off the application, the „C51Main‟ block takes over the command. The flow of the application and the various modes that it enters, based on user requests, are controlled by this block which is defined in the source file „C51Snakes.asm‟. This file is also the main file to be added to the project. Like the functions of the „Game Mode‟, definitions in this file are placed in page two of MCU ROM (0800H to 0FFFH). The rest of the source file definitions are place in page one.
System Power Administration
The power administration block is invoked during the application start up.
This block also controls System Power Down and manages a system recovery from Power Down. The gaming console powers down if the user does not press any key in about 25secs. The application will resume (console wakes up from power down state) if the user presses external interrupt keys. This process is quite straight forward. However, what happens if the user presses the reset key, while the console is in power down state? Now, the situation gets complicated.
By the way, there are two power up modes to talk about. First, a cold power up / reset characterized by the Vdd rising from zero to maximum. This is the case when the power is switched off and again switched on. Second, a warm start up / reset, which happens when the user presses the reset key (while Vdd is held high). The RAM assumes random values during the former case while the RAM remains intact during the latter case. However, in either case, the SFRs are reset.
[attachment=34392]
Description of the Hardware
The project is implemented using AT89S51 controller. The complete circuit diagram can be found in the directory /C51Snakes/ckt in the archive C51Snakes.zip. Here, I shall explain the important sections of the circuit that may require your attention
Crystal
I have chosen a 27MHz crystal for the oscillator. If you wish to use a crystal of different frequency, then you will have to modify the functions „_Delay10ms‟ and „_Delay100ms‟ in the file “SystemFunction.inc”. It may be noted that these functions are heavily used by the application for timing.
It is not advisable to use a crystal of frequency lower than 20MHz lest the timing and real time response of the game should be affected.
The 4.7k – 22uF RC network provides a power on auto. reset feature. You may wonder why an RC network of time constant as large as ~100ms is used. The reset key also has an overloaded feature: wake the MCU from Power Down state (external interrupt keys may also be used for this purpose). The application is then expected to resume from the point where the Power Down occurred. However, in the first design (where I did not incorporate the RC network), the bouncing of the reset key prevented the application from resuming; Often, it would start from the beginning. But now, the RC network also offers a debounce feature. A large RC delay will guarantee that the RESET pin will be held high until even the bounce signal of the worst time period has settled. The diode provides an easy discharge path for the capacitor during a cold reset.
3mm LED Dot Matrix Display
The display is driven by the ports P0, P1 and P2. The anodes of the LEDs are shorted along any column and their cathodes are shorted along any row. The LED rows 0 (bottommost) to 7 (topmost) are connected to P0 pins 0 to 7 respectively. Similarly, the LED columns 0 (leftmost) to 7 and 8 to 15 (rightmost) are driven by P1 pins 0 to 7 and P2 pins 0 to 7 respectively. All port pins are active low.
Coding Conventions
Group of functions that accomplish a particular task will always be moved to a separate file (.inc). Be it a file name, function name, ISR name or even labels, the identifiers clearly manifest their purpose. Each function has been documented, clearly specifying their arguments and return value(s). I have also added comments where ever necessary.
Function naming convention:
The function names will always start specifying the return variable, followed by the identifier and the arguments, if any will also be contained in the name. If a function does not return any value, then the name will begin with an underscore.
Global Variables and Program Constants
All the global variables and the program constants are defined in the source file „ConstAndDataDefs.inc‟. All the 128 bytes of available RAM has been put into use (may be I will have to move on to AT89S52, in case the next version of the game is made). The RAM partitioning and the purpose of each partition is given below.
Display multiplexing
The display is controlled by the ports P0, P1 and P2. Now, we have 128 LEDs and 24 MCU pins altogether to control them. So, we multiplex the display to the port pins ie flash only one of the 16 columns at a time. After flashing this column for a short period, we switch to the next column. Finally, after proceeding in this fashion, when we reach the last column, we circle around to the first column. It takes about 8ms to sweep the whole display once. So, the average display refreshing rate is about 125Hz at 27MHz crystal frequency.
Various modes and their associated source files
Once the System Power Administration block kicks off the application, the „C51Main‟ block takes over the command. The flow of the application and the various modes that it enters, based on user requests, are controlled by this block which is defined in the source file „C51Snakes.asm‟. This file is also the main file to be added to the project. Like the functions of the „Game Mode‟, definitions in this file are placed in page two of MCU ROM (0800H to 0FFFH). The rest of the source file definitions are place in page one.
System Power Administration
The power administration block is invoked during the application start up.
This block also controls System Power Down and manages a system recovery from Power Down. The gaming console powers down if the user does not press any key in about 25secs. The application will resume (console wakes up from power down state) if the user presses external interrupt keys. This process is quite straight forward. However, what happens if the user presses the reset key, while the console is in power down state? Now, the situation gets complicated.
By the way, there are two power up modes to talk about. First, a cold power up / reset characterized by the Vdd rising from zero to maximum. This is the case when the power is switched off and again switched on. Second, a warm start up / reset, which happens when the user presses the reset key (while Vdd is held high). The RAM assumes random values during the former case while the RAM remains intact during the latter case. However, in either case, the SFRs are reset.
![[Image: 0.jpg]](https://1.bp.blogspot.com/_sEuQm7zs5oI/SvyKXK_KtrI/AAAAAAAAAok/KrMdCLoIQNU/s400/0.jpg)