Low Level API¶
This chapter describes succinctly the available Low Level API, module by
module. The exhaustive documentation of each LLAPI function is available
in the LLAPI header files themselves. The required header files to
implement are automatically copied in the folder include of MicroEJ
Platform at platform build time.
LLMJVM: MicroEJ Core Engine¶
Naming Convention¶
The Low Level MicroEJ Core Engine API, the LLMJVM API, relies on
functions that need to be implemented. The naming convention for such
functions is that their names match the LLMJVM_IMPL_* pattern.
Header Files¶
Three C header files are provided:
LLMJVM_impl.h
Defines the set of functions that the BSP must implement to launch and schedule the virtual machine
LLMJVM.h
Defines the set of functions provided by virtual machine that can be called by the BSP when using the virtual machine
LLBSP_impl.h
Defines the set of extra functions that the BSP must implement.
LLKERNEL: Multi-Sandbox¶
Naming Convention¶
The Low Level Kernel API, the LLKERNEL API, relies on functions that
need to be implemented. The naming convention for such functions is that
their names match the LLKERNEL_IMPL_* pattern.
Header Files¶
One C header file is provided:
LLKERNEL_impl.h
Defines the set of functions that the BSP must implement to manage memory allocation of dynamically installed applications.
LLSP: Shielded Plug¶
Naming Convention¶
The Low Level Shielded Plug API, the LLSP API, relies on functions
that need to be implemented. The naming convention for such functions is
that their names match the LLSP_IMPL_* pattern.
Header Files¶
The implementation of the Shielded Plug for the Platform assumes some support from the underlying RTOS. It is mainly related to provide some synchronization when reading / writing into Shielded Plug blocks.
LLSP_IMPL_syncWriteBlockEnterandLLSP_IMPL_syncWriteBlockExitare used as a semaphore by RTOS tasks. When a task wants to write to a block, it “locks” this block until it has finished to write in it.LLSP_IMPL_syncReadBlockEnterandLLSP_IMPL_syncReadBlockExitare used as a semaphore by RTOS tasks. When a task wants to read a block, it “locks” this block until it is ready to release it.
The [SP] specification provides a mechanism to force a task to wait
until new data has been provided to a block. The implementation relies
on functions LLSP_IMPL_wait and LLSP_IMPL_wakeup to block the
current task and to reschedule it.
LLEXT_RES: External Resources Loader¶
Principle¶
This LLAPI allows to use the External Resource Loader. When installed, the External Resource Loader is notified when the MicroEJ Core Engine is not able to find a resource (an image, a file etc.) in the resources area linked with the MicroEJ Core Engine.
When a resource is not available, the MicroEJ Core Engine invokes the External Resource Loader in order to load an unknown resource. The External Resource Loader uses the LLAPI EXT_RES to let the BSP loads or not the expected resource. The implementation has to be able to load several files in parallel.
Naming Convention¶
The Low Level API, the LLEXT_RES API, relies on functions that need
to be implemented. The naming convention for such functions is that
their names match the LLEXT_RES_IMPL_* pattern.
Header Files¶
One header file is provided:
LLEXT_RES_impl.h
Defines the set of functions that the BSP must implement to load some external resources.
LLCOMM: Serial Communications¶
Naming Convention¶
The Low Level Comm API (LLCOMM), relies on functions that need to be
implemented by engineers in a driver. The names of these functions match
the LLCOM_BUFFERED_CONNECTION_IMPL_* or the
LLCOM_CUSTOM_CONNECTION_IMPL_*pattern.
Header Files¶
Four C header files are provided:
LLCOMM_BUFFERED_CONNECTION_impl.h
Defines the set of functions that the driver must implement to provide a Buffered connection
LLCOMM_BUFFERED_CONNECTION.h
Defines the set of functions provided by ECOM Comm that can be called by the driver (or other C code) when using a Buffered connection
LLCOMM_CUSTOM_CONNECTION_impl.h
Defines the set of functions that the driver must implement to provide a Custom connection
LLCOMM_CUSTOM_CONNECTION.h
Defines the set of functions provided by ECOM Comm that can be called by the driver (or other C code) when using a Custom connection
LLUI_INPUT: Input¶
LLUI_INPUT API is composed of the following files:
- the file
LLUI_INPUT_impl.hthat defines the functions to be implemented - the file
LLUI_INPUT.hthat provides the functions for sending events
Implementation¶
LLUI_INPUT_IMPL_initialize is the first function called by the input
engine, and it may be used to initialize the underlying devices and bind
them to event generator IDs.
LLUI_INPUT_IMPL_enterCriticalSection and
LLUI_INPUT_IMPL_exitCriticalSection need to provide the Input Engine with a
critical section mechanism for synchronizing devices when sending events
to the internal event queue. The mechanism used to implement the
synchronization will depend on the platform configuration (with or
without RTOS), and whether or not events are sent from an interrupt
context.
LLUI_INPUT_IMPL_getInitialStateValue allows the input stack to get the
current state for devices connected to the MicroUI States event
generator, such as switch selector, coding wheels, etc.
Sending Events¶
The LLUI_INPUT API provides two generic functions for a C driver to
send data to its associated event generator:
LLUI_INPUT_sendEvent: Sends a 32-bit event to a specific event generator, specified by its ID. If the input buffer is full, the event is not added, and the function returnsLLUI_INPUT_NOK; otherwise it returnsLLUI_INPUT_OK.LLUI_INPUT_sendEvents: Sends a frame constituted by several 32-bit events to a specific event generator, specified by its ID. If the input buffer cannot receive the whole data, the frame is not added, and the function returnsLLUI_INPUT_NOK; otherwise it returnsLLUI_INPUT_OK.
Events will be dispatched to the associated event generator that will be responsible for decoding them (see Generic Event Generators).
The UI extension provides an implementation for each of MicroUI’s built-in event generators. Each one has dedicated functions that allows a driver to send them structured data without needing to understand the underlying protocol to encode/decode the data. The following table shows the functions provided to send structured events to the predefined event generators:
| Function name | Default event generator kind [1] | Comments |
|---|---|---|
LLUI_INPUT_sendCommandEvent |
Command | Constants are provided that define all standard MicroUI commands [MUI]. |
|
Buttons | In the case of chronological sequences (for example, a RELEASE that may occur only after a PRESSED), it is the responsibility of the driver to ensure the integrity of such sequences. |
|
Pointer | In the case of chronological sequences (for example, a RELEASE that may occur only after a PRESSED), it is the responsibility of the driver to ensure the integrity of such sequences. Depending on whether a button of the pointer is pressed while moving, a DRAG and/or a MOVE MicroUI event is generated. |
LLUI_INPUT_sendStateEvent |
States | The initial value of each
state machine (of a States)
is retrieved by a call to
LLUI_INPUT_IMPL_getInitialStateValue
that must be implemented by
the device. Alternatively,
the initial value can be
specified in the XML static
configuration. |
|
Pointer | In the case of chronological sequences (for example, a RELEASE that may only occur after a PRESSED), it is the responsibility of the driver to ensure the integrity of such sequences. These APIs will generate a DRAG MicroUI event instead of a MOVE while they represent a touch pad over a display. |
| [1] | The implementation class is a subclass of the MicroUI class of the column. |
Event Buffer¶
Functions LLUI_INPUT_IMPL_log_xxx allow logging the use of event buffer.
Implementation of these LLAPIs is already available on the MicroEJ Central Repository (LLUI_INPUT_LOG_impl.c).
This implementation is using an array to add some metadata to each event.
This metadata is used when the BSP is calling LLUI_INPUT_dump().
When no implementation is included in the BSP, the call to LLUI_INPUT_dump() has no effect (no available logger).
LLUI_DISPLAY: Display¶
Principle & Naming Convention¶
The Graphics Engine provides some Low Level APIs to connect a display driver. The file LLUI_DISPLAY_impl.h defines the API headers to be implemented. For the APIs themselves, the naming convention is that their names match the *_IMPL_* pattern when the functions need to be implemented:
LLUI_DISPLAY_IMPL_initializeLLUI_DISPLAY_IMPL_binarySemaphoreTakeLLUI_DISPLAY_IMPL_binarySemaphoreGiveLLUI_DISPLAY_IMPL_flush
Some additional Low Level APIs allow you to connect display extra features. These Low Level APIs are not required. When they are not implemented, a default implementation is used (weak function). It concerns backlight, contrast, etc.
This describes succinctly some LLUI_DISPLAY_IMPL functions. Please refer to documentation inside header files to have more information.
Initialization¶
Each Graphics Engine gets initialized by calling the function LLUI_DISPLAY_IMPL_initialize: It asks its display driver to initialize itself. The implementation function has to fill the given structure LLUI_DISPLAY_SInitData. This structure allows to retrieve the size of the virtual and physical screen, the back buffer address (where MicroUI is drawing). The implementation has to give two binary semaphores.
Image Heap¶
The display driver must reserve a runtime memory buffer for creating dynamic images when using MicroUI ResourceImage and BufferedImage classes methods. The display driver may choose to reserve an empty buffer. Thus, calling MicroUI methods will result in a MicroUIException exception.
The section name is .bss.microui.display.imagesHeap.
Functions LLUI_DISPLAY_IMPL_image_heap_xxx allow to control the image buffers allocation in the image heap.
Implementation of these LLAPIs is already available on the MicroEJ Central Repository (LLUI_DISPLAY_HEAP_impl.c).
This implementation is using a best fit allocator.
It can be updated to log the allocations, the remaining space, etc.
When no implementation is included in the BSP, the default Graphics Engine’a allocator (a best fit allocator) is used.
External Font Heap¶
The display driver must reserve a runtime memory buffer for loading external fonts (fonts located outside CPU addresses ranges). The display driver may choose to reserve an empty buffer. Thus, calling MicroUI Font methods will result in empty drawings of some characters.
The section name is .bss.microui.display.externalFontsHeap.
Flush and Synchronization¶
The back buffer (graphics buffer) address set in Initialization function is the address for the very first drawing. The content of this buffer is flushed to the external display memory by the function LLUI_DISPLAY_flush. The parameters define the rectangular area of the content which has changed during the last drawing action, and which must be flushed to the display buffer (dirty area). This function should be atomic: the implementation has to start another task or a hardware device (often a DMA) to perform the copy.
As soon as the application performs a new drawing, the Graphics Engine locks the thread. It will automatically unlocked when the BSP will call LLUI_DISPLAY_flushDone at the end of the copy,
Display Characteristics¶
Function LLUI_DISPLAY_IMPL_isColor directly implements the method from the MicroUI Display class of the same name. The default implementation always returns true when the number of bits per pixel is higher than 4.
Function LLUI_DISPLAY_IMPL_getNumberOfColors directly implements the method from the MicroUI Display class of the same name. The default implementation returns a value according to the number of bits by pixel, without taking into consideration the alpha bit(s).
Function LLUI_DISPLAY_IMPL_isDoubleBuffered directly implements the method from the MicroUI Display class of the same name. The default implementation returns true. When LLAPI implementation targets a display in direct mode, this function must be implemented and return false.
Contrast¶
LLUI_DISPLAY_IMPL_setContrast and LLUI_DISPLAY_IMPL_getContrast are called to set/get the current display contrast intensity. The default implementations don’t manage the contrast.
BackLight¶
LLUI_DISPLAY_IMPL_hasBacklight indicates whether the display has backlight capabilities.
LLUI_DISPLAY_IMPL_setBacklight and LLUI_DISPLAY_IMPL_getBacklight are called to set/get the current display backlight intensity.
Color Conversions¶
The following functions are only useful (and called) when the display is not a standard display, see Pixel Structure.
LLUI_DISPLAY_IMPL_convertARGBColorToDisplayColor is called to convert a 32-bit ARGB MicroUI color in 0xAARRGGBB format into the “driver” display color.
LLUI_DISPLAY_IMPL_convertDisplayColorToARGBColor is called to convert a display color to a 32-bit ARGB MicroUI color.
CLUT¶
The function LLUI_DISPLAY_IMPL_prepareBlendingOfIndexedColors is called when drawing an image with indexed color. See CLUT to have more information about indexed images.
Image Decoders¶
The API LLUI_DISPLAY_IMPL_decodeImage allows to add some additional image decoders.
LLUI_LED: LEDs¶
Principle¶
The LEDs engine provides Low Level APIs for connecting LED drivers. The file LLUI_LED_impl.h, which comes with the LEDs engine, defines the API headers to be implemented.
Naming Convention¶
The Low Level APIs rely on functions that must be implemented. The naming convention for such functions is that their names match the *_IMPL_* pattern.
Initialization¶
The first function called is LLUI_LED_IMPL_initialize, which allows the driver to initialize all LED devices. This method must return the available number of LEDs. Each LED has a unique identifier. The first LED has the ID 0, and the last has the ID NbLEDs – 1.
This UI extension provides support to efficiently implement the set of methods that interact with the LEDs provided by a device. Below are the relevant C functions:
LLUI_LED_IMPL_getIntensity: Get the intensity of a specific LED using its ID.LLUI_LED_IMPL_setIntensity: Set the intensity of an LED using its ID.
LLVG: VectorGraphics¶
Principle¶
The VG Pack provides a Low Level API for initializing the Vector Graphics engine. The file LLVG_impl.h, which comes with the VG Pack, defines the API headers to be implemented.
Naming Convention¶
The Low Level APIs rely on functions that must be implemented. The naming convention for such functions is that their names match the *_IMPL_* pattern.
Initialization¶
The function LLVG_IMPL_initialize is the first native function called by the MicroVG implementation.
It allows to initialize all C components: GPU initialization, Font engine, heap management, etc.
LLVG_MATRIX: Matrix¶
Principle¶
The Matrix module provides Low Level APIs for manipulating matrices. The file LLVG_MATRIX_impl.h, which comes with the Matrix module, defines the API headers to be implemented.
Naming Convention¶
The Low Level APIs rely on functions that must be implemented. The naming convention for such functions is that their names match the *_IMPL_* pattern.
Implementation¶
The matrix functions are divided in four groups:
- identity and copy: fill an identity matrix or copy a matrix to another one.
- setXXX: erase the content of the matrix by an operation (translate, rotation, scaling, concatenate).
- xxx (no prefix): perform an operation with the matrix as first argument:
M' = M * xxx(x, y)wherexxxis the operation (translate, rotation, scaling, concatenate). - postXXX: perform an operation with the matrix as second argument:
M' = xxx(x, y) * Mwherexxxis the operation (translate, rotation, scaling, concatenate).
LLVG_PATH: Vector Path¶
Principle¶
The Path module provides Low Level APIs for creating paths in platform specific format. The file LLVG_PATH_impl.h, which comes with the Path module, defines the API headers to be implemented.
The file LLVG_PAINTER_impl.h defines the API headers to be implemented to draw the paths (with a color or a gradient).
Naming Convention¶
The Low Level APIs rely on functions that must be implemented. The naming convention for such functions is that their names match the *_IMPL_* pattern.
Creation¶
The header file LLVG_PATH_impl.h allows to convert a MicroVG library format path in a buffer that represents the same vectorial path in the platform specific format (generally GPU format).
The first function called is LLVG_PATH_IMPL_initializePath, which allows the implementation to initialize the path buffer.
The buffer is allocated in the Java heap and its size is fixed by the MicroVG implementation.
When the buffer is too small for the platform specific format, the implementation has to return the expected buffer size instead of the keyword LLVG_SUCCESS.
The next steps consist in appending some commands in the path buffer. The command encoding depends on the platform specific format. When the buffer is too small to add the new command, the implementation has to return a value that indicates the number of bytes the array must be enlarged with.
List of commands:
LLVG_PATH_CMD_CLOSE: MicroVG “CLOSE” command.LLVG_PATH_CMD_MOVE: MicroVG “MOVE ABS” command.LLVG_PATH_CMD_MOVE_REL: MicroVG “MOVE REL” command.LLVG_PATH_CMD_LINE: MicroVG “LINE ABS” command.LLVG_PATH_CMD_LINE_REL: MicroVG “LINE REL” command.LLVG_PATH_CMD_QUAD: MicroVG “QUAD ABS” command.LLVG_PATH_CMD_QUAD_REL: MicroVG “QUAD REL” command.LLVG_PATH_CMD_CUBIC: MicroVG “CUBIC ABS” command.LLVG_PATH_CMD_CUBIC_REL: MicroVG “CUBIC REL” command.
List of operations:
LLVG_PATH_IMPL_appendPathCommand1: Adds a command with 1 point parameter in the array.LLVG_PATH_IMPL_appendPathCommand2: Adds a command with 2 points parameter in the array.LLVG_PATH_IMPL_appendPathCommand3: Adds a command with 3 points parameter in the array.
A path is automatically closed by the MicroVG implementation (by adding the command LLVG_PATH_CMD_CLOSE).
A path can be reopened (function LLVG_PATH_IMPL_reopenPath), that consists in removing the last added command (LLVG_PATH_CMD_CLOSE command) from the buffer.
Drawing¶
The header file LLVG_PAINTER_impl.h provides the functions called by the application via VectorGraphicsPainter to draw a path.
- A path can be drawn with a 32-bit color (ARGB8888):
LLVG_PAINTER_IMPL_drawPath. - A path can be drawn with a linear gradient:
LLVG_PAINTER_IMPL_drawGradient.
The drawing destination is symbolized by a MicroUI GraphicsContext: a pointer to a MICROUI_GraphicsContext instance.
Like MicroUI Painter natives, the implementation has to synchronize the drawings with the MicroUI Graphics Engine.
LLVG_GRADIENT: Vector Linear Gradient¶
Principle¶
The Gradient module provides Low Level APIs for creating linear gradients in platform specific format. The file LLVG_GRADIENT_impl.h, which comes with the Gradient module, defines the API headers to be implemented.
Naming Convention¶
The Low Level APIs rely on functions that must be implemented. The naming convention for such functions is that their names match the *_IMPL_* pattern.
Implementation¶
Only one function has to be implemented: LLVG_GRADIENT_IMPL_initializeGradient.
It consists in encoding the MicroVG LinearGradient in a buffer that represents the linear gradient in platform specific format (generally GPU format).
This function allows the implementation to initialize the gradient buffer.
The buffer is allocated in the Java heap and its size is fixed by the MicroVG implementation.
When the buffer is too small for the platform specific format, the implementation has to return the expected buffer size instead of the keyword LLVG_SUCCESS.
LLVG_FONT: Vector Font¶
Principle¶
The Font module provides Low Level APIs for decoding fonts (LLVG_FONT_impl.h) and rendering texts (LLVG_PAINTER_impl.h). Both header files, which come with the Font module, define the API headers to be implemented.
Naming Convention¶
The Low Level APIs rely on functions that must be implemented. The naming convention for such functions is that their names match the *_IMPL_* pattern.
Initialization¶
The first function called is LLVG_FONT_IMPL_load_font, which allows the driver to open a font file from its name.
This function takes a parameter to configure the text rendering engine:
- Simple layout: uses the glyph advance metrics and the font kerning table.
- Complex layout: uses the font GPOS and GSUB tables.
See VectorFont for more information.
The implementation must manage its own heap to keep the font opened.
The font’s data are disposed by a call to LLVG_FONT_IMPL_dispose.
Font Characteristics¶
The other functions in LLVG_FONT_impl.h consist in retrieving some font characteristics according a text and a font size: string width, string height, baseline, etc.
See VectorFont for more information.
Drawing¶
The header file LLVG_PAINTER_impl.h provides the functions called by the application via VectorGraphicsPainter to draw a path.
- A string can be drawn with a 32-bit color (ARGB8888):
LLVG_PAINTER_IMPL_drawString. - A string can be drawn with a linear gradient:
LLVG_PAINTER_IMPL_drawStringGradient. - A string can be draw on a circle:
LLVG_PAINTER_IMPL_drawStringOnCircleandLLVG_FONT_PAINTER_IMPL_drawStringOnCircleGradient.
The drawing destination is symbolized by a MicroUI GraphicsContext: a pointer to a MICROUI_GraphicsContext instance.
Like MicroUI Painter natives, the implementation has to synchronize the drawings with the MicroUI Graphics Engine.
LLNET: Network¶
Naming Convention¶
The Low Level API, the LLNET API, relies on functions that need to
be implemented. The naming convention for such functions is that their
names match the LLNET_IMPL_* pattern.
Header Files¶
Several header files are provided:
LLNET_CHANNEL_impl.h
Defines a set of functions that the BSP must implement to initialize the Net native component. It also defines some configuration operations to setup a network connection.
LLNET_SOCKETCHANNEL_impl.h
Defines a set of functions that the BSP must implement to create, connect and retrieve information on a network connection.
LLNET_STREAMSOCKETCHANNEL_impl.h
Defines a set of functions that the BSP must implement to do some I/O operations on connection oriented socket (TCP). It also defines function to put a server connection in accepting mode (waiting for a new client connection).
LLNET_DATAGRAMSOCKETCHANNEL_impl.h
Defines a set of functions that the BSP must implement to do some I/O operations on connectionless oriented socket (UDP).
LLNET_DNS_impl.h
Defines a set of functions that the BSP must implement to request host IP address associated to a host name or to request Domain Name Service (DNS) host IP addresses setup in the underlying system.
LLNET_NETWORKADDRESS_impl.h
Defines a set of functions that the BSP must implement to convert string IP address or retrieve specific IP addresses (lookup, localhost or loopback IP address).
LLNET_NETWORKINTERFACE_impl.h
Defines a set of functions that the BSP must implement to retrieve information on a network interface (MAC address, interface link status, etc.).
LLNET_SSL: SSL¶
Naming Convention¶
The Low Level API, the LLNET_SSL API, relies on functions that need
to be implemented. The naming convention for such functions is that
their names match the LLNET_SSL_* pattern.
Header Files¶
Three header files are provided:
LLNET_SSL_CONTEXT_impl.h
Defines a set of functions that the BSP must implement to create a SSL Context and to load CA (Certificate Authority) certificates as trusted certificates.
LLNET_SSL_SOCKET_impl.h
Defines a set of functions that the BSP must implement to initialize the SSL native components, to create an underlying SSL Socket and to initiate a SSL session handshake. It also defines some I/O operations such as
LLNET_SSL_SOCKET_IMPL_writeorLLNET_SSL_SOCKET_IMPL_readused for encrypted data exchange between the client and the server.LLNET_SSL_X509_CERT_impl.h
Defines a function named
LLNET_SSL_X509_CERT_IMPL_parsefor certificate parsing. This function checks if a given certificate is an X.509 digital certificate and returns its encoded format type : Distinguished Encoding Rules (DER) or Privacy-Enchanced Mail (PEM).
LLECOM_NETWORK: Network Interfaces¶
Naming Convention¶
The Low Level Network Interfaces API (LLECOM_NETWORK), relies on functions that need to
be implemented by engineers in a driver. The names of these functions
match the LLECOM_NETWORK_IMPL_* pattern.
Header Files¶
One header file is provided:
LLECOM_NETWORK_impl.h
Defines the set of functions that the BSP must implement to manage and configure and TCP/IP network interfaces.
LLECOM_WIFI: Wi-Fi Management¶
Naming Convention¶
The Low Level Wi-FI API (LLECOM_WIFI), relies on functions that need to
be implemented by engineers in a driver. The names of these functions
match the LLECOM_WIFI_IMPL_* pattern.
Header Files¶
One header file is provided:
LLECOM_WIFI_impl.h
Defines the set of functions that the BSP must implement to manage and configure Wi-FI access points.
LLBLUETOOTH: Bluetooth¶
Naming Convention¶
The Low Level Bluetooth API (LLBLUETOOTH), relies on functions that need to
be implemented by engineers in a driver. The names of these functions
match the LLBLUETOOTH_IMPL_* pattern.
Header Files¶
One header file is provided:
LLBLUETOOTH_impl.h
Defines the set of functions that the BSP must implement to manage and configure and Bluetooth module.
LLEVENT: Event Queue¶
Naming Convention¶
The Low Level Event Queue API (LLEVENT), relies on functions that need to
be implemented by engineers in a driver. The names of these functions
match the LLEVENT_IMPL_* or LLEVENT_* pattern.
Header Files¶
Two header files are provided:
LLEVENT_impl.h
Defines the set of functions that the BSP must implement to manage, offer/handle events from the Event Queue.
LLEVENT.h
Defines the set of functions that the BSP must implement to use the Event Queue from the native side.
LLFS: File System¶
Naming Convention¶
The Low Level File System API (LLFS), relies on functions that need to
be implemented by engineers in a driver. The names of these functions
match the LLFS_IMPL_* and the LLFS_File_IMPL_* pattern.
Header Files¶
Two C header files are provided:
LLFS_impl.h
Defines a set of functions that the BSP must implement to initialize the FS native component. It also defines some functions to manage files, directories and retrieve information about the underlying File System (free space, total space, etc.).
LLFS_File_impl.h
Defines a set of functions that the BSP must implement to do some I/O operations on files (open, read, write, close, etc.).
LLHAL: Hardware Abstraction Layer¶
Naming Convention¶
The Low Level API, the LLHAL API, relies on functions that need to
be implemented. The naming convention for such functions is that their
names match the LLHAL_IMPL_* pattern.
Header Files¶
One header file is provided:
LLHAL_impl.h
Defines the set of functions that the BSP must implement to configure and drive some MCU GPIO.
LLDEVICE: Device Information¶
Naming Convention¶
The Low Level Device API (LLDEVICE), relies on functions that need to be
implemented by engineers in a driver. The names of these functions match
the LLDEVICE_IMPL_* pattern.
Header Files¶
One C header file is provided:
LLDEVICE_impl.h
Defines a set of functions that the BSP must implement to get the platform architecture name and unique device identifier.
LLWATCHDOG_TIMER: Watchdog Timer¶
Naming Convention¶
The Low Level Watchdog Timer API (LLWATCHDOG_TIMER), provides functions that allow the use of this API
at the BSP level in C. The names of these functions match the LLWATCHDOG_TIMER_IMPL_* pattern.
The Watchdog API is delivered with a Generic C implementation on which the platform must
depend. This implementation relies on functions that need to be implemented by engineers in a driver.
The name of these functions match the LLWATCHDOG_TIMER_IMPL_*_action pattern.
Header Files¶
One C header file is provided:
LLWATCHDOG_TIMER_impl.h
Defines a set of functions that can be used at BSP level if required.
This C header file contains functions to implement:
watchdog_timer_helper.h
Defines a set of functions that the BSP must implement to link the platform watchdog timer to the Watchdog Timer library.
LLSEC: Security¶
Naming Convention¶
The Low Level Security API (LLSEC) provides functions that allow the use of this API at the
BSP level in C. The names of these functions match the LLSEC_*_IMPL_* pattern.
Header Files¶
Several C header files are provided:
LLSEC_CIPHER_impl.h
Defines a set of functions that must be implemented by the BSP in order to decrypt and encrypt data using cryptographic ciphers.
LLSEC_CONSTANTS.h
Defines constants for certificates encoding formats.
LLSEC_DIGEST_impl.h
Defines a set of functions that must be implemented by the BSP in order to support message digest algorithms such as SHA-1 or SHA-256.
LLSEC_ERRORS.h
Defines the Security API error return codes.
LLSEC_KEY_FACTORY_impl.h
Defines a set of functions that must be implemented by the BSP in order to get keys informations such as algorithm or encoded form.
LLSEC_KEY_PAIR_GENERATOR_impl.h
Defines a set of functions that must be implemented by the BSP in order to generate private/public key pairs.
LLSEC_MAC_impl.h
Defines a set of functions that must be implemented by the BSP in order to support MAC algorithms.
LLSEC_PRIVATE_KEY_impl.h
Defines a set of functions that must be implemented by the BSP in order to encode private keys in DER format.
LLSEC_PUBLIC_KEY_impl.h
Defines a set of functions that must be implemented by the BSP in order to encode public keys.
LLSEC_RANDOM_impl.h
Defines a set of functions that must be implemented by the BSP in order to generate random data.
LLSEC_SIG_impl.h
Defines a set of functions that must be implemented by the BSP in order to support signatures functionalities.
LLSEC_X509_CERT_impl.h
Defines a set of functions that must be implemented by the BSP in order to manage X509 certificates operations like getting the public key, extracting the issuer, etc.
Docs
Resources
Forum