Lab Report > CEG3136 LAB 1 Report Introduction to Microprocessor Programming

downloaded from

Scholarfriends

https://scholarfriends.com Downloaded by: writerforacademic@gmail.com | https://scholarfriends.com/singlePaper/273538/lab-report-ceg3136-lab-1-report-introductionto-microprocessor-programming Distribution of this document is illegal.

CEG 3136

LAB 1 Introduction to Microprocessor Programming

Lab of Sept 20th, 2018 TA: Bruce Sun Daniel Campbell - #8764508 Srikar Kovvali - #8661959 Christien Salem - #8607260 Scott Fulton - #8765062

Equipment The following was used to complete this lab: • Windows PC • Dragon 12 Plus Trainer

Objectives Part One Summary This initial section of the lab had instructed us to utilize the D-Bug12 module of the MiniIDE software to assemble a given program and record responses to a given table. This program was designed to interpret a user-given ASCII character input from terminal, and repeat that character a set number of times in a formatted manner. Both the number of times it would be repeated, and the formatting of the outputted text, would later be altered per the lab manuals instructions. The completion of this parts components was verified by the TA. Algorithm We were required to translate the given algorithm into C code to further understand its process. The following is the code we developed: Include <stdio.h> int main(void){ int a, b; putchar(‘:’); b=getchar(); for (a=3;a!=0;a--){ putchar(‘ ’); putchar(b); } return 0; }

Observations of Outcomes Given a list of instructions, we were then asked to record the subsequent address and contents observed throughout operation. This is seen in ​Table A1 Table A1:Given Instruction Execution

Address

Content

Instruction

2000

CC003A

LDD #$3A

2003

FEE86

LDX $EE86

2006

1500

JSR 0,X

2008

FEEE84

LDX $EE84

200B

1500

JSR 0,X

200D

8603

LDAA #3

200F

36

PSHA

2010

37

PSHB

2011

CC0020

LDD #$20

2014

FEEE86

LDX $EE86

2017

1500

JSR 0,X

2019

33

PULB

201A

FEEE86

LDX $EE86

201D

1500

JSR 0,X

201F

32

PULA

2020

43

DECA

2021

26EC

BNE $200F

2023

3F

SW1

Following this, we were asked to alter the instructions and their address contents to alter the “:” prompt to a “>” promt, the “ “ spacing to a “;”, and change the loop counter to print exactly 15 times. This is documented in ​Table A2 Table A2: Altered Instruction and Address Content

Address

Content

Instruction

Comment

2000

CC003E

LDE #$3E

Change to ascii ‘>’

2003

FEEE86

LDX $EE86

2006

1500

JSR 0,X

2008

FEEE84

LDX $EE84

200B

1500

JSR 0,X

200D

860F

LDAA #15

200F

36

PHSA

2010

37

PSHB

2011

CC002C

LDD #$2C

Counter to 15

Change to ascii ‘,’

Table A3: Analysis of Requested Operations

Instruction Code

Machine Code

OP Code

Operand

Addresssing Mode

LDX $EE86

FEEE86

FE

EE86

Extended Mem Addresing

JSR 0,X

1500

15

00

Indexed Addresssing

BNE $200F

26EC

26

EC

Relative Addressing

Extended Mem Addressing​ allows us to address a parameter of size 16 bits.

Indexed Addressing​ is used to move to a register with an offset, in this case an offset of 0, meaning we address register X. Relative Addressing​ shows us a replacement of the address $200F with EC

Part Two Summary In this section of the lab, we assembled an already coded alarmSimul.asm file. The program was designed to run in EEPROM and the variables were stored at various RAM addresses. Once we had started the simulation, we had to deal with two problems. The first one being that the the program accepts all types of codes. This bug was visible in the isCodeValid section in the Armed module which could allow us to disarm the system with any code of our choice. The second bug we had to deal with was that delays had not been implemented in the software as in the Delay module did not exist at all. Through the steps provided in the lab manual, we were able to examine the listing of the assembled code in the file alarmSimul.lst and trace the instructions within. We then proceeded to set breakpoints in the subroutine which aided the CPU to execute the program until the given address is seen. Finally, after the above steps, we were able to debug the problem with the armed module.

