User Guide
OpenECU Developer Platform
C-API

The following items of hardware are available as part of OpenECU:

The following items of software are available as part of OpenECU:

And the following items of software are required but not provided as part of OpenECU.

To run the Pi OpenECU software, you will need an IBM-compatible PC with the specifications listed below.

Either the physical system or a system simulator is ultimately required to test and calibrate your ECU and the system model you have created to run on it. A suitable Calibration/reprogramming communications tool is also required conforming to the ASAP2 standard.

You will need the following software pre-installed on your PC:

See the Chapter 2, Installation for full details of the software required.

This manual describes how to use the C-API to create your own designs, but does not include a tutorial about C or embedded systems.

A working knowledge of design modelling and system dynamics principles in an engineering environment is required to make the best use of OpenECU. Ultimately, it is the quality of your own system designs that will be reflected in the quality of your system control strategy.

Note also that there are serious hardware and personal safety considerations involved in developing automotive control systems. Please make sure that you read and understand the notes given in Section 1.5, “Warnings and safety guidelines” to reduce the chance of any such hazards.

Pi Innovo considers the safety and quality of its products to be of paramount importance. The integrity of the product can be considered by assessing the three 'components' which comprise the system.

Systems, rather than software, have a Safety Integrity Level (SIL). The SIL of the customer's resultant system will have to be assessed and defined by their knowledge of the processes used to develop all the components (including those supplied by Pi) comprising the complete system.

The process of testing automotive systems can involve many personal safety hazards — high-speed machinery, extremely flammable and potentially explosive fuels, and the possibility of loss of vehicle control is a combination that can be fatal if sensible precautions are not followed.

As the system designer and tester, it is your responsibility to ensure that your working practices are specifically designed to minimise or eliminate the possibility of personal injury, and to incorporate into your designs such fail-safe functionality as is necessary. This includes the avoidance of certain dynamical situations such as open throttles and other 'positive feedback' scenarios where control of the system may be lost.

Pi Innovo makes no representation or warranties of any kind whatsoever with respect to the contents hereof, and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Pi Innovo shall not be liable for any errors contained herein, or for incidental or consequential damages in connection with the furnishing, performance or use of the software, associated hardware, or this written material.

Pi Innovo reserves the right to revise this publication from time to time, and to make changes in the content hereof without obligation to notify any person of such revision or changes.

A copy of the Pi Innovo Terms and Conditions of Sale is available on request, and includes a declaration of the warranty and limitation of liability which apply to all Pi Innovo products and services.

OpenECU developer software has been tested to work with Windows 10. OpenECU is compatible with Windows 7 SP1 (32-bit and 64-bit) and Windows XP SP3, but support for these operating systems is deprecated. OpenECU is not compatible with Windows Vista or Windows 8.

For C based development, OpenECU requires (at a minimum) one of the following compiler tools:

To program and calibrate an OpenECU with an application, OpenECU integrates with the following calibration tools. Only one calibration tool is required:

For Simulink model based development, OpenECU requires (at a minimum) the following MathWorks tools:

In addition, if you need to add state diagrams to the model, then you will also need:

Simulink Coder generates C code which does not lend itself to efficient repeatable testing. When creating a production version of your product, you may need better control of the structure of the C code generated from the model to reduce the cost of testing the C code against any industry standards. Under these circumstances you will also need:

To compile the generated C code (from either Simulink Coder or Embedded Coder), you will need one of the following compilers:

To program and calibrate an OpenECU with an application, OpenECU integrates with the following calibration tools. Only one calibration tool is required:

OpenECU works with a number of applications (both required and optional) supplied by other companies. If you intend to use OpenECU with one of the following tools, it is best to install them before OpenECU. The installer will then integrate the OpenECU developer software with these applications.

OpenECU works with a number of other applications, but these need not be installed prior to the OpenECU developer software.

The applications above have been listed with a version or release number. These are the versions or releases that OpenECU has been tested against. It may be that OpenECU will work with other versions of these applications, but it is recommended against and Pi may not provide technical support if these versions or releases are not used.

In summary, the following third party tools are compatible with this version of OpenECU:

Some third party tools have been marked deprecated and support for these tools will be removed in a future release of OpenECU.

To setup a floating license, the vender daemon will have to be run on the designated license server as well as have a license file on that machine. This section describes setting up the vendor daemon for a floating license.

To setup a node-locked license, a license file must be placed on the development machine.

GCC, also known as the GNU Compiler Collection, is a free compiler system produced by the GNU Project supporting various programming languages. The Free Software Foundation (FSF) distributes GCC under the GNU Public License (GNU GPL). GCC has been adopted as the standard compiler by most modern Unix-like computer operating system and has also been ported to a wide variety of processor architectures and is available for most embedded platforms.

GCC is used with permission under the GPL Version 3. If GCC is installed with OpenECU, the license file can be found in the [install path]\tools\gcc\ppc\docs directory of the OpenECU install. If desired, a copy of the GCC source code can be found and downloaded from the Pi Innovo website.

Support for GCC is currently in beta and as such, the user may run into issues which can cause an application to fail to build or run correctly on target. Listed below are a set of known issues when building an application using GCC. See Appendix J, Contact information for details on how to get in contact with OpenECU support if support is needed for using GCC.

GCC is not recommended for production programs at this time.

Python is general purpose, high level interpreted programming language, distributed under the PSF license which allows use in non open-source commercial applications. The license can be found in the [install path]\tools\python\license.txt file.

Before any engineering project reaches the design stage, several detailed planning stages should be carried out to define suitable functional requirements and specifications. Once you have a detailed target for your design, you can then start to create an implementation of the application.

For this example, we'll skip the functional specification stage for brevity. The application will read an analogue input every 100 milliseconds, transform the input into a temperature reading, check for sensor faults, and turn on a lamp if the temperature exceeds a limit. We have designed and partially implemented the application for you — you need only finish the implementation as described below.

To create the application, copy the [installation directory]\examples\c_api\step1_quick_start directory to somewhere local on your machine. Avoid placing the copy in a directory which contains a space in the path name. The copy has the following directories:

Open the src\step1_[target-name].c file in a text editor. The file contains a few variables and functions. The M460 version is shown in summary here (and indeed all subsequent examples reflect the M460, there will be some differences to files targeting other ECUs):

#include "openecu.h" 

/*...*/

#include "step1_m460_api.h" 

static S16 stp_adc_raw; 
static F32 stp_adc_eng; 

static OE_CAL F32 stpc_adc_limit = 90.0; 

void psc_initialise_app(void) 
{
    (void) pcx_config(PIO_CAN_A37_A36, PIO_CBAUD_500_KBPS); 
    (void) pcx_config(PIO_CAN_C37_C36, PIO_CBAUD_500_KBPS);

    /* Delete this comment and conditionals below when filling out this
     * example from the User Guide.
     */
#if (1)
#error "There is more to do here, see the User Guide." 
#endif
}

void stp_task_100ms(void) 
{
    /* Delete this comment and conditionals below when filling out this
     * example from the User Guide.
     */
#if (1)
#error "There is more to do here, see the User Guide."
#endif
}

void psc_background_app(void) 
{
}

We need to extend the basic functionality of the application to read an analogue input, process it into a temperature reading, and set the state of a PWM output based on the temperature calibration.

The input portion of the application means reading an analogue input and converting the result to a temperature. Add the following code to the stp_task_100ms() function.

    (void)  pax_adc_input  (PIO_AIN_A28 , &stp_adc_raw , FALSE );

We also need to initialise the library to read pin A28, add the following code to function psc_initialise_app().

    (void) pax_adc_input(PIO_AIN_A28, &stp_adc_raw, TRUE);

