ARM Programming Method Based on IAR Integrated Development Platform

introduction

In project development, especially small and medium-sized project development, in order to reduce the development difficulty and development cost, the solution of not loading the operating system is often chosen. This paper selects the IAR embedded development platform, and uses C language (about 95%) and assembly language (about 5%) to develop software for an industrial control system based on ATMEL's AT91M40800 chip (ARM7TDMI core) without loading the operating system.

Hardware Architecture

The overall hardware framework of the system is shown in Figure 1. The system basically includes various functions required by current industrial control systems, and its software development is very representative.

IAR Integrated Development Environment

IAR development platform is a comprehensive development platform based on the latest C/C++ compilation and debugging technology developed by Swedish IAR. This platform is a complete integrated development environment that can complete all the work of creating projects, editing files, compiling, assembling, linking and debugging applications; multiple projects can be placed in the same workspace; it can be configured for a single source file, a group of source files or all source files; it provides project templates and supports almost all ARM cores; it provides ANSI standard C compiler, ISO/ANSI C and embedded C++ libraries; it supports multiple JTAGs including Wiggler JTAG interface; and it provides multiple code optimization methods.

The target code generated by IAR is divided into two types: debug version (Debug) and release version (Release). The address of the Debug target code is defined in SRAM and will be downloaded to SRAM for execution; the address of the Release target code is defined in Flash, and most of it will eventually be executed in Flash. Before compiling the program, you need to write two memory allocation files, Debug.xcl and Release.xcl, according to the template. Based on the project template provided by IAR, the following areas need to be modified:

-DROMSTART=2000000
-DROMEND=200FFFF
//ROM address segment
-Z(CODE)INTVEC=00-3F
-DRAMSTART=2010000
-DRAMEND=207FFFF
//RAM address segment
-D_USR_STACK_SIZE=20000
//Stack size
-D_SVC_STACK_SIZE=50
-D_FIQ_STACK_SIZE=100
-D_ABT_STACK_SIZE=50
-D_UND_STACK_SIZE=50 -D_IRQ_STACK_SIZE=
1000
-D_HEAP_SIZE=2000
//Heap size

Startup code design

Usually, C language starts to execute from the main function. In the absence of an operating system, the initialization of the main function is completed by the startup code, including hardware initialization, stack initialization, initialization of various registers, etc.

After completing all the initialization work, a jump instruction is used to enter the main function of the C program, and the control of the program is transferred to the C program. [page]

Driver design

The software framework of the system is shown in Figure 2. The driver includes the device driver, interrupt program and interrupt service program. First, take the Flash driver design as an example. According to the Flash datasheet and hardware design, there are the following definitions:

#define FLASH_BASE ((volatile USHORT *)(0x01000000))
/*Base address of FLASH*/
/*Define the operation code of flash*/
#define FLASH_SEQ_ADD1 (0x5555)
#define FLASH_SEQ_ADD2 (0x2AAA)
#define FLASH_CODE1 ((USHORT)(0xAA))
#define FLASH_CODE2 ((USHORT)(0x55))
#define ID_IN_CODE ((USHORT
)(0x90)) #define ID_OUT_CODE ((USHORT)(0xF0))
#define WRITE_CODE ((USHORT)(0xA0))
#define CHIP_ERASE_CODE ((USHORT)(0x10))

Then write the FLASH function. The following function is used to verify the FLASH device ID:

-ramfunc-farfunc BOOL FLASH_Test(void)
{
//Input command sequence, manuf_code indicates production number, device_code indicates device number
USHORT manuf_code,device_ code;
*(FLASH_BASE + FLASH_ SEQ_ADD1) = FLASH_CODE1;
*(FLASH_BASE + FLASH_ SEQ_ADD2) = FLASH_CODE2;
*(FLASH_BASE + FLASH_ SEQ_ADD1) = ID_IN_CODE;
//Read production number and device number
manuf_code = *FLASH_BASE ;
device_code = *(FLASH_BASE + 1);
//Exit product authentication mode
*(FLASH_BASE + FLASH_ SEQ_ADD1) = ID_OUT_CODE;
//Judge whether the read production number and device number are correct
return ((manuf_code== 0x001f)&&(device_code==0x00c0));
}

When an interrupt occurs, the ARM core operating state will enter several other modes (including FIQ, IRQ, etc.) from the general mode (System & User), so it is necessary to protect the running scene (r0~r12 general registers) and push the ARM status registers (CPSR and SPSR) into the stack. The interrupt program uses assembly language to protect the registers, while the interrupt service program can be written in C language. Here we take the timer interrupt that controls the movement of the stepper motor as an example:

tc0_handler
stmfd sp!, {r14}
;Push the protection register to the stack
mrs r14, SPSR
stmfd sp!, {r14}
mrs r14, CPSR
stmfd sp!, {r0-r12,r14}
IMPORT Interrupt_Tc0
ldr r0,=Interrupt_Tc0
;Jump to C language interrupt service routine Interrupt_Tc0()
mov lr,pc
bx r0
IntExit
;Interrupt service routine completed
ldmia sp!,{r0-r12,r14}
;Restore the scene
msr CPSR_cxsf, r14
ldmia sp!,{r14}
msr SPSR_cxsf,r14
ldmia sp!, {r14}
subs pc,lr,#4

It is worth noting that ARM's division operation uses software division, which uses the r14 register, so it must also be protected. After the interrupt service program is completed, the scene is restored and the registers are popped out of the stack one by one.

Conclusion

The following experiences were gained during the development of this system:

1. Try to avoid using variables that take up a lot of storage space (such as int buffer[4096]). The system overhead is too high and may cause the system to crash.

2. Use memory allocation functions such as malloc() with caution. If used, be sure to call free() to release the memory space after use, otherwise it is easy to cause memory leaks or even system crashes.

3. Pay attention to all warning messages of the IAR compiler and carefully read the meaning of the warning messages.

4. For some modules that are frequently called and need to be processed quickly, consider using assembly.

5. When generating the Release version target code, the exe directory under the Release directory is the target file, and the *.map file in the List directory contains the specific situation of the target file's memory allocation. You can judge whether there is a problem with the memory allocation based on the information in it.

A certain industrial control product developed according to the above development method has been launched on the market after rigorous testing, and its reliability and stability have been verified.