Concepts

MicroEJ Platform Configuration

A MicroEJ Platform is described by a .platform file. This file is usually called [name].platform, and is stored at the root of a MicroEJ Platform configuration project called [name]-configuration.

The configuration file is recognized by the MicroEJ Platform builder. The MicroEJ Platform builder offers a visualization with two tabs:

MicroEJ Platform Configuration Overview Tab

MicroEJ Platform Configuration Overview Tab

This tab groups the basic platform information used to identify it: its name, its version, etc. These tags can be updated at any time.

MicroEJ Platform Configuration Content Tab

MicroEJ Platform Configuration Content Tab

This tab shows all additional modules (see Modules) which can be installed into the platform in order to augment its features. The modules are sorted by groups and by functionality. When a module is checked, it will be installed into the platform during the platform creation.

Modules

The primary mechanism for augmenting the capabilities of a Platform is to add modules to it.

A MicroEJ module is a group of related files (Foundation Libraries, scripts, link files, C libraries, Simulator, tools, etc.) that together provide all or part of a platform capability. Generally, these files serve a common purpose. For example, providing an API, or providing a library implementation with its associated tools.

The list of modules is in the second tab of the platform configuration tab. A module may require a configuration step to be installed into the platform. The Modules Detail view indicates if a configuration file is required.

Low Level API Pattern

Principle

Each time the user has to supply the C code that links a platform component to the target hardware, a Low Level API is defined. There is a standard pattern for the definition and implementation of these APIs. Each interface has a name and is specified by two header files:

  • [INTERFACE_NAME].h specifies the functions that make up the public API of the implementation. In some cases the user code will never act as a client of the API, and so will never use this file.
  • [INTERFACE_NAME]_impl.h specifies the functions that must be coded by the user in the implementation.

The user creates implementations of the interfaces, each captured in a separate C source file. In the simplest form of this pattern, only one implementation is permitted, as shown in the illustration below.

Low Level API Pattern (single implementation)

Low Level API Pattern (single implementation)

The following figure shows a concrete example of an LLAPI. The C world (the board support package) has to implement a send function and must notify the library using a receive function.

Low Level API Example

Low Level API Example

Multiple Implementations and Instances

When a Low Level API allows multiple implementations, each implementation must have a unique name. At run-time there may be one or more instances of each implementation, and each instance is represented by a data structure that holds information about the instance. The address of this structure is the handle to the instance, and that address is passed as the first parameter of every call to the implementation.

The illustration below shows this form of the pattern, but with only a single instance of a single implementation.

Low Level API Pattern (multiple implementations/instances)

Low Level API Pattern (multiple implementations/instances)

The #define statement in MYIMPL.c specifies the name given to this implementation.