Initialisation uses the same function and parameters except for the last. The final parameter, set to TRUE this time, tells the function to initialise pin A28 to be processed as an analogue input.

With these changes in place, the application can now initialise the temperature sensor input pin and reads the temperature sensor every 100 milliseconds. We now need to convert the reading into a sensible engineering value.

Temperature sensors, and other sensors in general, can often generate a non-linear response to the physical characteristic under measurement. For the purposes of this exercise, we'll assume the temperature sensor is non-linear, and has a response similar to the following:

Figure 3.2. Transfer function for temperature sensor

The OpenECU library directly supports converting linear and non-linear analogue readings to engineering values with the put_process_analog_input() function. Add the following code immediately below the call to put_adc_in().

    put_process_analog_input(stp_adc_raw, 
                             0.1, 
                             &stp_adc_eng, 
                             &stp_adc_confirmed_raw_min_flt, 
                             &stp_adc_confirmed_raw_max_flt,
                             &stp_adc_confirmed_slew_rate_flt,
                             &stp_adc_confirmed_eng_min_flt,
                             &stp_adc_confirmed_eng_max_flt,
                             &stp_adc_transient_flt,
                             &stp_adc_process_analog_input_pai_cal, 
                             &stp_adc_process_analog_input_pai_wrk );

The function call references numerous variables which have not yet been declared. Add the following code after the declaration of stpc_adc_limit.

static BOOL stp_adc_confirmed_raw_min_flt;
static BOOL stp_adc_confirmed_raw_max_flt;
static BOOL stp_adc_confirmed_slew_rate_flt;
static BOOL stp_adc_confirmed_eng_min_flt;
static BOOL stp_adc_confirmed_eng_max_flt;
static BOOL stp_adc_transient_flt;

which declares the fault flags passed to put_process_analog_input(). We also need to declare the work space and calibration structures. Add the following code immediately after the fault variables:

static PUT_ANALOGUE_WORKSPACE_T stp_adc_process_analog_input_pai_wrk;
static const PUT_ANALOGUE_CAL_DATA_T stp_adc_process_analog_input_pai_cal  =
{
    &stpc_adc_min_raw_value, 
    &stpc_adc_max_raw_value,
    &stp_adc_eng_lookup_axis_size, 
    stpc_adc_eng_lookup_x_axis,
    stpc_adc_eng_lookup_z_data,
    &stpc_adc_min_eng_value, 
    &stpc_adc_max_eng_value,
    &stpc_adc_leaky_bucket_rise_rate, 
    &stpc_adc_leaky_bucket_fall_rate,
    &stpc_adc_leaky_bucket_flt_clear_level,
    &stpc_adc_default_output_value, 
    &stpc_adc_max_slew_rate 
};

static OE_CAL F32 stpc_adc_min_raw_value        = 90;
static OE_CAL F32 stpc_adc_max_raw_value        = 4000;

static const  S32 stp_adc_eng_lookup_axis_size  = 6;
static OE_CAL F32 stpc_adc_eng_lookup_x_axis[]  = {163,  917,  1671,
                                                   2424, 3178, 3932 };
static OE_CAL F32 stpc_adc_eng_lookup_z_data[]  = {135,  96,   74,
                                                   55,   20,   -42  };

static OE_CAL F32 stpc_adc_min_eng_value        = -40;
static OE_CAL F32 stpc_adc_max_eng_value        = 130;

static OE_CAL F32 stpc_adc_leaky_bucket_rise_rate       = 0.5;
static OE_CAL F32 stpc_adc_leaky_bucket_fall_rate       = 0.25;
static OE_CAL F32 stpc_adc_leaky_bucket_flt_clear_level = 0.5;

static OE_CAL F32 stpc_adc_default_output_value = 60;

static OE_CAL F32 stpc_adc_max_slew_rate        = 10000000;

We also need to initialise the workspace used for processing the analogue input, add the following code to function psc_initialise_app().

    put_process_analog_input_init(&stp_adc_process_analog_input_pai_wrk);

