Файл: ARM cross development with Eclipse, version 2 (J.P. Lynch, 2005).pdf

The next part of the startup file crt.s to investigate is the setup of the .data and .bss sections, as shown below.

The .data section contains all the initialized static and global variables. The GNU linker will create a exact copy of the variables in flash with the correct initial values loaded. The onus is on the programmer to copy this initialized flash copy of the data to RAM.

The location of the start of the .data section in flash is defined by symbol _etext (defined in the linker command script demo2106.cmd). Likewise, the location of the start and end of the .data section in destination RAM is given by the symbols _data and

_edata. Both of these symbols are defined in the linker command script.

The .bss section contains all the uninitialized static and global variables. All we have to do here is clear this area. Likewise, the location of the start and end of the .bss section in destination RAM is given by the symbols _bss_start and _bss_end. Both of these symbols are defined in the linker command script.

Two simple assembly language loops load the .data section in RAM with the initializers in flash and clear out the .bss section in RAM.

The GNU linker specifies two addresses for sections, the Virtual Memory Address (VMA) and the Load memory Address (LMA). The VMA is the final destination for the section; for the .data section, this is the RAM address where it will reside. The LMA is

where it will be loaded in Flash memory, the exact copy with the initial values. The GNU Linker will sort this out for us.

14 Description of the Main Program main.c

Now let’s look at the main program.

The main program starts out with a few function prototypes. Note that the interrupt routines mentioned in the crt.s assembler program reside in the main() program. We’ve used the GNU C compiler syntax that identifies the interrupt routines and makes sure that the compiler will save and restore registers, etc. whenever the interrupt is asserted.

I’ve also included a few do-nothing variables, both initialized and uninitialized, to illustrate that the compiler will put the initialized variables into the .data section and the uninitialized ones into the .bss section.

We’re going to try to toggle a single I/O bit, specifically P0.7 which is the Olimex red LED.

By the way, with this hardware arrangement:

P0.7 = 1 // turn off LED

P0.7 = 0 // turn on LED

The Philips LPC2106 has 32 I/O pins, labeled P0.0 through P0.31. Most of these pins have two or three possible uses. For example, pin P0.7 has three possible uses; digital

I/O port, SPI Slave Select and PWM output 2. Normally, you select which function to use with the Pin Connect Block. The Pin Connect Block is composed of two 32-bit registers, PINSEL0 and PINSEL1. Each Pin Select register has two bits for each I/O pin, allowing at least three functions for each pin to be specified.

For example, pin P0.7 is controlled by PINSEL0, bits 14 – 15. The following specification would select PWM2 output.

PINSEL0 = 0x00008000; // set PINSEL0 bits 14 – 15 to 01

Fortunately, the Pin Connect Block resets to zero, meaning that all port pins are General-Purpose I/O bits. So we don’t have to set the Pin Select registers in this example.

We do have to set the I/O Direction for port P0.7, this can be done in this way.

The ARM I/O ports are manipulated by register IOSET and register IOCLR. You never directly write to the I/O Port! You set a bit in the IOSET register to set the port bit and you set a bit in the IOCLR register to clear the port bit. This little nuance will trip up novice and experienced programmers alike. Alert readers will ask; “What if both bits are set in IOSET and IOCLR?” The answer is “Last one wins.” The last IOSET or IOCLR instruction will prevail.

To turn the LED P0.7 off, we can write:

Likewise, to turn the LED P0.7 on, we can write:

IOCLR = 0x00000080; // turn P0.7 (red LED) on

As you can see, it’s fairly simple to manipulate I/O bits on the ARM processor.

To blink the LED, a simple FOREVER loop will do the job. I selected the loop counter values to get a one half second blink on – off time.

// endless loop to toggle the red LED P0.7 while (1) {

This scheme is very inefficient in that it hog-ties the CPU while the wait loops are counting up.

The Initialize(); function requires some explanation.

We have to set up the Phased Lock Loop (PLL) and that takes some math.

Olimex LPC-P2106 board has a 14.7456 Mhz crystal

We'd like the LPC2106 to run at 53.2368 Mhz (has to be an even multiple of crystal, in this case 3x)

Note: M - 1 must be entered into bits 0-4 of PLLCFG (assign 3 to these bits)

The Current Controlled Oscillator (CCO) must operate in the range 156 Mhz to 320 Mhz

Fcc0 = 212947200 hz (good choice for P since it's within the 156 mhz to 320 mhz range From Table 19 (page 48) of Philips LPC2106 manual P = 2, PLLCFG bits 5-6 = 1 (assign 1 to these bits)

Finally: PLLCFG = 0 01 00011 = 0x23

Final note: to load PLLCFG register, we must use the 0xAA followed 0x55 write sequence to the PLLFEED register

this is done in the short function feed() below

With the math completed, we can set the Phase Locked Loop Configuration Register

(PLLCFG)

// Setting Multiplier and Divider values PLLCFG = 0x23;

feed();

To set values into the PLLCON and PLLCFG registers, you have to write a twobyte sequence to the PLLFEED register:

PLLFEED = 0xAA;

PLLFEED = 0x55;

This sequence is coded in a short function feed();

The net effect of the above setup is to run the ARM CPU at 53.2 Mhz.

Next we fully enable the Memory Accelerator module and set the Flash memory to run at ¼ the clock speed. Now you see why some people prefer to execute out of RAM where it’s much faster.

//Enabling MAM and setting number of clocks used for Flash memory fetch

//(4 cclks in this case)

MAMCR=0x2;

MAMTIM=0x4;

The clock speed of the peripherals is also run at 53.2 Mhz which is the full clock speed.

// Setting peripheral Clock (pclk) to System Clock (cclk) VPBDIV=0x1;

In the final snippet of the main() code, you can see the dummy interrupt service routines. They are just simple endless loops; we don’t intent to allow interrupts in this simple example.

15 Description of the Linker Script demo2106_blink_flash.cmd

Let’s look now at the linker command script, demo2106_blink_flash.cmd. I’ve included extensive annotation to make it very clear how the memory is organized.

The first order of business in the linker command script is to identify the memory available, this is easy in a Philips LPC2106 – the RAM and FLASH memory are on-chip and at fixed locations. Page 29 of the Philips LPC2106 User Manual shows the physical memory layout.

On-chip static RAM is from 0x40000000 -

0x4000FFFF For the LPC2106

On-chip static FLASH is from 0x00000000 - 0x0001FFFF For the LPC2106

First we define an entry point; specifically _startup as defined in the assembler function crt.s.

ENTRY(_startup)

The Linker command script uses the following directives to lay out the physical memory.

You might expect that we’d define only a flash and a ram memory area. In addition to those, we’ve added two dummy memory areas that will prevent the linker from loading code or variables into the RAM areas used by the Philips

ISP Flash Utility (sometimes called a boot loader). See page 180 in the Philips

LPC2106 User Manual for a description of the Boot Loader’s RAM usage.

As you’ll see in a minute, we’ll be moving various sections (.text section, .data section, etc.) into flash and ram.

Note that we created a global symbol (all symbols created in the linker command script are global) called _stack_end. It’s just located after the stack/variable area used by the Philips ISP Flash Utility (boot loader) as mentioned above.

_stack_end = 0x4000FEDC;

Now that the memory areas have been defined, we can start putting things into them. We do that by creating output sections and then putting bits and pieces of our code and data into them.

We define below four output sections: