RAIL is short for Radio Abstraction Interface Layer, and is the most direct interface available for EFR32 radios. You can think of it as a radio driver. While this sounds like a restriction, this actually makes software development for proprietary wireless much simpler:
RAIL application development is currently possible in the Flex SDK in Simplicity Studio. To progress further with this tutorial, please remember to open the RAIL API documentation.
If you have an existing protocol, and you must be compatible with it, you'd probably have to use RAIL (as all of our stacks use a standardized frame format).
If you want to use sub-GHz communication, you have a few options, including RAIL. For simple point to point communication, RAIL might be the simplest solution. However, as soon as you need security or addressing, it might be better choose a protocol stack, such as Connect.
RAIL also has the benefit that it adds the least amount of delays to all radio events: In fact, some event notification will happen in interrupt context.
RAIL only supports what the radio hardware supports. For example, auto ACK and address filter is available, as the hardware provides support for it. On the other hand, while security is important for wireless communication, it's not really a radio task, hence RAIL does not support it. The crypto engine is an independent peripheral that can be used to encrypt payloads before giving them to RAIL and the radio hardware.
EM1p or higher is required for the radio to be operational (i.e., Transmitting, receiving, or waiting for packets, RAIL timer running from HF clock). On devices without EM1p support, EM1 is required for the radio. See AN1244: EFR32 Migration Guide for Proprietary Applications for more details on EM1p.
EM2 or higher is required for RAIL scheduling or timers (Running from LF clock, which needs configuration, a topic in Tutorial 5).
EM3 or higher is required for RAIL to work without re-initialization.
We do not recommend writing code from scratch because it is much simpler to have something existing that sets up the include paths and linker settings correctly. The best way to start is the example Flex (RAIL) - Empty Example.
The empty application includes the following RAIL related components (under 'Platform/Radio'):
There are a few components that you might want to install
If you work on a starter kit, you don't need to change the configuration of most of these components (for custom hardware, there will be a new article coming soon), except the Initialization component. However, the initialization component also includes a good starting point, that we don't need to modify for simple applications.
The Radio Configurator is accessible by configuring the component Advanced Configurators/Radio Configurator. The usage of the radio configurator is out of scope for this tutorial series. For more details, see AN1253: EFR32 Radio Configurator Guide.
Projects always include the following parts:
rail_config.c), init code, the linker script, and other generated code used by components, like the command descriptors for the CLI interface
.slcpfile) and the Pin tool (
Note that all files related to the project should be visible in the project explorer, including header and library files.
All projects include
main.c, which is not recommended to modify. Instead, add the initialization code to
app_init.c, and implement the main loop in
app_process.c. This way, the System components can initialize components, and call the "process" function of the components that requires this. Additionally, enabling an RTOS will convert app_process's main loop into an RTOS task.