To be able to turn the warning lamp on or off, the application must decide whether the processed temperature input has exceeded a limit. We already have the processed temperature value (stp_adc_eng) and a calibratable temperature limit (stpc_adc_limit), comparing the two is simple. Add the following code to the end of function stp_task_100ms().

    stp_adc_state = (stp_adc_eng > stpc_adc_limit);

This code introduces a new variable, stp_adc_state. It holds the boolean result of the comparison, 0 if the temperature limit has not been exceeded, 1 if the temperature limit has been exceeded. Add the following code after the definition of stp_adc_eng.

static BOOL stp_adc_state;

Finally, the application must drive the lamp on or off based on the comparison. Add the following code to the end of function stp_task_100ms().

    (void)  pdx_pwm_output  (PIO_POT_A15, 
                                1000, 
                                stp_adc_state, 
                                0, 
                                FALSE); 

We also need to initialise the library to drive pin A15, add the following code to the end of function psc_initialise_app().

    (void) pdx_pwm_output(PIO_POT_A15, 1000, 0, 0, TRUE);

Most OpenECU hardware implements a switch to control whether an output driver can be turned on or not (although some do not, for instance, the M461). The switch can be used as a secondary system to prevent accidental changes to the output drivers. However, for the purposes of this exercise there is no need for this level of functionality, instead, we simply need to ensure that pin A15 can be driven. Add the following code to the end of function psc_initialise_app() if the ECU target supports the function (see pss_set_safety_switch()). for more).

    pss_set_safety_switch(TRUE);

Having followed the instructions you will have a simple application which reads an analogue temperature sensor and turns on a lamp if the temperature exceeds a calibratable limit. Your code should now look something like the following.

#include "openecu.h"

#include "step1_m460_api.h"

static S16  stp_adc_raw;
static F32  stp_adc_eng;
static BOOL stp_adc_state;

static OE_CAL F32 stpc_adc_limit = 90.0;

static BOOL stp_adc_confirmed_raw_min_flt;
static BOOL stp_adc_confirmed_raw_max_flt;
static BOOL stp_adc_confirmed_slew_rate_flt;
static BOOL stp_adc_confirmed_eng_min_flt;
static BOOL stp_adc_confirmed_eng_max_flt;
static BOOL stp_adc_transient_flt;

static OE_CAL F32 stpc_adc_min_raw_value                = 90;
static OE_CAL F32 stpc_adc_max_raw_value                = 4000;
static const  S32 stp_adc_eng_lookup_axis_size          = 6;
static OE_CAL F32 stpc_adc_eng_lookup_x_axis[]          = { 163,  917,  1671,
                                                            2424, 3178, 3932 };
static OE_CAL F32 stpc_adc_eng_lookup_z_data[]          = { 135,  96,   74,
                                                            55,   20,   -42  };
static OE_CAL F32 stpc_adc_min_eng_value                = -40;
static OE_CAL F32 stpc_adc_max_eng_value                = 130;
static OE_CAL F32 stpc_adc_leaky_bucket_rise_rate       = 0.5;
static OE_CAL F32 stpc_adc_leaky_bucket_fall_rate       = 0.25;
static OE_CAL F32 stpc_adc_leaky_bucket_flt_clear_level = 0.5;
static OE_CAL F32 stpc_adc_default_output_value         = 60;
static OE_CAL F32 stpc_adc_max_slew_rate                = 10000000;

static PUT_ANALOGUE_WORKSPACE_T stp_adc_process_analog_input_pai_wrk;
static const PUT_ANALOGUE_CAL_DATA_T stp_adc_process_analog_input_pai_cal =
{
    &stpc_adc_min_raw_value,
    &stpc_adc_max_raw_value,
    &stp_adc_eng_lookup_axis_size,
    stpc_adc_eng_lookup_x_axis,
    stpc_adc_eng_lookup_z_data,
    &stpc_adc_min_eng_value,
    &stpc_adc_max_eng_value,
    &stpc_adc_leaky_bucket_rise_rate,
    &stpc_adc_leaky_bucket_fall_rate,
    &stpc_adc_leaky_bucket_flt_clear_level,
    &stpc_adc_default_output_value,
    &stpc_adc_max_slew_rate
};

