Migrating from PIC Microcontrollers to Cortex-M3

In contrast, Cortex-M3 devices have a small set of architectural peripherals (e.g. the SysTick timer, the NVIC etc) which are accessed via registers in the System Control Space. The location of this is fixed. Other memory-mapped peripherals can be located absolutely at compile-time (via fixed addresses in source code) but this is not recommended. Instead, they are usually defined in relocatable data segments which are then placed by the linker at absolute addresses – these addresses area supplied to the linker in the scatter control file.                

4.1.5       Data types and alignment

When programming in a high-level language, the natural data type of the underlying machine is not necessarily important. The C compiler will take care of mapping high-level data types to low-level arithmetic operations and storage units.

Both compilers support a variety of types, as listed in the table.







8-bit signed

8-bit signed

Char is signed by default in both architectures









short long








long long



No 64-bit type for PIC









long double





The Cortex-M3 is a 32-bit architecture and, as such, handles 32-bit types very efficiently. In particular, 8-bit and 16-bit types are less efficiently manipulated, although they will save on data memory if this is an issue.

Cortex-M3 devices, in common with other ARM architecture devices, normally require that data be aligned on natural boundaries. For instance, 32-bit objects should be aligned on 32-bit (word) boundaries and so on. The core is capable of supporting accesses to unaligned types (and this is useful when porting from architectures which do not have such strict alignment requirements) but there is a small speed penalty associated with this (since the memory interface is required to make multiple word accesses).

Since data memory is always accessed as bytes, PIC devices have no such restrictions.

4.1.6       Storage classes

1.     Static

PIC compilers support the ability to share storage for automatic variables between functions. These are placed in static RAM locations and initialized on each entry to the function. The compiler will attempt to overlay storage for these functions, provided that they can never be active at the same time. Such functions cannot be re-entrant.

Function parameters can also be declared as static and will be allocated fixed storage in data memory. Again, such functions cannot be re-entrant.

The advantage in each case is the potential for smaller code (due to the ease of access to the variables) and smaller data footprint (due to the possibility of overlaying data segments).

While ARM compilers support the static keyword, it is not applicable to parameters and the concept of overlaying data objects is not supported.

2.     Banked

Due to the banked nature of the data memory in the PIC architecture, data items can be declared as near or far. Near items are located within the Access RAM area and can therefore be accessed directly with an 8-bit address. Items declared as far are in banked memory and will therefore require the Bank Selection Register to be set in order to access them.

Near/far can also be applied to program memory objects. Far objects are located at addresses above 64k. in the context of the PIC18F46 device, this is not relevant as the maximum size of program memory is less than this threshold.

In Cortex-M3 devices, there is no concept of near/far for either program or data objects since all pointers can address all of available memory.

3.     RAM/ROM location

Since PIC devices enforce strict isolation between program and data address spaces, data which is to be placed in ROM must be explicitly marked using the rom qualifier. Similarly, pointers to data objects in program memory must be marked using the same keyword.

This introduces complications when using standard library functions to access, for instance, string constants held in program memory (the default). There are several versions of functions like strcpy, depending on whether source and data strings are located in program or data memory. Care must be taken to use the correct variant.

Since the Cortex-M3 address space is unified, this technique is not necessary.

4.2         Tools configuration

When using larger PIC devices, addressing extended program and data memory becomes problematic since pointers are 16-bits in size. Therefore, in addition to the “near” and “far” qualifiers for objects and pointers, PIC compilers, support various memory configurations when building applications. “Small” models limit pointers to 16-bits, while “large” models allow 24-bit pointers. There comes with a code size and speed penalty.

When building for Cortex-M3, there is no need for this since all pointers are 32-bits and can address the entire memory map.

4.3         Startup

PIC18 devices begin execution at the reset vector, which is located at address 0x0000. The return stack pointer is automatically initialized to the bottom of the internal stack region. The software stack pointer, if one is used, is initialized via the linker control file (see 4.1.2).

Before starting execution, the PIC will load a set of system configuration values from a fixed location in program memory (the exact location varies from device to device – the default location will be specified in the template linker script for the device). These values are set via #pragma statements in C or CONFIG directives in assembler language source files.

The PIC startup code automatically initializes the C runtime environment before calling main().

Cortex-M3 devices take the initial value for the Main Stack Pointer from the first word of the vector table (at address 0x00000000) and then begin execution by jumping to the address contained in the reset vector (at address 0x00000004).

Note that Cortex-M3 devices do not support any mechanism for auto-configuration (as described above for PIC) so all components will be in their reset state as described in the manual.

The C startup code will initialize the runtime environment and then call main().


Related posts:

About author

This article was written by admin

Admin has over twenty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles. Working presently as Development Manager in India. A firm Believer in Knowledge grows when it shared.


Comments (3)
  1. pardhu says - Posted: August 22, 2012

    nice stuff…share more info…

  2. Lovetta Turcott says - Posted: October 24, 2012

    It is in point of fact a great and helpful piece of information. I’m happy that you shared this helpful info with us. Please keep us up to date like this. Thanks for sharing.

  3. gry kasynowe says - Posted: October 24, 2012

    If most of the web sites displayed another degree to you, the web ended up being by far and away better location. No place I came across thus fascinating written content. I hope you may proceed often the page: )

Leave your comment

Your email address will not be published. Required fields are marked *