Device support
To get a smooth start with your product development, the IAR product installation comes with a wide range of device-specific support.
Note
The object code that the compiler generates is not always binary compatible between the cores. Therefore it is crucial to specify a processor. The default core is Cortex-M3.
32-bit Arm devices
Most of the cores and devices that belong to the Armv4, Armv5, Armv6, Armv7 and Armv8 generations are supported (including Armv8.1-M).
Arm architecture profiles
From Armv7, the Arm architectures consist of three architectural profiles:
The A profile, the application profile, implemented by the Cortex-A series, compatible with AArch32.
The R profile, the real-time profile, implemented by the Cortex-R series.
The M profile, the microcontroller profile, implemented by most cores in the Cortex-M series.
32-bit Arm properties
The 32-bit Arm devices (except the M profile) have CPU modes: User mode, Interrupt (FIQ, IRQ) mode, Supervisor mode, etc.
The 32-bit Arm devices have these instruction sets (not all cores have all instruction sets):
Thumb (T), 16-bit wide instructions. Used for compact code.
Arm (A32), 32-bit wide instructions. Used for faster code.
Thumb-2 (T32), extended 32-bit wide instructions to the Thumb instruction set.
Addresses are always 32-bit.
The register set consists of thirteen generic 32-bit registers.
Some 32-bit Arm devices can have coprocessors, like VFP (vector floating point) and SIMD (serial instructions multiple data). The coprocessors have sixteen 64-bit registers or thirty-two 128-bit registers.
The 32-bit Arm devices use 32-bit ELF as object and image format.
64-bit Arm devices
The 64-bit Arm devices based on architectures up to Armv8.4-A are supported, as well as Armv8-R AArch64.
The Armv8-A/R generation defines two execution states: AArch32 and AArch64. (Not all cores support both execution states.)
The AArch32 execution state
The 32-bit AArch32 execution state is compatible with the Armv7-A architecture—it has the same CPU modes, instruction sets, register set, etc—and it has VFP and advanced SIMD. In this execution state, the CPU always runs in 32-bit mode (see Execution modes).
The AArch64 execution state
AArch64 supports four levels of privilege:
The CPU can traverse from a higher EL to a lower one, and during that traversion it can change from the AArch64 into the AArch32 execution state.
In the AArch64 state, the CPU runs in 64-bit mode. See Execution modes.
AArch64 supports one instruction set, A64, that has 32-bit instructions.
Addresses are always 64-bit.
The register set has thirty-one 64-bit wide generic registers.
A VFP and NEON module is always present. That module have 32 registers that are 128-bits wide.
There are three defined data models for AArch64:
ILP32. It has 32-bit
longand pointer types, and 32-bitwchar_ttype. It uses 32-bit ELF as object and image format.LP64. It has 64-bit
longand pointer types, and 32-bitwchar_ttype. It uses 64-bit ELF as object and image format.LLP64. It has 32-bit
longtype, 64-bit pointer type, and 16-bitwchar_ttype. IAR Embedded Workbench for Arm does not support this data model.
Note: Code generated for AArch64 using the ILP32 data model cannot be linked with code generated using the LP64 data model. Neither can code generated for AArch32 and AArch64 be linked together.
Preconfigured support files
The IAR product installation contains preconfigured files for supporting different devices. If you need additional files for device support, they can be created using one of the provided ones as a template.
Header files for I/O
Standard peripheral units are defined in device-specific I/O header files with the filename extension h. The product package supplies I/O files for all devices that are available at the time of the product release. You can find these files in the arm\inc\vendor directory. Make sure to include the appropriate include file in your application source files. If you need additional I/O header files, they can be created using one of the provided ones as a template. For detailed information about the header file format, see EWARM_HeaderFormat.pdf located in the arm\doc directory.
Device description files
The debugger handles several of the device-specific requirements, such as definitions of available memory areas, peripheral registers and groups of these, by using device description files. These files are located in the arm\config directory and they have the filename extension ddf. The peripheral registers and groups of these can be defined in separate files (filename extension sfr), which in that case are included in the ddf file. For more information about these files, see Modifying a device description file and EWARM_DDFFORMAT.pdf located in the arm\doc directory.
Examples for getting started
Example applications are provided with IAR Embedded Workbench. You can use these examples to get started using the development tools from IAR. You can also use the examples as a starting point for your application project.
The examples are ready to be used as is. They are supplied with ready-made workspace files, together with source code files and all other related files. For information about how to run an example project, see Working with example projects.