void psc_initialise_app(void)
{
    (void) pcx_config(PIO_CAN_A37_A36, PIO_CBAUD_500_KBPS);
    (void) pcx_config(PIO_CAN_C37_C36, PIO_CBAUD_500_KBPS);

    (void) pax_adc_input(PIO_AIN_A28, &stp_adc_raw, TRUE);

    put_process_analog_input_init(&stp_adc_process_analog_input_pai_wrk);

    (void) pdx_pwm_output(PIO_POT_A15, 1000, 0, 0, TRUE);

    pss_set_safety_switch(TRUE);
}

void stp_task_100ms(void)
{
    (void) pax_adc_input(PIO_AIN_A28, &stp_adc_raw, FALSE);

    put_process_analog_input(stp_adc_raw,
                             0.1,
                             &stp_adc_eng,
                             &stp_adc_confirmed_raw_min_flt,
                             &stp_adc_confirmed_raw_max_flt,
                             &stp_adc_confirmed_slew_rate_flt,
                             &stp_adc_confirmed_eng_min_flt,
                             &stp_adc_confirmed_eng_max_flt,
                             &stp_adc_transient_flt,
                             &stp_adc_process_analog_input_pai_cal,
                             &stp_adc_process_analog_input_pai_wrk);

    stp_adc_state = (stp_adc_eng > stpc_adc_limit);

    (void) pdx_pwm_output (PIO_POT_A15,
                           1000,
                           stp_adc_state,
                           0,
                           FALSE);
}

void psc_background_app(void)
{
}

Before we build the application and link it with the OpenECU library we need to specify how the library and application will work together. For instance, we need to tell the library that function stp_task_100ms must be called every 100 milliseconds. We do this by writing a data dictionary file and an interface specification file.

There are two aspects to linking an application with the OpenECU library:

Both the data dictionary file (or files) and the interface specification file are read by a tool which generates:

Name          Units         Class  Accuracy  Min  Max     Description 

stp_adc_raw  A/D counts  d    1         0    4096   Temp. pin A28 as A/D...

target-ecu
{
  hw-part-number  = "01T-068144"; 
  hw-issue-number = 1;
  hw-option       = "000";
}

application
{
  major-version    = 1; 
  minor-version    = 0;
  subminor-version = 0;

  description      = "Step-1 example for the C-API.";
  copyright        = "Copyright 2015, Pi Innovo";
  name             = "Step1 v%ver-major%.%ver-minor%.%ver-subminor%, %target%";

  os-native
  {
    stack-size = 8192; 

    task
    {
      name     = stp_task; 
      priority = 1;
      period   = 100;
      function = stp_task_100ms;
    }
  }
}

ccp-messaging
{
  cro             = 1785; 
  dto             = 1784;
  station-address = 0;
  can-bus         = 0;
  baud            = 500;

  enabled-during-application-mode = true;
}

ddes
{
  include-dde-tabbed "../interface_specification/step1.dde"; 

  generate-library-ddes = true;
}

The following sections detail how to build the application. Building the application can be done using either the Diab Compiler, or by using GCC. Please follow the steps relevant to your compiler.

SET OPENECU_DIAB=

SET OPENECU_DIAB=c:\diab\5.5.1.0\win32\bin\

The OpenECU is programmed with any CCP compliant tool. Specific instructions for ATI Vision, Vector CANape and ETAS INCA calibration tools are provided in Appendix C, Supporting tools.

At a minimum, the OpenECU device will need to be powered and be connected to the CCP tool over CAN as shown in the following diagram.

The OpenECU device can be programmed by following these steps:

