E85 Lab 8: Assembly Language

Transcription

1 E85 Lab 8: Assembly Language E85 Spring 2016 Due: 4/6/16 Overview: This lab is focused on assembly programming. Assembly language serves as a bridge between the machine code we will need to understand to build actual CPUs in Verilog and the C programming we have been doing. In this lab you will learn how to add assembly code to a larger program. You will practice adding writing assembly code by implementing a GPIO based driver for an 8x8 LED display. What to turn in: 1. Your answers for part A 2. Did you complete part B? 3. Your timing diagram for part C 4. Your code for part C 5. Did the LED raster correctly? Feedback: Let us know: What went well in this assignment? Were there points of confusion? How long did you need to work on this assignment?

2 Part A ASM Programming (1) (a) I have the following function: int myfn(int a, float b, double c); Where are a, b and c at the start of the function for a standard ARMv4 procedure call? Where is the return value stored when the function ends? (b) I have a non-leaf function that requires the 8 registers for calculating the answer. Assume the values will be stored in R0-R7. Write the lines needed to handle the standard ARMv4 procedure call for the preserved registers and to return control of the function to the calling function. (c) I have a function: fn1. This function calls fn2. At the time of the function call fn1 is using R0-R11 to hold values it needs for a calculation. What must fn1 do before the BL fn2 instruction? After the BL fn2 instruction? (2) Write an assembly program that finds the modulus of var1 and var2. That is var1 mod var2. You do not have division or multiplication operations. The equivalent C prototype for the function is: int mod(int var1, int var2); (3) The code for: int fn(int a, int b)is shown below. What is the value returned for fn(27, 6)? Express your answer as hexadecimal. fn MOV R2, #0 dwl ADD R2, R2, #4 SUBS R0, R0, R1 BGT dwl CMP R2, #0xA MOVEQ R0, R2 MOVLT R0, R1 MOV PC, LR (4) Write the hexadecimal value of the SUBS, and MOVLT instructions above.

3 Part B Tutorial Thumb and adding assembly to a C program In the previous lab we use C to create a useful embedded system. In this lab the focus is on assembly programming. As you have learned in class, assembly is essentially a human readable form of machine language. That is it is code that the CPU can directly execute. Machine languages implement instruction set architectures (ISAs). The ISA we have been learning in class and is covered in the textbook is ARMv4. This is a great ISA to learn because it is still the basis for all ARM processors today which are ubiquitous. We will be creating an ARMv4 CPU in Verilog in the last labs of this class. Our ATSAMD11 however does not implement the ARMv4 architecture. It actually implements ARMv6M. The M stands for microcontroller. This means it uses a different machine code. The coding of this is actually much more complex than the ARMv4 architecture. ARMv6M is optimized for code size. Embedded systems have very little memory so this is very important for them. We still want to focus on the ARMv4 architecture however because that is the one we will be building. As such we can treat our microcontroller as a restricted ARMv4 processor in terms of assembly. Some instruction forms are not available. For instance we cannot use conditional execution except for branches. The other main difference is that we are limited to using R0-R7 for most instructions. The ARMv6M architecture has some extra instructions as well but we will not use them. What is available to us is given in section 3.3 of this manual: Look at the table and you can see that many instructions are only available in the S version. Some immediate and shifting versions are missing as well. This restricts our coding style but will still allow us to learn the important parts of assembly coding. Why assembly? Knowing assembly is important for a variety of reasons. First it serves as a bridge between the CPU s machine code and high level language code like C. By looking at the assembly our code compiles to we can truly understand everything that our code is doing. In the last lab you saw that the uvision IDE provides you the assembly in the debugger for just this reason. The other reasons to know assembly is of course to use it. In embedded systems it is generally used in places that need either exact timing or efficiency. Even a very good compiler is not as good as a human in many cases at writing optimal code. Compilers do not understand every dependency and may be too careful. One place I recently saw a major piece of assembly programming was in a music player s decoder. This code was being executed for every single byte of music file that was being played. It was worth the time to write it by hand in assembly as a result.

