TABLE OF CONTENTS For many engineers, porting existing program code to new architecture is a typical task. With the Cortex-M3 products starting to emerge on the market, many of us have to face the challenge of porting ARM7TDMI (referred to as ARM7 in the following text) code to the Cortex-M3. This chapter evaluates a number of aspects involved in porting applications from the ARM7 to the Cortex-M3.
There are several areas to consider when you're porting from the ARM7 to the Cortex-M3:
System characteristics
Assembly language files
C language files
Optimization
Overall, low-level code such as hardware control, task management, and exception handlers requires the most changes, whereas application codes normally can be ported with minor modification and recompiling.
There are a number of system characteristic differences between ARM7-based systems and Cortex-M3 based systems (for example, memory map, interrupts, MPU, system control, and operation modes.)
The most obvious target of modification in porting programs between different microcontrollers is their memory map differences. In the ARM7, memory and peripherals can be located in almost any address, whereas the Cortex-M3 processor has a predefined memory map. Memory address differences are usually resolved in compile and linking stages. Peripheral code porting could be more time consuming because the programmer model for the peripheral could be completely different. In that case, device driver codes might need to be completely rewritten.
Many ARM7 products provide a memory remap feature so that the vector table can be remapped to the SRAM after boot-up. In...