Once programmed, ground the FEPS pin, power cycle the ECU, and the application will start. With your calibration tool, you will be able to view the stp_adc_raw and stp_adc_eng variables and see them vary as the voltage applied to pin A28 is varied.

Varying the voltage so stp_adc_eng exceeds the value for stpc_adc_limit (which defaults to 90°C) will cause the output driver for A15 to turn on and light the warning lamp.

Grounding the A28 pin will cause the application to determine there is a fault with the temperature sensor, and reported through the stp_adc_confirmed_raw_min_flt and/or stp_adc_confirmed_eng_min_flt variables.

There are some automatically added data definitions you can view which provides some information about the application (you can find a complete list in Section 8.1.7, “Automatic ASAP2 entries”).

With application source code, interface specification and data dictionary files in place, the application can be built and linked with the OpenECU and compiler libraries to generate a binary image which can be programmed and run on an OpenECU. Figure 4.6, “Building an application (in outline)” shows in outline how a build is achieved.

Figure 4.6. Building an application (in outline)

The build process has a number of inputs:

The inputs are processed in a number of steps to create intermediate objects:

From those intermediate steps, the final set of objects are created:

The C-API examples supplied with OpenECU show how each of these stages can be implemented in a simple fashion using batch files (see Section 4.6.8.1, “Building the examples”). These are the minimum steps required to build and can be copied if required. But an application may have additional stages to implement and there is no reason why a more sophisticated system (like make or SCons for example) might not be used.

As described already, the library has both data and function parts to its API. Some of the data components are hard to write and maintain by hand and so there is an interface tool which takes a simple description of the interface between the application and library, and generates the data components as required. This helps simplify the coding required to link the application and library together.

The interface tool and format of the interface specification file is given in detail in Section 8.1, “Interface and DDE tool”.

The interface specification also specifies the data dictionaries used to describe application data variables.

The OpenECU library can interact with calibration tools to read and write application data while the application is executing on the target. To support the interface between the calibration tool and the application, a data description file is required so the calibration tool understands how the application memory is laid out.

To support the interaction between the calibration tool and application, the interface tool can read a description of the application data and generate the data description file for the calibration tool. The application data is described in a set of data dictionary files explained in more detail in Section 8.1.5, “DDE specification” and the resulting data description file used by the calibration tool can also be used for reprogramming the ECU.

The framework of OpenECU requires application processing to occur in one or more tasks. These tasks are declared in the interface specification file, each declaring an application function to call and a priority to schedule the task relative to others.

In order to support the services provided by the library (e.g., J1939 messaging), the library defines a number of auxiliary tasks. These tasks have a unique priority relative to each other and the application tasks, as shown in Table 4.3, “Library and application tasks”.

Tasks can have different triggers. Triggers make the task become ready to run. The highest priority task ready to run is given the CPU.

As the application performs work, it may call the library to access the hardware or perform a function. Depending on the current state of the ECU or the data passed to the library function, the library may or may not be able to perform as required. The library employs two mechanisms to report status and error information when interacting with the application.

The error handling mechanisms are not mutually exclusive — a function may return a status value and raise an error in the system log. For each library function, the documentation in the sub-sections of Chapter 5, Library interface detail how a function handles errors.

The compiler library implements the C standard library as well as any additional functions and data the compiler may require. The OpenECU library relies on some of the standard C library functions and therefore the C library must be included in a build.

OpenECU does the least necessary to make the compiler library work for the functions OpenECU requires. Any additional setup, for instance, to allow memory allocation to work via malloc() and free(), must be performed by the application.

To allow for change in the library, some API features can become marked as deprecated. API features become deprecated when newer features replace older features, or because a change in API naming makes the API more consistent. For instance, when the library is updated to automatically perform a function that the application was required to perform then that function will become marked as deprecated.

