13.2.3. Overview of the development procedure

This section gives an overview of the development process of an application using Angel, from the evaluation stage to the final product.

The stages in the Angel development procedure are:

  1. Evaluate the application.

  2. Build with high dependence on Angel.

  3. Build with low dependence on Angel.

  4. Move to final production hardware.

Figure 13.2 shows an example of this development procedure. The stages of the development procedure are described in more detail below.

Figure 13.2. The Angel development process

Stage 1: Evaluating applications

If you want to evaluate the ARM to ensure that it is appropriate for your application you must have a program, or suite of programs to run on the ARM.

You can rebuild your programs using the ARM Software Development Toolkit, and link them with an ARM C or C++ library.

You can run your ported applications in two ways:


You can run your programs under the ARMulator, and evaluate cycle counts to see if the performance is sufficient.

This method does not involve Angel, however you can use an Angel-targeted ARM C or C++ library because the ARMulator supports the Angel semihosting SWIs, so C library calls are handled by the host C library support.

Evaluation board

Instead of testing programs under the ARMulator, you can use an ARM evaluation board to evaluate performance. In this case you use Angel running as a debug monitor on the ARM evaluation board. You do not need to rebuild Angel, or to be familiar with the way Angel works.

You can build images that are linked with an Angel-targeted ARM C or C++ library, and then download the images with an ARM debugger.

Stage 2: Building applications on a development board, highly dependent on Angel

After evaluating your application you move to the development stage. At this stage, the target board is either your own development board or an ARM development board:

Using an ARM development board

You can use the ARM PID board to closely emulate the configuration of your production hardware. You can develop your application on the PID board and port it to your final hardware with minimal effort.

Using your own development board

If you are developing on your own hardware it is likely to have different peripheral hardware, different memory maps, and so on from the ARM evaluation boards or development boards. This means that you must port Angel to your development board. The porting procedure includes writing device drivers for your hardware devices. Refer to Porting Angel to new hardware for more information.

When you have chosen your development platform, you build a stand-alone application that runs next to Angel on your target hardware. You must use one of the methods described in Downloading new application versions to download the application to your development board.

At this stage you are highly reliant on Angel to debug your application. In addition you must make design decisions about the final form of your application. In particular you should decide whether the final application is stand alone, or uses minimal Angel to provide initialization code, interrupt handlers, and device drivers. If you are porting Angel to your own hardware you must also consider how you will debug your Angel port. Refer to Debugging your Angel port for more information.

If you are developing simple embedded applications, you might want to move straight to building your application on a development board.

Stage 3: Building applications on a development board, with little dependence on Angel

As you proceed with your development project and your code becomes more stable, you will rely less on Angel for debugging and support. For example, you might want to use your own initialization code, and you might not require C library semihosting support:

  • You can switch off semihosting, without building a special cut-down version of Angel, by setting the $semihosting_enabled variable in the ARM debuggers. In armsd:

    $semihosting_enabled = 0

    In ADW or ADU select Debugger Internals from the View menu to view and edit the variable. Refer to Chapter 3 ARM Debuggers for Windows and UNIX for more information.

  • You can build an application that links with the minimal Angel library. This can be blown into a ROM, soft-loaded into Flash by the ARM debuggers, or installed using a ROM emulator, Multi-ICE, or EmbeddedICE.

    Minimal Angel provides the same initialization code, raw device drivers, and interrupt support as full Angel. Moving from full Angel to minimal Angel on your development hardware is straightforward. See Developing an application under minimal Angel for a description of minimal Angel.

    This is conceptually a step closer to the final product compared with using the debugger to download an image. You can choose either to keep minimal Angel in your production system, or remove it for final production.

    If you need to debug a minimal Angel application and your hardware supports JTAG you can use EmbeddedICE or Multi-ICE. These do not require any resource on the target.

Stage 4: Moving an application to final production hardware

When you are ready to move the application onto final production hardware, you have a different set of requirements. For example:

  • Production hardware might not have as many communications links as your development board. You might not be able to communicate with the debugger.

  • RAM and ROM might be limited.

  • Interrupt handlers for timers might be required in the final product, but debug support code is not.

At this stage it is not desirable to include any parts of Angel that are not required in the final product. You can choose to remove Angel functionality completely, or you can continue to link your application with a minimal Angel library to provide initialization, raw device, and exception support.

Copyright © 1997, 1998 ARM Limited. All rights reserved.ARM DUI 0040D