4 Other places you will commonly see assembly are in interrupt handlers and for low level drivers that require software based timing. Interrupt handlers are code that runs on an embedded system when an event occurs. This could be an external event like a button being pressed or something internal. The startup code that is run on our Cortex M0+ before main sets up a table of interrupt handler functions. If you look at the code you will see things like ADC_Handler, a function that would be called every time the ADC converts a sample. The ADC is capable of running at 350 ksps. If our CPU is running at 48 MHz (its maximum rate) then this code would be executed every 137 clock cycles. That might sound like a large number but consider single line of C like the ones we used to blink the LED with &= ~ could easily be at least 4 actual assembly instructions and you will realize that 137 clock cycles is not many. This issue would likely be handled by leveraging direct memory addressing (DMA) but the general problem of interrupts remains: they can happen very frequently, if the code is too long it will not even finish before another interrupt occurs preventing the main functions from running at all. Interrupt handlers therefore are a primary place assembly code will be written because they occur very frequently and thus need to be optimal. Another place to use assembly is where timing needs to be known. Because instructions take a certain length of time which is known, if there are no branches then we can create exact timing of outputs. This can be very helpful creating software implementations of peripherals. You might want to do this if you need another SPI or UART or if you simply do not have one in your selected part. Adding assembly to a C program To add assembly to a C program is not hard. We already met how to add a single line of assembly in our first C programming lab. Here we will write an entire function. It will be to turn on or off our LED. Create a new project in uvision in a new folder for this lab Add a C file to the project called main.c to the project and copy the following code into the file #include "samd11.h" #define NOP() asm volatile ( "NOP" ) void nopdelay(unsigned long delay); void led(unsigned int a); int main() { PORT->Group->DIR.reg = (1<<4); while(1) { led(1); nopdelay(50); led(0); nopdelay(50); // Burn CPU cycles and spin doing nothing void nopdelay(unsigned long delay) { unsigned long i, j; for(j = 0; j<delay; j++)

5 { for(i = 0; i<0xfff; i++)nop(); Add ASM file called led.s to the project and copy the following code into the file THUMB AREA.text, CODE, READONLY EXPORT led OUTADR EQU 0x led ledon ledoff finish PUSH {R4 LDR R4, =OUTADR LDR R1, [R4] MOVS R3, #0x10 CMP R0, #0 BEQ ledoff ORRS R1, R1, R3 B finish MVNS R3, R3 ANDS R1, R1, R3 STR R1, [R4] POP {R4 MOV PC, LR ALIGN END This is a simple function to turn the LED on and off. It illustrates most of the assembly coding we have been learning in class. There are some extra items here however so we will go through the code top to bottom together. The directive THUMB tells the compiler that it should compile THUMB version code. This is the compact form that ARMv4 does not have. We need to say this for our microcontroller but it is not important beyond that. The next statement about AREA tells the compiler where this code goes in the memory of the CPU. The text area is where programs go, its read only. The EXPORT statement makes the symbol led available outside this file. We need to do this because the C program calls led. The OUTADR EQU is very much like a #define statement in C. It allows us to use a label rather than a value. Notice at the start of the code we PUSH R4. This is consistent with the standard procedure call for ARMv4 (ARMv6M is basically the same). We are going to use R4 so we save the contents. Notice in the code we really did not have to use R4 so we could have made this more efficient if we had left it out and used R2 in its place, but we put a PUSH and POP in the code to show their proper place!

6 The standard procedure call from C puts the first argument in R0, so we know that R0 will contain 0 for off. The code above treats anything that is not 0 as true to turn on the LED as you can see. The last line MOV PC, LR returns to where we were before the function call. At this point also look at the C code and notice the function prototype is there and defines how LED works for the compiler. Build the project to compile the code You should get a warning about the MOV PC, LR. It will say that BX <rn> is preferred. This is a Thumb specific instruction to do the return that is more compact. We will keep writing code that is compatible with ARMv4 and not use it. Change the debugger settings for the project and start a debugging session Set a breakpoint at each of the calls to led() Add the PORT peripheral to debugger view At each call of led() look at the evolution of the registers and memory in the PORT OUT register using single stepping You should see the value 1 or 0 passed to the function in R0, the value of R4 at the end should be as it was at the beginning of the function, and you should observe both paths of execution through the function.

7 Part C Implement a driver for the 8x8 LED display In this part of the lab you should implement a driver that allows you to display patterns on the 8x8 LED display you used in the last lab. The base code for this part of the assignment can be found here: The driver should be a single function: void drive8led(unsigned char row, unsigned char col); The driver should: 1. Shift out row and col to the two shift registers using sclk, row and col pins 2. Latch the values to the output with the rclk pin Before you write the assembly code for this function, first draw a timing diagram for the ideal output of the GPIO signals to set to shift in an arbitrary pattern. After you have drawn your timing diagram implement the diagram as closely as possible in assembly. If it is not possible to do something you have drawn then make note of it. You are welcome to shift out the LSB or MSB first whichever you find more convenient. By writing the code in assembly we can increase the performance/refresh rate of the display or minimize the overhead of the call to update this display in our overall code. Try to minimize the number or instructions executed by your function. Depending on how you write your code you might find the OUTTGL, OUTCLR and OUTSET registers useful in the PORT peripheral. How many instructions are executed for your function?