Profile Data
| Member | Action | Date |
|---|---|---|
Marc Dorval
|
Updated KBA: WF(M)200 Checking Linux GPIOs allocation on Wi-Fi Knowledge Base Show more |
32 days ago |
|
Marc Dorval
|
Updated KBA: WF(M)200 Checking Linux GPIOs allocation on Wi-Fi Knowledge Base Show more |
32 days ago |
|
Marc Dorval
|
Updated KBA: WF200/WFM200 Linux Driver with AllWinner SoC (SDIO) on Wi-Fi Knowledge Base Show more |
32 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 4 (studio5): Combining Transmit and Receive on Proprietary Wireless Knowledge Base
This tutorial builds on the following tutorials:
Please read them first if you haven't. You can find other tutorials on the table of contents site. On the previous tutorial, we had both transmit and receive working, but we couldn't see what we received. This tutorial will solve that problem. We're also adding calibrations, which is recommended for all projects. You can find a SimpleTRX example in Simplicity Studio, which has a similar purpose. However, the result of this tutorial will be somewhat different. Mainly, this tutorial is not very pedantic on checking errors returned by all functions, to make it easier to understand. However, we highly recommend checking all possible errors, therefore using the SimpleTRX example in Studio as a reference. Enabling CalibrationsFirst, let's load PA factory calibrations: Open the configuration for the component RAIL Utility, Power Amplifier, and turn on the Enable PA Calibration switch. All other calibrations are enabled by default in RAIL Utility, Initialization, but require some application code to perform them. First, we need to add the related event during initialization to enable it (in app_init.c):
Next, we need to perform calibrations when RAIL requests them (in app_process.c):
This is all that's needed from an application to perform all calibrations available on EFR32, to have the maximum available performance. Calibrations are detailed further in another tutorial. Preparing for printingIn the previous tutorials, we already enabled LEDs and buttons, but we'll need a more user friendly output: We need a serial console. To enable that, install the following components:
Finally, we need to enable Virtual COM UART on the Board Control component:
This pulls up a GPIO, which will enable the USB-UART bridge on the WSTK. Receive FIFOWe already configured Tx FIFO multiple ways. RAIL also implements an Rx FIFO. By default, it's 512B, allocated by the RAIL library. We will use that, but it is configurable. See By default, you cannot use the whole 512B, as RAIL adds a few bytes to each packet to store timestamp, RSSI, and similar information in the FIFO (sometimes we call this "appended info"). We're working on what we call packet mode. It's the simpler, and recommended way, but it's not possible to handle packets bigger than 512B with this method, in which case FIFO mode should be used. We return to that topic in a later tutorial. The Packet HandleThe FIFO is accessible with
Note that
If you don't care about upcoming or ongoing packets, you can use When to Read the FIFOLet's say we want to download the packet when it's fully received (although it's possible to access it during reception). We must let RAIL know this in the event We have two options:
While the first one is simpler, it is desirable in most cases to keep large memory copy operations outside of interrupt handlers, therefore the attached example demonstrates the second method. The Event HandlerIn the event handler, we want to instruct RAIL to hold all successfully received frames:
The API Download and PrintFirst, let's create a buffer we can use to download the packet:
In
Let's go through this, line by line: First, Since the receive buffer is a ring buffer, the packet in the buffer might not be in a single sequential buffer, copying from that using The API Finally, we release the packet, using Note that this method is safe, even if we receive a new packet while downloading one: That packet will be downloaded and printed when Download in the Event HandlerDownloading the packet in the event handler is essentially the same as what we did in the main loop above, except we don't need to worry about releasing:
Note that ConclusionWith this, you can use RAIL for basic transmit and receive, which concludes the getting started series. However, RAIL can do much more - you can continue with the basic tutorials from the table of contents site. API Introduced in this TutorialFunctions
Types and enums |
39 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 3 (studio5): Event Handling on Proprietary Wireless Knowledge Base
This tutorial builds on the following tutorials:
Please read them first if you haven't. You can find other tutorials on the Table of Contents site. In the previous tutorials, we set up RAIL to do various tasks through API commands. However, RAIL can inform the application on various events almost real time (basically, wiring interrupts through RAIL). So let's improve what we had in the previous tutorial. The Event Handler FunctionYou might have already seen this function in
This is the event handler function, which is called by the RAIL library, and routed through the RAIL Utility, Initialization component. The The event handler should be prepared for multiple events in a single call. There's no "clearFlag" mechanism, each event will be signaled once, and the application is responsible for handling it. Keep in mind that almost all events are generated from interrupts, so the event handler is usually running from interrupt context (i.e., interrupts are disabled). Therefore, the event handler should run fast; if you have to do something that takes more time, set a flag, and do it from the main loop. You should be also careful with RAIL interrupt safety. Calling state changing APIs ( Configuring EventsThe events enabled by default are configured on the RAIL Utility, Initialization component (under 'Platform/Radio', press 'Configure'):
However, using the RAIL API directly is actually simpler than using the event configuration capabilities of this component. The API for this is
RAIL also defines a few event groups (defined in rail_types.h, documented in events), the most useful are:
This can be used, for example, to disable or enable all events:
If you enable/disable events in group, it's a good practice to create similar group of events in your application. RAIL has no API to flush pending events, but disabling and enabling them will have that result:
However, you only need to do this in rare cases. Enabling events is not like unmasking interrupts: Enabling them will not trigger the event handler on past events. Tx Error HandlingIn the last tutorial, we sent out a frame, but we didn't check the results because it would have needed the event handler. Let's turn on led0 on success and led1 on any error (we'll be turning led1 on when transmitting and clearing led1 if no Tx error occurs). First, for the LEDs, enable the Simple LED component with led0 and led1. In app_process.c (to get access to the led instances, now declared in autogen/sl_simple_led_instances.h):
For the actual radio related changes, we'll need to enable the success and error events. We can do that during init since we don't really need to disable anything at runtime for such simple applications:
Next, let's check for errors returned by the StartTx call:
Finally, let's check the events for success and errors:
With this, you should see led0 toggling on every transmitted packet. Receiving PacketsLet's add receive capabilities to this application! Again, use led0 to report success and led1 for errors. First, we need to modify the init code. In app_init.c (to get access to the led instances):
We need RX success/error events enabled, and we need to start the radio in RX mode:
The API Finally, let's check the events for success and errors (in app_process.c):
Auto state transitionsBy default, after receiving or transmitting a packet, RAIL will switch to idle mode (i.e., turn off the radio). Since we want it to keep receiving future packets, we can use RAIL's auto state transition feature. This can be configured on the RAIL Utility, Initialization component, let's set all dropdowns to RX:
We're basically saying that after the packets are received/transmitted, we want to return to Rx. These configurations can be also changed in run-time, using the If you compile and flash the program after this modification, you should see that now both WSTK toggles led0 on every button press. Testing and ConclusionIf you install this example to two boards (make sure you attach the antennas if you use sub-GHz kits on sub-GHz config), you will see that on the press of btn0 on either device, led0 on both devices toggle. However, we can't see what we're receiving, since we never actually download the messages. We're going to fix this Next time API Introduced in this TutorialFunctionsTypes and enums |
39 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 3 (studio5): Event Handling on Proprietary Wireless Knowledge Base
This tutorial builds on the following tutorials:
Please read them first if you haven't. You can find other tutorials on the Table of Contents site. In the previous tutorials, we set up RAIL to do various tasks through API commands. However, RAIL can inform the application on various events almost real time (basically, wiring interrupts through RAIL). So let's improve what we had in the previous tutorial. The Event Handler FunctionYou might have already seen this function in
This is the event handler function, which is called by the RAIL library, and routed through the RAIL Utility, Initialization component. The The event handler should be prepared for multiple events in a single call. There's no "clearFlag" mechanism, each event will be signaled once, and the application is responsible for handling it. Keep in mind that almost all events are generated from interrupts, so the event handler is usually running from interrupt context (i.e., interrupts are disabled). Therefore, the event handler should run fast; if you have to do something that takes more time, set a flag, and do it from the main loop. You should be also careful with RAIL interrupt safety. Calling state changing APIs ( Configuring EventsThe events enabled by default are configured on the RAIL Utility, Initialization component (under 'Platform/Radio', press 'Configure'):
However, using the RAIL API directly is actually simpler than using the event configuration capabilities of this component. The API for this is
RAIL also defines a few event groups (defined in rail_types.h, documented in events), the most useful are:
This can be used, for example, to disable or enable all events:
If you enable/disable events in group, it's a good practice to create similar group of events in your application. RAIL has no API to flush pending events, but disabling and enabling them will have that result:
However, you only need to do this in rare cases. Enabling events is not like unmasking interrupts: Enabling them will not trigger the event handler on past events. Tx Error HandlingIn the last tutorial, we sent out a frame, but we didn't check the results because it would have needed the event handler. Let's turn on led0 on success and led1 on any error (we'll be turning led1 on when transmitting and clearing led1 if no Tx error occurs). First, for the LEDs, enable the Simple LED component with led0 and led1. In app_process.c (to get access to the led instances, now declared in autogen/sl_simple_led_instances.h):
For the actual radio related changes, we'll need to enable the success and error events. We can do that during init since we don't really need to disable anything at runtime for such simple applications:
Next, let's check for errors returned by the StartTx call:
Finally, let's check the events for success and errors:
With this, you should see led0 toggling on every transmitted packet. Receiving PacketsLet's add receive capabilities to this application! Again, use led0 to report success and led1 for errors. First, we need to modify the init code. In app_init.c (to get access to the led instances):
We need RX success/error events enabled, and we need to start the radio in RX mode:
The API Finally, let's check the events for success and errors (in app_process.c):
Auto state transitionsBy default, after receiving or transmitting a packet, RAIL will switch to idle mode (i.e., turn off the radio). Since we want it to keep receiving future packets, we can use RAIL's auto state transition feature. This can be configured on the RAIL Utility, Initialization component, let's set all dropdowns to RX:
We're basically saying that after the packets are received/transmitted, we want to return to Rx. These configurations can be also changed in run-time, using the If you compile and flash the program after this modification, you should see that now both WSTK toggles led0 on every button press. Testing and ConclusionIf you install this example to two boards (make sure you attach the antennas if you use sub-GHz kits on sub-GHz config), you will see that on the press of btn0 on either device, led0 on both devices toggle. However, we can't see what we're receiving, since we never actually download the messages. We're going to fix this Next time API Introduced in this TutorialFunctionsTypes and enums |
39 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 3 (studio5): Event Handling on Proprietary Wireless Knowledge Base
This tutorial builds on the following tutorials:
Please read them first if you haven't. You can find other tutorials on the Table of Contents site. In the previous tutorials, we set up RAIL to do various tasks through API commands. However, RAIL can inform the application on various events almost real time (basically, wiring interrupts through RAIL). So let's improve what we had in the previous tutorial. The Event Handler FunctionYou might have already seen this function in
This is the event handler function, which is called by the RAIL library, and routed through the RAIL Utility, Initialization component. The The event handler should be prepared for multiple events in a single call. There's no "clearFlag" mechanism, each event will be signaled once, and the application is responsible for handling it. Keep in mind that almost all events are generated from interrupts, so the event handler is usually running from interrupt context (i.e., interrupts are disabled). Therefore, the event handler should run fast; if you have to do something that takes more time, set a flag, and do it from the main loop. You should be also careful with RAIL interrupt safety. Calling state changing APIs ( Configuring EventsThe events enabled by default are configured on the RAIL Utility, Initialization component (under 'Platform/Radio', press 'Configure'):
However, using the RAIL API directly is actually simpler than using the event configuration capabilities of this component. The API for this is
RAIL also defines a few event groups (defined in rail_types.h, documented in events), the most useful are:
This can be used, for example, to disable or enable all events:
If you enable/disable events in group, it's a good practice to create similar group of events in your application. RAIL has no API to flush pending events, but disabling and enabling them will have that result:
However, you only need to do this in rare cases. Enabling events is not like unmasking interrupts: Enabling them will not trigger the event handler on past events. Tx Error HandlingIn the last tutorial, we sent out a frame, but we didn't check the results because it would have needed the event handler. Let's turn on led0 on success and led1 on any error (we'll be turning led1 on when transmitting and clearing led1 if no Tx error occurs). First, for the LEDs, enable the Simple LED component with led0 and led1. In app_process.c (to get access to the led instances, now declared in autogen/sl_simple_led_instances.h):
For the actual radio related changes, we'll need to enable the success and error events. We can do that during init since we don't really need to disable anything at runtime for such simple applications:
Next, let's check for errors returned by the StartTx call:
Finally, let's check the events for success and errors:
With this, you should see led0 toggling on every transmitted packet. Receiving PacketsLet's add receive capabilities to this application! Again, use led0 to report success and led1 for errors. First, we need to modify the init code. In app_init.c (to get access to the led instances):
We need RX success/error events enabled, and we need to start the radio in RX mode:
The API Finally, let's check the events for success and errors (in app_process.c):
Auto state transitionsBy default, after receiving or transmitting a packet, RAIL will switch to idle mode (i.e., turn off the radio). Since we want it to keep receiving future packets, we can use RAIL's auto state transition feature. This can be configured on the RAIL Utility, Initialization component, let's set all dropdowns to RX:
We're basically saying that after the packets are received/transmitted, we want to return to Rx. These configurations can be also changed in run-time, using the If you compile and flash the program after this modification, you should see that now both WSTK toggles led0 on every button press. Testing and ConclusionIf you install this example to two boards (make sure you attach the antennas if you use sub-GHz kits on sub-GHz config), you will see that on the press of btn0 on either device, led0 on both devices toggle. However, we can't see what we're receiving, since we never actually download the messages. We're going to fix this Next time API Introduced in this TutorialFunctionsTypes and enums |
39 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 3 (studio5): Event Handling on Proprietary Wireless Knowledge Base
This tutorial builds on the following tutorials:
Please read them first if you haven't. You can find other tutorials on the Table of Contents site. In the previous tutorials, we set up RAIL to do various tasks through API commands. However, RAIL can inform the application on various events almost real time (basically, wiring interrupts through RAIL). So let's improve what we had in the previous tutorial. The Event Handler FunctionYou might have already seen this function in
This is the event handler function, which is called by the RAIL library, and routed through the RAIL Utility, Initialization component. The The event handler should be prepared for multiple events in a single call. There's no "clearFlag" mechanism, each event will be signaled once, and the application is responsible for handling it. Keep in mind that almost all events are generated from interrupts, so the event handler is usually running from interrupt context (i.e., interrupts are disabled). Therefore, the event handler should run fast; if you have to do something that takes more time, set a flag, and do it from the main loop. You should be also careful with RAIL interrupt safety. Calling state changing APIs ( Configuring EventsThe events enabled by default are configured on the RAIL Utility, Initialization component (under 'Platform/Radio', press 'Configure'):
However, using the RAIL API directly is actually simpler than using the event configuration capabilities of this component. The API for this is
RAIL also defines a few event groups (defined in rail_types.h, documented in events), the most useful are:
This can be used, for example, to disable or enable all events:
If you enable/disable events in group, it's a good practice to create similar group of events in your application. RAIL has no API to flush pending events, but disabling and enabling them will have that result:
However, you only need to do this in rare cases. Enabling events is not like unmasking interrupts: Enabling them will not trigger the event handler on past events. Tx Error HandlingIn the last tutorial, we sent out a frame, but we didn't check the results because it would have needed the event handler. Let's turn on led0 on success and led1 on any error (we'll be turning led1 on when transmitting and clearing led1 if no Tx error occurs). First, for the LEDs, enable the Simple LED component with led0 and led1. In app_process.c (to get access to the led instances, now declared in autogen/sl_simple_led_instances.h):
For the actual radio related changes, we'll need to enable the success and error events. We can do that during init since we don't really need to disable anything at runtime for such simple applications:
Next, let's check for errors returned by the StartTx call:
Finally, let's check the events for success and errors:
With this, you should see led0 toggling on every transmitted packet. Receiving PacketsLet's add receive capabilities to this application! Again, use led0 to report success and led1 for errors. First, we need to modify the init code. We need RX success/error events enabled, and we need to start the radio in RX mode:
The API Finally, let's check the events for success and errors:
Auto state transitionsBy default, after receiving or transmitting a packet, RAIL will switch to idle mode (i.e., turn off the radio). Since we want it to keep receiving future packets, we can use RAIL's auto state transition feature. This can be configured on the RAIL Utility, Initialization component, let's set all dropdowns to RX:
We're basically saying that after the packets are received/transmitted, we want to return to Rx. These configurations can be also changed in run-time, using the If you compile and flash the program after this modification, you should see that now both WSTK toggles led0 on every button press. Testing and ConclusionIf you install this example to two boards (make sure you attach the antennas if you use sub-GHz kits on sub-GHz config), you will see that on the press of btn0 on either device, led0 on both devices toggle. However, we can't see what we're receiving, since we never actually download the messages. We're going to fix this Next time API Introduced in this TutorialFunctionsTypes and enums |
39 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 3 (studio5): Event Handling on Proprietary Wireless Knowledge Base
This tutorial builds on the following tutorials:
Please read them first if you haven't. You can find other tutorials on the Table of Contents site. In the previous tutorials, we set up RAIL to do various tasks through API commands. However, RAIL can inform the application on various events almost real time (basically, wiring interrupts through RAIL). So let's improve what we had in the previous tutorial. The Event Handler FunctionYou might have already seen this function in
This is the event handler function, which is called by the RAIL library, and routed through the RAIL Utility, Initialization component. The The event handler should be prepared for multiple events in a single call. There's no "clearFlag" mechanism, each event will be signaled once, and the application is responsible for handling it. Keep in mind that almost all events are generated from interrupts, so the event handler is usually running from interrupt context (i.e., interrupts are disabled). Therefore, the event handler should run fast; if you have to do something that takes more time, set a flag, and do it from the main loop. You should be also careful with RAIL interrupt safety. Calling state changing APIs ( Configuring EventsThe events enabled by default are configured on the RAIL Utility, Initialization component (under 'Platform/Radio', press 'Configure'):
However, using the RAIL API directly is actually simpler than using the event configuration capabilities of this component. The API for this is
RAIL also defines a few event groups (defined in rail_types.h, documented in events), the most useful are:
This can be used, for example, to disable or enable all events:
If you enable/disable events in group, it's a good practice to create similar group of events in your application. RAIL has no API to flush pending events, but disabling and enabling them will have that result:
However, you only need to do this in rare cases. Enabling events is not like unmasking interrupts: Enabling them will not trigger the event handler on past events. Tx Error HandlingIn the last tutorial, we sent out a frame, but we didn't check the results because it would have needed the event handler. Let's turn on led0 on success and led1 on any error. First, for the LEDs, enable the Simple LED component with led0 and led1. In app_process.c (to get access to the led instances, now declared in autogen/sl_simple_led_instances.h):
For the actual radio related changes, we'll need to enable the success and error events. We can do that during init since we don't really need to disable anything at runtime for such simple applications:
Next, let's check for errors returned by the StartTx call:
Finally, let's check the events for success and errors:
With this, you should see led0 toggling on every transmitted packet. Receiving PacketsLet's add receive capabilities to this application! Again, use led0 to report success and led1 for errors. First, we need to modify the init code. We need RX success/error events enabled, and we need to start the radio in RX mode:
The API Finally, let's check the events for success and errors:
Auto state transitionsBy default, after receiving or transmitting a packet, RAIL will switch to idle mode (i.e., turn off the radio). Since we want it to keep receiving future packets, we can use RAIL's auto state transition feature. This can be configured on the RAIL Utility, Initialization component, let's set all dropdowns to RX:
We're basically saying that after the packets are received/transmitted, we want to return to Rx. These configurations can be also changed in run-time, using the If you compile and flash the program after this modification, you should see that now both WSTK toggles led0 on every button press. Testing and ConclusionIf you install this example to two boards (make sure you attach the antennas if you use sub-GHz kits on sub-GHz config), you will see that on the press of btn0 on either device, led0 on both devices toggle. However, we can't see what we're receiving, since we never actually download the messages. We're going to fix this Next time API Introduced in this TutorialFunctionsTypes and enums |
39 days ago |
|
Marc Dorval
|
Updated
RAIL Tutorial 1 (studio5): Introduction, RAIL components and the Empty Example on Proprietary Wireless Knowledge Base
What is RAIL?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:
See this KBA for more details. 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. When to Use RAIL?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. What is covered by RAIL?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. Supported Energy ModesEM1p 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. Writing Code from ScratchWe 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. RAIL ComponentsThe 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 ConfiguratorThe 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. The project structureProjects always include the following parts:
Note that all files related to the project should be visible in the project explorer, including header and library files. All projects include ConclusionThis project is ready to send out frames. We're going to do that in the next part. You can also find other tutorials from the Table of Content site. |
39 days ago |
Level 5
Level 4
Level 3
Level 1