Silicon Labs UG103.4, HAL User Manual
UG103.4: HAL Fundamentals
Silicon Labs HAL (Hardware Abstraction Layer) is program code
between a system’s hardware and its software that provides a
consistent interface for applications that can run on several different hardware platforms. The HAL is designed for developers using EmberZNet PRO with the EFR32MG family of products.
Silicon Labs’ Fundamentals series covers topics that project managers, application designers, and developers should understand before beginning to work on an embedded
networking solution using Silicon Labs chips, networking stacks such as EmberZNet
PRO or Silicon Labs Bluetooth®, and associated development tools. The documents
can be used as a starting place for anyone needing an introduction to developing wireless networking applications, or who is new to the Silicon Labs development environment.
KEY POINTS
• Provides information on how the HAL is
organized, including naming conventions,
API files, and directory structure.
• Includes an overview of each of the main
subsections of the HAL functionality.
• Describes how to adapt the HAL to your
specific hardware and application
requirements.
silabs.com | Building a more connected world. Rev. 1.4
UG103.4: HAL Fundamentals
Introduction
1. Introduction
The Hardware Abstraction Layer (HAL) is program code between a system’s hardware and its software that provides a consistent interface for applications that can run on several different hardware platforms. To take advantage of this capability, applications should access hardware through the API provided by the HAL, rather than directly. Then, when you move to new hardware, you only need to
update the HAL. In some cases, due to extreme differences in hardware, the HAL API may also change slightly to accommodate the
new hardware. In these cases, the limited scope of the update makes moving the application easier with the HAL than without.
The introductory parts of this document are recommended for all software developers who are using EmberZNet PRO. Developers
needing to modify the HAL or port it to new a hardware platform will want to read the entire document to understand how to make
changes while meeting the requirements of the networking stack.
silabs.com | Building a more connected world. Rev. 1.4 | 2
UG103.4: HAL Fundamentals
HAL API Organization
2. HAL API Organization
The HAL API is organized into the following functional sections, which are described in section 5. HAL API Description:
• Common microcontroller functions: APIs for control of the MCU behavior and configuration.
• Token access: APIs for token acces, Simulated EEPROM (SimEEPROM) access, and NVM3 access. For an introduction to the
token system, see document UG103.7: Non-Volatile Data Storage Fundamentals.
• Sample APIs for Peripheral access: APIs for controlling and accessing system peripherals.
• System timer control: APIs for controlling and accessing the system timers.
• Symbol timer control: APIs for accessing the symbol timer for the radio.
• HAL configuration: Miscellaneous API modules for board and chip configuration.
• HAL utilities: General-purpose APIs that may rely on hardware capabilities (for example, CRC calculation that may take advantage
of hardware acceleration).
• Bootloader interfaces: APIs for interfacing with Gecko bootloader and Ember legacy bootloaders. The use of bootloading is reviewed in the document UG103.6: Bootloader Fundamentals.
silabs.com | Building a more connected world. Rev. 1.4 | 3
UG103.4: HAL Fundamentals
Naming Conventions
3. Naming Conventions
HAL function names have the following prefix conventions:
• hal: The API Sample applications use. You can remove or change the implementations of these functions as needed.
• halCommon: The API used by the stack and that can also be called from an application. Custom HAL modifications must maintain
the functionality of these functions.
• halStack: Only the stack uses this API. These functions should not be directly called from any application, as this may violate timing constraints or cause re-entrancy problems. Custom HAL modifications must maintain the functionality of these functions.
• halInternal: The API that is internal to the HAL. These functions are not called directly from the stack and should not be called
directly from any application. They are called only from halStack or halCommon functions. You can modify these functions, but be
careful to maintain the proper functionality of any dependent halStack or halCommon functions.
Most applications will call halXXX and halCommonXXX functions and will not need to modify the HAL. If you need a special implementation or modification of the HAL, be sure to read the rest of this document as well as the data sheet for your Silicon Labs platform first.
silabs.com | Building a more connected world. Rev. 1.4 | 4
Loading...