As well as being marked deprecated in the documentation, the library header files mark deprecated functions by wrapping them in pre-processor conditional statements. For instance, the API function pss_set_switch() was deprecated (replaced by function pss_set_safety_switch()) and declared in the library header files as:

#if !defined(CFG_DONT_USE_DEPRECATED)
/* Deprecated, see pss_set_safety_switch(). */
extern void pss_set_switch
(
    BOOL pssf_enable
);
#else
#define pss_set_switch(pssf_enable) pss_set_switch_is_deprecated_see_user_guide()
#endif

By defining the CFG_DONT_USE_DEPRECATED macro in the compile command, the compiler pre-processor will replace deprecated API functions with functions which do not exist in the library resulting in a build which does not link. For instance, using the example above, calling pss_set_switch() results in the Diab linker generating the following error:

dld: warning: Undefined symbol 'pss_set_switch_is_deprecated_see_user_guide'
              in file '[file-name].o'
dld: error: Undefined symbols found - no output written

As part of the install process, a number of examples which use the library are installed, ready to be built.

Each example has the same directory layout. The directories store different types of files and includes a simple batch file to build the example.

Based on the C language, there are a limited number of global name-spaces for identifiers. To avoid clashes with application identifiers which share the same global name-spaces, the library uses a standard naming convention (covered in detail in Section 8.1.5.2, “DDE naming rules (prefix_style)”).

In short, the library uses a 3, 4 or 5 character prefix for all function and data identifiers. Each prefix identifies an area of functionality that the library covers, e.g., PDX for digital I/O or PJ1939 for J1939 messaging. This prefix scheme is similar to the DDE naming scheme covered in Section 8.1.5.2, “DDE naming rules (prefix_style)”.

The current composition of functionality is broken down into a set of features, each with a unique prefix, as shown in Table 5.1, “Library composition”.

The library is provided as a set of C include files and a library object file to be linked with the final application. There is a library object for each target and each compiler supported for that target. These files are located relative to the install location of OpenECU.

where: [install location] refers to the install location of OpenECU; [ecu] refers to the target ECU for the application; [option] refers to the specific ECU option for the application; and [processor] refers to the ECU's target processor (some ECUs have more than one processor populated).

For instance, when building for a M250 target ECU using Diab v5.5.1.0, the library header files and library object file are located at:

When compiling with GCC specifically, the libary object files will not follow the same naming convention mentioned above. Since GCC does not support non-VLE code, the platform is rebuilt, using Diab v5.9 but using non-VLE compiler options. Therefore the library object files are not named using the GCC compiler, but rather with the Diab Compiler (with no_vle specified). The library header files and library object files are located at:

Each feature is detailed in a separate section from other features. Each feature section is broken down as follows:

The C object names (for macros, typedefs, variables and so on) are fully linked, allowing for quick browsing.

The system feature (PSY) provides the base set of types for the library and a simple logging mechanism for recording conditions that the library believes to be in error.

The library types (BOOL, S8, U8, S16, U16, S32, U32, U64, F32, F64) are to be used when interfacing with the library. Whether that be parameter types, return types, or member types of structures. Each represents an integer or floating point type of a minimum bit width (but the actual underlying type may implement a larger bit width).

The library also defines the NULL, pointer, as well as the TRUE, and FALSE booleans as macros, if those macros have not already been defined.

As described in Section 4.6.5, “Library status and error handling”, the library records some errors in a log. The system feature gives access to the log for debugging purposes. The log consists of a fixed size array, where each element stores a reference to the feature which raised the error and a code for the error. Once the log is full, further errors raised by the library are discarded.

The feature reference matches one of the feature macros (e.g., PSY_PAX for the analogue input/output feature). The code for an error matches one of the corresponding feature's Pxxx_ERROR_CODE_T enumeration (e.g., PAX_ERROR_CODE_T).

The application can access elements of the log through the psy_get_error() function. The number of reported errors can be determined by calling psy_get_num_errors().

An index of interface objects for this feature.

An index of interface objects for this feature.