Skip to main content

IAR Embedded Workbench for RISC-V 3.40

Retargeting—Adapting for your target system

In this section:

Before you can run your application on your target system, you must adapt some parts of the runtime environment, typically the system initialization and the DLIB low-level I/O interface functions.

To adapt your runtime environment for your target system:

  1. Adapt system initialization.

    It is likely that you must adapt the system initialization, for example, your application might need to initialize interrupt handling, I/O handling, watchdog timers, etc. You do this by implementing the routine __low_level_init, which is executed before the data sections are initialized. See System startup and termination and System initialization.

    Note

    You can find device-specific examples on this in the example projects provided in the product installation, see the Information Center.

  2. Adapt the runtime library for your target system. To implement such functions, you need a good understanding of the DLIB low-level I/O interface, see Briefly about retargeting.

    Typically, you must implement your own functions if your application uses:

    • Standard streams for input and output

      If any of these streams are used by your application, for example by the functions printf and scanf, you must implement your versions of the low-level functions __read and __write.

      The low-level functions identify I/O streams, such as an open file, with a file handle that is a unique integer. The I/O streams normally associated with stdin, stdout, and stderr have the file handles 0, 1, and 2, respectively. When the handle is -1, all streams should be flushed. Streams are defined in stdio.h.

    • File input and output

      The library contains a large number of powerful functions for file I/O operations, such as fopen, fclose, fprintf, fputs, etc. All these functions call a small set of low-level functions, each designed to accomplish one particular task, for example, __open opens a file, and __write outputs characters. Implement your version of these low-level functions.

    • signal and raise

      If the default implementation of these functions does not provide the functionality you need, you can implement your own versions.

    • Time and date

      To make the time and date functions work, you must implement the functions clock, __time32, __time64, and __getzone. Whether you use __time32 or __time64 depends on which interface you use for time_t, see time.h.

    • Assert, see __iar_ReportAssert.

    • Environment interaction

      If the default implementation of system or getenv does not provide the functionality you need, you can implement your own versions.

    For more information about the functions, see The DLIB low-level I/O interface.

    The library files that you can override with your own versions are located in the riscv\src\lib directory.

  3. When you have implemented your functions of the low-level I/O interface, you must add your version of these functions to your project. For information about this, see Overriding library modules.

    Note

    If you have implemented a DLIB low-level I/O interface function and added it to a project that you have built with support for C-SPY emulated I/O, your low-level function will be used and not the functions provided with C-SPY emulated I/O. For example, if you implement your own version of __write, output to the C-SPY Terminal I/O window will not be supported. See Briefly about C-SPY emulated I/O.

  4. Before you can execute your application on your target system, you must rebuild your project with a Release build configuration. This means that the linker will not include the C-SPY emulated I/O mechanism and the low-level I/O functions it provides. If your application calls any of the low-level functions of the standard I/O interface, either directly or indirectly, and your project does not contain these, the linker will issue an error for every missing low-level function.

    Note

    By default, the NDEBUG symbol is defined in a Release build configuration, which means asserts will no longer be checked. For more information, see __iar_ReportAssert.__aeabi_assert