Abstract
This chapter contains information about using Sourcery G++ Lite on your target system. This chapter also contains information about changes in this release of Sourcery G++ Lite. You should read this chapter to learn how to best use Sourcery G++ Lite on your target system.
Table of Contents
Because of a discrepancy between the ARMv7M Architecture and the ARM EABI it is not safe to use normal C functions directly as interrupt handlers. The EABI requires the stack be 8-byte aligned, whereas ARMv7M only guarantees 4-byte alignment when calling an interrupt vector. This can cause subtle runtime failures, usually when 8-byte types are used.
Functions that are used directly as interrupt handlers should be annotated with __attribute__((__interrupt__)). This tells the compiler to add special stack alignment code to the function prologue.
Sourcery G++ Lite includes support for building applications to run on ARMv7M hardware (eg. Cortex-M3 based devices). Configurations are provided for Generic ARMv7M and some specific devices.
When building an application for a specific board the linker will
put the stack at the top of RAM. When using the generic ARMv7M
configurations the memory size is not known, so the location of
the stack must be specified manually. To specify the stack location
add -Wl,--defsym,__stack= to the gcc linker commandline. For example, a Cortex-M3
device with 64k of RAM starting at address 0x20000000 would use
address
-Wl,--defsym,__stack=0x20010000.
Configurations are provided for both ROM and RAM based image. ROM based images are intended to be burned into flash, and will run when the device is reset. RAM based images are often useful during development and are typically loaded by the debugger via JTAG or similar interfaces.
Note that many Cortex-M3 based devices have very small amounts of
memory. Using some large library functions (eg.
malloc or semihosted file IO) may overflow
avaiable memory.
If you are using the Sourcery G++ IDE, choose from the menu. Select C/C++ Build followed by Tool Settings. Select Target to specify the appropriate board configuration.
Specific board configurations are selected by means of a linker script. The following table shows which linker scripts are available:
Table 3.1. Linker Scripts
| Board | Script (ROM) | Script (RAM) | |
|---|---|---|---|
| Generic ARMv7M | armv7m-rom.ld | armv7m-ram.ld | |
| LM3S101/LM3S102 | lm3s10x-rom.ld | lm3s10x-ram.ld | |
| LM3S301 | lm3s301-rom.ld | lm3s301-ram.ld | |
| LM3S310/LM3S315/LM3S316 | lm3s31x-rom.ld | lm3s31x-ram.ld | |
| LM3S6xx | lm3s6xx-rom.ld | lm3s6xx-ram.ld | |
| LM3S8xx | lm3s8xx-rom.ld | lm3s8xx-ram.ld |
From the command-line, you must add -T
to your linker command,
where scriptscript is the appropriate linker
script. For example, if you are using an LM3S101 board, you should
link with -T lm3s10x.ld.
Sourcery G++ Lite contains preliminary support for automatic generation of NEON SIMD vector code. Autovectorization is a compiler optimization where loops involving normal integer or floating point code are transformed into loops that use NEON SIMD instruction to process several data elements at once.
To enable generation of NEON vector code specify
-ftree-vectorize -mfpu=neon -mfloat-abi=softfp.
-mfpu=neon also enables generations of VFPv3 scalar
floating point code.
Sourcery G++ Lite also contains preliminary support for manual generation
of NEON SIMD code using C intrinsic functions. These intrinsics,
the same as those supported by the ARM RVCT compiler, are defined
in the arm_neon.h header
and are documented in the 'ARM NEON Intrinsics' section of the GCC
manual. The options -mfpu=neon
-mfloat-abi=softfp must be specified to use these
intrinsics; -ftree-vectorize is not required.
NEON support is still under active development. It has not been subject to extensive testing, and may not yet take full advantage of all the features provided by the NEON architecture.