Laboratory equipment

Introduction
The laboratory exercises are based on MCS51 development kits. Every development kit contains a small but
complete microprocessor system with a 51 family microcontroller, ROM and RAM memory, keyboard, display,
etc. The kits support in-circuit debugging via USB interface, connected to an IBM PC compatible computer, on
which the debugging tools (Keil software) are installed. Hence, user can write a program, compile the code, load
the development kit with the code, and run the program. The debugging software allows user to control the
program execution by means of watching the state of system resources (including internal and external memory,
microcontroller registers, etc.), changing their contents, setting breakpoints, executing the program in full speed
or single-step mode, etc. The computer used for running the debugging software must have a USB port.
Development kit hardware
The development kit hardware consists of a mainboard, microprocessor board and display daughterboard
(Fig. 1). The mainboard must be powered from an AC-DC power adapter. When the board is powered a yellow
Power ON diode located close to the power supply connector (see. Fig. 1) is on. Use only the original AC-DC
power adapter supplied with the kit. The mainboards used in EMISY labs are only partially assembled, as most
of the features available on the fully equipped mainboard are not required during the EMISY lab classes.
However do not change position of the jumpers on the mainboard or microprocessor board, as they are used for
routing some important signals, and changing positions of the jumpers may result in the labkit becoming non-
responsive to the debugging software.
The microprocessor boards used in the laboratory are based on Atmel AT89S52 microcontrollers. Read
AT89S52 datasheet (http://www.ise.pw.edu.pl/impuls/emisy/AT89S52.pdf) and 51 family microcontrollers
user manual (http://www.ise.pw.edu.pl/impuls/emisy/8051_um.pdf) to learn about the details of internal
architecture, available peripheral circuits, instruction list, etc. Circuit diagram and layout of the microprocessor
board are given in the Appendix 1.
Fig. 1. Labkit mainboard with an AT89S52 microprocessor board inserted.
In addition to the microcontroller and RAM chip, the microprocessor board contains also a PLD circuit
(Xilinx XC9536XL), which is used for generation of control signals (some of them are required by the
debugger). The remaining pins of the PLD circuit can be used as general purpose I/O pins. The mentioned
control signals and GPIO pins can be accessed in the external data memory address space of the microcontroller
according to the description below.
XRAM address = 0CxxxH; write and read
GPIO18..21 are general purpose I/O open drain pins with external pull-ups
MSB LSB
x x x x GPIO21 GPIO20 GPIO19 GPIO18
XRAM address = 0DxxxH; write only
GPIO0..7 are push-pull output pins
MSB LSB
GPIO7 GPIO6 GPIO5 GPIO4 GPIO3 GPIO2 GPIO1 GPIO0
XRAM address = 0ExxxH; write only
GPIO8..9 and CS0..3 are push-pull output pins
GPIO8..9 and CS0..2 outputs are directly controlled by the bits of the register described below
mode of CS3 output pin depends on the state of CS3MODE and CS3LEV bits:
for CS3MODE = 1 state of CS3 pin is controlled directly by CS3LEV bit (CS3 = CS3LEV)
for CS3MODE = 0 pin CS3 produces a strobe synchronised to WR / RD signal of the microcontroller
when external data memory at the address 0FxxxH is written or read; polarization of CS3 strobe
depends on the state of CS3LEV (the strobe is positive for CS3LEV=1, negative for CS3LEV = 0)
MSB LSB
CS3MODE x GPIO9 GPIO8 CS3LEV CS2 CS1 CS0
The mainboard can be used with two basic display daughterboards: LED display board and LCD display
board (Fig. 2). Circuit diagrams and layouts of the display boards are given in the Appendixes 2 and 3. Red
labels on the circuit diagrams indicate which of the microprocessor board signals are used to control the display
board lines.
Fig. 2. Numeric LED and alphanumeric LCD display boards.
Working with the code
Programs prepared by the students for the lab tasks are to be written in assembler code. The assembler source
code should be then assembled (and linked) by means of a 51 family assembler/linker. All the mentioned
operations and further debugging can be done with the Keil development tools. Keil development tools which
are used in the laboratory is a demo version of a professional development tookit. The main limitation of this
demo version is size of the program file, which cannot exceed 2 KB. Taking into consideration that the lab tasks
usually can be done with less then 100 bytes of a program, the mentioned limitation does not create any
problems. The tools can be downloaded from the Keil website (https://www.keil.com/demo/eval/c51.htm) after
registration. It is recommended to install the tools on your own computer and get familiar with them before
starting real work in the lab.
Assembler syntax depends an the assembler software manufacturer - further description covers the most
common case. Most of assemblers require every instruction of the source code to be placed in a separate text
line and not to be divided into a few lines (an exception is label definitions that can be placed in the same lines
with the instruction mnemonics or in separate lines). Keywords (op-code mnemonics, register names, etc.) can
be usually typed in small or capital letters, but the software can be case sensitive to all user-defined symbols
(including labels). Every label must be followed by colon (except from labels used in argument fields). The
dollar character used as an argument (instead of a label symbol) is treated as if it was a label defined at
(indicating) the currently assembled instruction line. Every text between semicolon and the end of line is
considered a comment. Binary constants must be followed by a "B" letter (small or capital), octal constants by
a "Q" letter, hex constants by an "H" letter. Every symbol that begins with a letter is considered a name, not a
number, hence hex constants must always begin with digits (eg. 0FFH, not FFH). Simple expressions in the
argument fields are allowed in most of assemblers. Some most common pseudoinstructions (directives)
interpreted by the assemblers are EQU, SET, ORG, DB, DW, END, PUBLIC, EXTERN. The EQU and SET
pseudoinstructions are quite similar they are used for defining a symbol and assigning a value to the symbol.
The difference is that value of a symbol defined with the EQU pseudoinstruction cannot be changed in any way,
while symbol defined with the SET directive can be reassigned (redefined) with another SET pseudoinstruction.
The ORG pseudoinstruction is used for defining an address at which the code that follows should be placed (the
first instruction after the ORG statement is given the address specified by the ORG). The DB and DW
pseudoinstructions are used for defining (respectively) bytes or words of code (constants located within the
program memory address space) and can be used with multiple arguments (numbers or string constants)
separated by commas. The END pseudoinstruction must be usually place at the end of source (assembler) code.
The EXTERN pseudoinstruction indicates symbols defined in the other (external) source code modules. The
PUBLIC pseudoinstruction indicates symbols defined in the current module, that are to be available for the other
(external) modules. To get familiar with programming of the 51 family microcontrollers study at least 51
family microcontrollers user manual (http://www.ise.pw.edu.pl/impuls/emisy/8051_um.pdf), which in particular
contains description of the instruction list of these microcontrollers.
In-circuit debugger
The debugger software is divided into two parts. One is a PC computer software, the other resides in the
development kit program memory, as a part of the system firmware (called monitor). The first part (PC computer
software) acts as a user interface displays all the information about the debugging system (memory and
registers contents, etc.), lets the user load a program, set breakpoints, etc., and communicates via the serial
interface with the development kit, sending commands that invoke routines corresponding to the actions
performed by the user on the computer. The second part of the debugger software (monitor) is responsible for
the system initialization (so that the development kit is ready to work in debugging mode) and servicing all the
debugging commands sent from the computer. As the monitor must initialize starter kit after reset, it must be
located at the bottom of program memory address space, and it occupies 0000H to 1FFFH program memory
address space, that covers also interrupt vector addresses. User program that would normally start at the address
0000H, must be written with the offset of 8000H, therefore starting at the address 8000H. This refers also to the
interrupt routines, eg. Timer 2 interrupt routine must start at the address 802BH, while normally it would be
located at 002BH. Moreover, due to the fact that the debugging software communicates with the kit via the serial
port, user firmware cannot use the serial port, neither Timer 1 (used as a baud rate generator). The interrupt
priorities must not be changed by user firmware, and the global interrupt enable bit must always be set.
Note: User should be very careful about manipulating TMOD, TCON, IP and IE registers, as changing or
loading improper values to these registers may affect the serial port or Timer 1 settings and result in
communication failure, making the starter kit stop responding to the computer.
Using Keil development tools
Start a new project by selecting from the main menu Project => New Vision Project. Save the new project
under the name of your choice, eg. emisy.uvproj. From the list of microcontroller vendors select Atmel and pick
AT89S52 from the list of models (Fig. 3). Answer No to the questions about copying STARTUP.A51 to the
project. Select from the main menu File => New and save the file eg. as lab1.asm. You can now type the code,
but the file is not assigned to the project yet. After expanding the tree in the Project window you should see a
structure as in Fig. 4. Right-click with your mouse folder Source Group 1 in the Project window and select Add
Fig. 3. Microcontroller selection window.
Fig. 4. Empty Keil project.
Files to Group Source Group 1, pick the filename lab1.asm that you have just created, click Add and then
Close. Now your project structure should look as in Fig. 5 and your file is visible as a project component, so that
it can be not only edited but also compiled. Once the code is written it can be compiled (assembled) by clicking
Translate icon and then linked with Build icon, but the same result can be obtained with just a single click
on Rebuild all icon (see Fig. 5). If errors are encountered during compilation or linking they will be described
in the Output window. In such a case double-clicking an output line indicating an error will result in highlighting
the source line containing the error (Fig. 6). Once the source code syntax is correct the Output window will show
Fig. 5. Project with an assembler code file assigned.
Fig. 6. Source code error detection.
0 Error(s), 0 Warning(s) information. Then it is possible to upload the program code to the kit and start
debugging by clicking Debugging on/off icon (see Fig. 5). Before debugging is started the development kit
must be connected to the computer with a USB cable (the kit has USB-mini connector see Fig. 1), and the Keil
software must be configured for operation with the kit. To do this select from the main menu Project => Options
for Target Target 1, then select tab Debug. From the upper top droplist pick Keil Monitor-51 Driver, and
check its Use radio button (Fig. 7). Click Settings button located to the right. From the Port droplist select
appropriate COM port, to which development kit is connected (Fig. 8). If you do not know which COM port
number is correct, check it in the Control Panel => System => Device Manager. After expanding Ports (COM
& LPT) the correct COM ports should be named EMISY labkit (see Fig. 9).
Fig. 7. Debug tab on the target Options window with proper settings.
Fig. 8. Target Setup window.
Once the software is properly set for operation with the development kit, debugging of the compiled program
can be started. Before anything push the reset button on the microprocessor board (see Fig. 1) to bring the
system to a default state. Clicking the Debugging on/off icon will then result in showing Evaluation mode
with 2 KB code limit warning, which should be accepted (click OK). This should initiate communication of
the Keil software with the development kit. Transmission will be signalled by USB transmission LEDs (see Fig.
1) blinking. After proper initialisation the Keil software windows will switch to debugging mode (Fig. 10).
After initialisation the cursor in the machine code window will be positioned at the address 0000H (startup
code). Click Run icon (or use F5 shortcut key) to pass the startup code and get to the beginning of the user
code. Now the code can be debugged in a few basic modes:
Single step (icon Step in; shortcut: F11),
Step over (icon Step over; shortcut: F10),
Run to cursor line (icon Run to cursor line; shortcut: Ctrl-F10),
Run (icon Run; shortcut: F5).
In the Single step mode only one instruction (single opcode) of the program is executed. After that contents
of the control windows is updated. If the opcode to be executed is a CALL (ACALL, LCALL) instruction, the
next instruction to be executed is the first instruction of the subroutine indicated by the CALL.
The Step over mode is similar to the Single step mode, but if the opcode to be executed is a CALL (ACALL,
LCALL) instruction, the program is stopped after the whole subroutine is executed (no subroutine execution
tracing). After that contents of the control windows is updated.
In the Run and Run to cursor line modes the program is running with the full speed. Contents of the control
windows remains unchanged (is not being updated). Execution of the program is stopped when line with the
cursor line (see Fig. 10) is reached (in the case of Run to cursor line mode) or when a breakpoint is encountered.
In the case of no breakpoints the only way to stop the program running in the Run mode is to click Debugging
on/off icon, confirm by clicking on Stop Debugging button (usually twice) and then reset the microprocessor
system (press the development kit reset button). Note however, that this will reset the development kit without
possibility of checking the system resources status, analysing the reasons of improper system behaviour (in the
case of bugs in the program), etc. That is why the Run modes are suitable for fast execution of the program until
a given line of code or a breakpoint is reached or for final (full speed) testing, but not so much for debugging
without breakpoints.
Fig. 9. Device manager window showing current assignment of the COM ports.
In order to stop execution of the program (in Run modes) at some particular addresses user can use
breakpoints. A breakpoint can be set / cleared by clicking at the left side of the selected line of code or by
placing cursor in the chosen line and then clicking Set / clear breakpoint icon.
Using breakpoints has some important limitations that cannot be neglected. All breakpoints are implemented
by means of opcode modification the opcode at which a breakpoint is to be set is substituted by an LCALL
instruction (which calls an appropriate monitor subroutine). Note however, that LCALL instruction opcode is
3-bytes long. Thus, setting a breakpoint at an instruction which opcode is 1- or 2-bytes long can modify some
other instructions. This may be a source of problems (may result in improper debugging) if the controlpoint
LCALL instruction modifies another instruction to which a jump, call, etc. may be executed before reaching the
breakpoint. For example, if a breakpoint is set at the RET instruction of the following program:
...
RET
SUB: INC A
MOV R1, A
...
then the breakpoint LCALL instruction will modify not only RET opcode, but also INC A instruction code, and
executing a call to the SUB label will have unexpected (improper) results. Note, that the limitations discussed
above occur only in the Run modes.
Fig. 10. Windows of the Keil software working in debugging mode.
Lab exercises
General remarks:
1) Oscillator frequency in all the laboratory kits is 11.0592 MHz.
2) The debugger uses serial port and timer T1 for communication with the PC computer. Hence, use of these
peripherals in the user programs is not allowed. Note also that manipulation of TMOD, TCON, IE, IP registers must
be careful in order not to change the settings used by the mentioned peripherals. If a timer/counter is required in the
designed application, use of Timer 2 is strongly recommended.
3) User program must start at the address of 8000H (such an offset is required by the debugger). Interrupt address
vectors (if the interrupts are used) must be also located with the offset of 8000H (e.g. Timer 2 interrupt service routine
should start at 802BH).
EXERCISE 1 (LCD display)
Write a program that will display your name on the LCD display (first name in the upper line, family name in the
bottom line of the display). The program must perform software LCD initialization. Brief description of the LCD
operation can be found at http://www.ise.pw.edu.pl/impuls/emisy/LCD3.pdf.
EXERCISE 2 (LED display)
Write a program responsible for controlling the dynamic LED display so that it would display a text given by the
teacher. The program should use Timer 2 to produce interrupts with the frequency of approx. 1-2 kHz and to service
the display in the Timer 2 interrupt routine.
Note: You can use D1 diode (see the circuit diagram and layout of the display) for testing purposes when
debugging the program.
EXERCISE 3 (keyboard)
Write a program that would scan the keyboard and display number of the pressed key (hex digit 0..F if a key is
pressed, blank display if all the keys are released) on the display. The program should use Timer 2 to produce
interrupts with the appropriate frequency and to service the keyboard in the Timer 2 interrupt routine.
Note: If you have the LED display board you can use the display in static mode. If you have the LCD display board
you can use it in a single line mode (no software initialisation is required in such a case).
Appendix 1. Circuit diagram and layout of the AT89S52 microprocessor board.
Appendix 2. Circuit diagram and layout of the numeric LED display board.
Appendix 3. Circuit diagram and layout of the alphanumeric LCD display board.