Discovery of the Bug After reviewing the alarmSimul assembler code and the design document, we discovered that the bug was in fact occurring before branching to the subroutine isCodeValid. Our process to find the bug was fairly straightforward. We traced the instructions as explained in the lab manual and we found the error was in the line beq CDE endif which had to be changed to bne CDE endif The bug occured when the program would check the alarm code. The beq command was would not let the branching to occur and had to be replaced by the command bne which would facilitate for ideal branching. The original command would not branch if incorrect thereby proceeding to mark the code as valid even if it were incorrect.

Addressing Modes The marked/highlighted section in the table is the were the code caused the system to hang up and delay. The line under it are the MOVW instructions. Since MOVW instructions only affect the data in memory, the only register which was affected ended up being the PC. Additionally, the instruction ‘rts’ affects only the SP and PC registers. This is because the rts will take the return address pointed to by the SP and decrement it’s value by 2 and store them as addresses which have a value of 2 bytes. We can also see the stack pointer change reflected in line 3.

The addressing modes are as follows: - MOVW #0 (immediate (#0) followed by extended direct for alarmCode) - MOVW #100 (mult is immediate followed by extended-direct)

A

B

X

Y

SP

PC

CCR

00

00

0000

0000

3C00

0400

90

00

00

0000

0000

2000

0403

90

00

00

0000

0000

1FFE

0427

90

00

00

0000

0000

1FFE

0429

90

00

00

0000

0000

1FFE

042C

90

0C

9C

0000

0000

1FFE

0450

90

0C

9C

0000

0000

1FFE

0456

90

0C

9C

0000

0000

1FFE

045C

90

0C

9C

0000

0000

2000

0405

90

We were able to test the code once again after the debugging process to test if the errors were still present. After thorough testing, we could conclude that the error was no longer present.

Part Three Summary In the final part of the lab we were tasked to creating a delay module for the code already provided in the lab manual. This involved implementing the body of several subroutines. The main implementation involved writing assembly code to delay for 1 ms or 24,000 clock cycles.

To do this we used a pseudocode that we had designed in the prelab using the “C” programing language. We then converted this code into Assembly Language and used this completed code to function as a delay in the program.

Algorithm Enclosed in this section is the c-coded program designed to give us an outline as to how to code the delay module. This code starts with a program that calls a value from a function. This value will determine how many times the program runs, hence how long the function is delayed. It then decrements the value by one until the value reaches zero. It then stops the function and continues the program. The c-code pseudocode is provided below.

Observations of Outcomes The actual implementation and testing of the code was fairly straight forward. The program should run exactly as it did in the second part of the program. The only difference is that now we have added a delay function, which means that the same operations will be shown on screen, just with an extended period of time in between each instruction being visually processed. The amount of time in the delay depends on the number initialized by the programmer. Since we know that 3000 cycles constitutes 1 millisecond, we can do this multiple times in order to create delays in quantifiable values of time. For our experiment, we declared a global variable, our “DELCOUNT” variable, and initialized it to the value 3000. We pushed variables x, y, and z.

We then cleared address in “del_call” and then branched to “del_1ms” which we loaded x with DELCOUNT. We then branch to “del_loop” where we decrement x and branches to “del_loop” if not zero. If it does equal zero, the function branches to “del_check” which loads “delayCount” into x. The variable “delayCount” is designed to determine how many millisecond cycles the program undergoes. Once loaded into x, it is decremented and then x is stored in the “delayCount” variable. The function then branches back to “del_call” if “delayCount” does not equal zero and repeats the 1 millisecond delay. If it does equal zero, then a is loaded with #TRUE and the delay finishes.

Conclusion In closing, the lab was designed to introduce students to the software program used, as well as the Dragon12 Board. It presented us with the opportunity to generate the binaries for execution and for viewing both assembly source and machine code. This helped the debugging processes and determining memory addresses, instruction size, and address locations. We also were made familiar with breakpoints as well as other features that can be used to debug a program. Finally we learned that by using assembly code we can create a delay program by knowing the time it takes to complete instructions.