Tiny4412 C language Realization running lights, Tiny4412 bare Metal program [3]

In the front we used the assembly to complete a running light experiment: TINY4412 assembly running light Code, Tiny4412 bare-metal LED operation

However, the assembly language readability is too poor, in this section we use C language to achieve the same function, and later test also try to use C language to achieve.

When we write the host computer program, the C language program executes the first instruction, not in the main function. When generating an executable file for a C program, the compiler typically adds several code--CRTL.O, CRTI.O, CRTEND.O, CRTN.O, and so on in our code that are called startup files, which are standard library files. The code sets the stack of the C program, and so on, and then calls the main function. They rely on the operating system, and on bare boards the code cannot be executed, so it is necessary to write one yourself.

This code is simple, with only 2 key instructions. Self-written start. The contents of the S startup file are as follows:

=0x02027800  //  C function must be set before calling the stack, the stack is used to save the running environment, assigning space to local variables //  reference rom manual P14, We point the stack at 1K above the BL2 (1K is sufficient),//  i.e.: 0x02020000 (iram base address) + 5K (irom code) + 8K (BL1) + 16K (for BL2) + 1K (used as stack)) c9>  BL main  //  call main function (main this name is not fixed, can be changed arbitrarily)  halt_loop:b halt_loop

After the stack pointer is set on line 4th, the C function can be called through line 8th and the stack must be set before---------------C function executes.

Q:does the CPU have a watchdog? Why don't you see the code for the watchdog off? Does this program work?

A: In the previous article, "Exynos 4412, the start-up process analysis," We have introduced, before executing our program, the CPU will first execute the code in Irom and BL1 code, in these two parts of the program will close the watchdog.

In fact, we shut down the watchdog itself is also very simple, just go to register Wtcon write 0 can;

Q: Why do I call the C function to set the stack?

Answer: 1. The overall function of the stack

1) Save the site;

2) Pass parameters: When the assembly code calls the C function, the parameters must be passed;

3) Save temporary variables: include non-static local variables of the function and other temporary variables generated automatically by the compiler;

2. Detailed explanation

1) Save the scene

Scene, meaning is equivalent to the crime scene, there are always some scene, to record down, otherwise destroyed by others, you will not be able to restore the scene. And here says the scene, is refers to the CPU to run, uses some registers, for example R0,R1 and so on, for these registers the value, if you do not save and jumps directly to the child function to execute, then possibly is destroyed, because its function execution also uses these registers. Therefore, before the function call, these registers, such as the field should be temporarily maintained (into the stack push), and so on after the call function execution is returned (out of the stack pop), and then restore the scene. This allows the CPU to continue to execute correctly. Save the value of the register, the general use of the push instruction, the corresponding value of some registers, one by one into the stack, the corresponding value is pressed into the stack, that is, the so-called pressure stack. Then to be called after the child function is executed, then call the pop, the stack of values, assigned to the corresponding those you have just started to press the register to use, the corresponding value from the stack popped out, that is, the so-called out of the stack. The stored register, also includes the value of LR (because the BL instruction to jump, then the value of the previous PC is present in LR), and then when the subroutine is completed, then the value of the LR in the stack pop out, assigned to the PC, so that the child function to achieve the correct return.

2) Passing parameters

C language function calls, often passed to the function called some parameters, for these C-level parameters, the compiler is translated into assembly language, it is necessary to find a place to store, and let the function can be called to access, otherwise it does not send the implementation parameters. To find a place to put, in two cases. In one case, the parameter can be transmitted via the Register R0~R3, with no more than 4 parameters passed by itself. Because in the previous save scene action, has saved the corresponding register value, then this time, these registers are idle, can let us use, then can put the parameter. In another case, when the parameter is more than 4, the register is not enough to use the stack.

3) Temporary variables are stored in the stack

Includes non-static local variables for the function and other temporary variables that the compiler automatically generates.

Now, we can easily write the program that controls the LED. After all, it is in C language, quite flexible. The main function is in the LED.C file with the following code:

#defineGpm4con (* (volatile unsigned int *) 0X110002E0)#defineGpm4dat (* (volatile unsigned int *) 0x110002e4)voidDelayvolatile intTime ) {       for(; time >0; time-- );} intMainvoid) {unsignedLongTMP =0;inti =0; /** Gpm4_0-gpm4_3 set to output function*/tmp=gpm4con;tmp&= ~0xFFFF; TMP|=0x1111; Gpm4con=tmp;/** Realization of running lights*/  while(1) {Gpm4dat=i;if(++i = = -) I=0;d Elay (9999999);} return 0;}

Take a look at makefile:

OBJS: = start.o led.oled.bin: $ (OBJS) arm-linux-ld-tled.lds-n-o led.elf $^arm-linux-objcopy-o Binary -S led.elf [email protected]arm-linux-objdump-d-M arm led.elf>%.o:%. carm-LINUX-GCC- Wall-marm-c-o2-o [email protected] $<%.o:%. Sarm-linux-gcc-wall-marm-c-o2-o [email protected] $<-F *.dis *.bin *.elf *.O

When the make command is executed, its aim is to generate a 1th target, namely Led.bin;

Led.bin relies on START.O and LED.O, so Mr. Cheng will be the 2. o files;

The START.O relies on start. S, which conforms to the rules of line 11th, generates START.O using the 12th line command;

Similarly, LED.O relies on LED.C, which conforms to the rules of line 8th, and generates LED.O using the command line 9th;

When these 2. o files are generated, the command that executes line 4th to 6th generates the Led.bin file: The 4th row will be compiled with the. o File connected to Led.elf

Executable program, line 5th is the executable program that generates the binary format, and line 6th is the disassembler for viewing.

The link script is also the same as the assembly of running lights.

OK, here's the start of verifying our program.

1. Upload the program source to the server and execute make to generate the Led.bin file.

2. Use the steps from the previous experiment to burn the program to the SD card.

3. Insert the SD card into the Tiny4412 Development Board and power up to see the effect of running lights (as well as the assembly flow lamp effect).

Complete program (extract password: WWW.techbulo.Com):

Original: Http://i.cnblogs.com/EditPosts.aspx?opt=1

---

Tiny4412 C language Realization running lights, Tiny4412 bare Metal program [3]