High-performance FPGAs play a key role in numerous applications including data centers, broadcast imaging, and industrial control. Unlike earlier generations, using high-performance FPGAs presents new design challenges. Rather than using simple integer clock multiplication of reference inputs or clock generation, high-end FPGAs require multiple non-integer-related frequencies to generate any output frequency without sacrificing jitter performance. To achieve this, a new clock reference architecture is required.

 

Traditional Clock Reference Architecture

Implementing a complex clock tree while still meeting severe space restrictions and a compressed time-to-market requires a new approach to clock generator design. The traditional architecture is based around a simple loop that generates a voltage-controlled oscillator output at a multiple of the desired frequency. In this architecture, the output clock frequency is a function of the input clock frequency and the PLL divider values. This model is suitable for simple integer clock multiplication of reference inputs or clock generation from a crystal input.

 

Solving the High-Performance FGPA Challenge

On the other hand, high-end FPGAs require multiple non-integer-related frequencies. The designer must use one or more custom crystals and multiple clock generator ICs to generate the required set of frequencies, increasing the cost, complexity and power consumption of the overall solution. Silicon Labs’ patented MultiSynth™ fractional divider architecture solves this problem. The MultiSynth architecture switches seamlessly to produce the exact output clock frequency with zero ppm error. This technique makes it possible to generate any output clock frequency without sacrificing jitter performance.

 A comparison of (a) the traditional PLL and (b) the MultiSynth clock generation architectures 

 

Integrated LDOs Reduce Noise and Improve Performance

In addition to the MultiSynth architecture, clock generators include multiple features that contribute to low jitter and save system cost. For example, noise on the power supply is a significant problem in high-performance clock devices. It affects the performance in two ways:

1. It adds noise to the clock voltage references, which appears in the output as a timing error
2. The power-supply noise is modulated by the internal oscillator in the PLL and contributes to phase noise

Power supplies based on switching topologies are the preferred choice in high-current, low-voltage designs because they are highly efficient. Unfortunately, they also generate significant noise, so FPGA system designers must add low-noise low-dropout (LDO) linear regulators, ferrite beads, and numerous filter capacitors to remove power-supply noise before it reaches the clock generator. This adds significant cost and increases the board size.  However, Silicon Labs devices include multiple LDOs on the chip to largely eliminate the need for these external components.

 

Silicon Labs Solutions

In conjunction with the timing solutions products, Silicon Labs offers several software tools that help customers develop quick-turn, customized solutions. ClockBuilder Pro (CBPro) is a software tool that simplifies the task of getting from a clock-tree specification to an orderable part. The tool uses a step-by-step GUI format that includes more than 175 clock design rules to reduce design and debug time. The CBPro software package is freely available for download, and with the tool, designers can now develop an optimum solution and quickly evaluate sample parts. Other software tools include a Phase Noise to Jitter Calculator that helps translate FPGA phase noise specifications into jitter requirements.

Silicon Labs timing solutions are widely used in several FPGA reference designs. These evaluation and development kits enables quick customer adoption and accelerate time-to-market. Visit our clock and oscillator reference designs to get started.

To learn more about how Silicon Labs’ portfolio of clock generators can help meet your FPGA design requirements, read the full whitepaper.

Last month, we had the chance to speak with David Simpson, Chief Product Officer, and IoT Product Manager Logan Stover, at Enseo. If you’ve ever stayed in a hotel room and watched an on-demand movie or streaming service on the TV, you’ve probably used the Texas-based company’s technology.

Enseo reaches more than 84 million people annually through their platform. A few years ago, the company expanded its hospitality offering into safety and created an IoT employee safety device using Silicon Labs’ wireless technology. The new product contributed to an industry-wide conversation in hospitality around steps employers can take to help prevent housekeeping staff assault incidences.

Today, four years after launching the system, the MadeSafe® product is used by many housekeeping employees across many of the largest hotel brands, including Marriott. David and Logan share some details below about the company and how the safety product came about.

Can you tell me a little bit about Enseo?

Today we have four core products in one platform, including in-room entertainment, high-speed Internet, IoT energy management and room control, and the MadeSafe employee safety system. The demand for this platform grew quickly, and we have ventured into other adjacent markets, including education, hospitals and government. Enseo got its start almost 20 years ago after creating one of the first TV channel scroll guides for cable TV. Soon after that, Enseo entered the hospitality market.

How did MadeSafe come about?

One reason why MadeSafe is so useful is because hotel employees are often alone during the work day while servicing hundreds of rooms. Several years ago, the press was focused on a sexual assault case involving a New York City housekeeper and a prominent international politician. The case garnered a great deal of media attention about sexual assault in the hospitality sector. Shortly after the case, several New York City hotels approached us about designing an employee safety product. Enseo deployed the first generation of MadeSafe at the J.W. Marriott Essex House in 2015.

According to the Center for American Progress, 25 percent of all sexual assault charges filed are in industries with a large number of service sector workers who are often women.

By late 2017, the #metoo movement brought these issues to the attention of everyone. Hoteliers and cities began creating ordinances, while unions brought the issue to a higher level of attention, inspiring several communities and the American Hotel and Lodging Association to be more aggressive in industry requirements around safety. Today most hotels are committed to installing this technology by the end of 2020. The hospitality industry is leading other industries in proactively addressing these safety concerns.

How does the product work?

Each employee wears a small wireless device that looks similar to a car key fob. If the employee feels threatened, they simply press the button, and a geolocation signal is immediately sent to designated safety personnel, showing exactly where the employee is located on a 3D property map. Employees can only be tracked when the button is pressed, which was an important privacy element we built into the product.

Why did you use Silicon Labs to help design the product?

Silicon Labs’ multiprotocol functionality and performance, along with cost, were the key differentiators for us while considering the design of our latest generation of MadeSafe product. Also, of key importance to us was the multiple protocol capability to keep options open for later generations of the MadeSafe system and other IoT future products. The Silicon Labs multiprotocol Wireless Gecko platform was easy for Enseo developers to use, allowing us to incorporate both Zigbee and Bluetooth protocols into the product. The platform’s capabilities to enable over the air updates and the Simplicity Studio development kit were also critical to our development team, as it helped simplify and speed the design process. Our design team, who was already familiar with Silicon Labs systems, also liked the scalability and flexibility of the software ecosystem.

Where do you see IoT headed in the next 5-8 years?

IoT security needs more attention from both silicon and software providers. Hardware, in particular, has a key role to play in security, but up until now, hardware hasn’t had a pivotal role. We see this changing in the future. The future of IoT will bring an enormous number of new devices into the market, many of which we have not even begun to imagine. While cost pressures will be substantial moving forward, we will need flexible and innovative software to meet pricing and development cost demands.

Introduction

Hello and welcome to the latest article for the blog series, Timing 201. This is a sequel to the article Timing 201 #1: The Case of the Phase Noise That Wasn’t – Part 1. In this post, I follow-up on Part 1 and suggest that both a limiting amplifier and balun are useful accessories to minimize AM and make good phase noise measurements. I include some example data and close with a few rules of thumb.

A Quick Review from Part 1

You will recall the basic idea we last explored was that AM (Amplitude Modulation) noise can impact phase noise measurements. (AM noise is the apparent “phase noise that isn’t”.) A spectrum analyzer cannot distinguish between AM and PM (Phase Modulation) or phase noise. Purpose-built phase noise measurement instrumentation can suppress but not eliminate AM to PM conversion. The use of a limiting amplifier can further reduce the impact of AM noise on phase noise measurement. This can be a valuable troubleshooting tool when investigating system-level clock noise and spurs.

Example Limiting Amplifier AM Rejection

First, a few words about the particular limiting amplifier used for data collection in this article. The ideal limiting amplifier or LA would be high gain, low noise, wideband, and modestly priced. That combination is hard to find.

The sample LA used here is the Hittite (now Analog Devices) HMC750 which has a 3 dB bandwidth of 11 GHz. An evaluation board is available from distributors though it’s relatively expensive. There are other LAs available from other vendors, and if you buy units in quantity and/or roll your own PCB, you can certainly lower your costs. 

Two suggestions if you do use the Hittite evaluation board:

1. Replace the 0 Ω resistors used in the I/O paths with 1 mF 0402 capacitors. This will allow routine AC-coupled operation without having to attach external DC-blocking caps.
2. Scrape the EVB solder mask in the vicinity of the SMA connector mounts and fillet solder them to the PCB. This will make the connectors more mechanically secure. I know from personal experience that these can “torque off” if you are not careful. <Thanks to Scott McMullen here for repairing and updating the last board.>

As a reminder, the time domain operation of the LA is illustrated as follows. Below left is a scope capture for a 100 MHz single-ended sinusoidal clock. The AM depth was 5% and the scope is set to infinite persistence. Below right is the same single-ended clock through the example limiting amplifier.

While the time domain operation is suggestive, AM rejection is better measured in the frequency domain. In the following measurements, a Keysight E5052B was used both as the measurement instrument and as a stand-in clock receiver. I employed a Keysight 33600A Waveform Generator, operating single-endedly, to apply AM at several frequencies and measured both the AM and phase noise spur amplitude. The carrier was 100 MHz and the AM depth was set to 1%. Getting a consistent AM spur above the noise floor was what I was looking for.

I then inserted the cited LA and repeated the same measurements. 

Note the new noise columns that had to be added. The LA effectively eliminated the AM spur completely, reducing it to the noise floor. There is still a corresponding phase noise spur, reduced also. (Subsequent testing indicated this was incidental phase modulation from the source.)

Here is a sample plot for the 100 kHz case with no intervening limiting amplifier. The phase noise window is displayed at the top and the AM noise window is displayed at the bottom. Marker 1 in each window is set at 100 kHz.

And here is a corresponding sample plot for the 100 kHz case when using the limiting amplifier. As I mentioned previously, the AM spur is eliminated which I was looking for. The corresponding phase noise spur dropped another 12 dB. For some reason, at least for this sample, the AM noise floor above 10 kHz is not flat as would be ideal.

In general, we should use a limiting amplifier if AM noise or spurs are significant with respect to phase noise. In a measurement system that can measure both, we typically want AM noise or spurs to be at least 10 dB below phase noise or spurs at the same offset frequencies. (We weren’t quite getting that in the first table above.)

Ideally, the same would be true for the clock receiver accounting for its AM rejection. For example, if both the input clock’s AM noise floor and phase noise floor were the same at a particular offset frequency, then we would want the clock receiver to reject or attenuate AM noise further by 10 dB. This performance is not always specified and may need to be measured. It is also often a function of the input clock slew rate or rise/fall time. 

Differential Signaling

A limiting amplifier is useful for removing AM from both single-ended and differential clocks. However, differential clocks are themselves an important approach to combating AM noise.

One of the most important reasons for differential signaling on balanced lines is common mode (CM) noise rejection. Since most AM noise on differential signals is CM (e.g. due to power supplies) then differential receivers will tend to reject AM. This can be illustrated pictorially in the figures below.

First, consider amplitude noise impressed upon a single-ended clock.

Now, consider the same amplitude noise impressed upon a differential clock.

There are several aspects to the diagram worth noting:

1. Differential signaling needs equal CLKP and CLKN path lengths to minimize skew and DM to CM conversion. The PC board should be laid out to enforce this.
2. A split termination as shown will further minimize CM noise due to any unintended skew. (Please see
   Timing 101: The Case of the Split Termination.)
3. The differential clock receiver needs good Common Mode Rejection or CMR. Typical differential receivers should have CMR ³ 60 dB. However, this should be verified for the offset frequencies of interest.

All of these will help to prevent CM AM noise from impacting the measurement.

Unfortunately, most spectrum and phase noise analysis instruments have single-ended inputs and don’t directly support differential measurements. If we replace the receiver in the diagram with an instrument, what is the best approach?

A ready measurement would be to route one differential clock polarity, e.g. CLKP, to the instrument and terminate the unmeasured polarity output, e.g. CLKN, in to 50 Ω. Generally you will want to AC-couple these so as to present roughly the same impedance. The necessity for balanced termination is discussed in Timing 101 #10: The Case of the Half-terminated Differential Output Clock. 

This is a valid measurement but is overly conservative as it neglects the advantage that would actually be experienced in a differential clock system. What we need is a device that will convert the differential signal to a single-ended signal. Such a device is known as a balun (taken from balanced to unbalanced).

This could be in the form of an amplifier (sometimes called an active balun) or more typically a passive component. As an example of the latter, a classic transformer balun or voltage balun has a center-tapped winding on one side for converting 100 Ω differential to single-ended 50 Ω.

The example balun used in these tests is the Tektronix (formerly Picosecond Pulse Labs) PSPL5310R. This is a phase matched balun which can operate from 4 MHz to 6.5 GHz. Unfortunately, for some reason, these are no longer available from Tektronix.

Other vendors which sell baluns include MACOM, Marki Microwave, and Mini-Circuits. (This is not meant to be an inclusive and exhaustive list. These are just companies I am familiar with.)

Look for a balun wideband enough to pass the necessary waveform with sufficient risetime and with good phase and amplitude balance. The old PSPL balun had anywhere from ± 0.5 to ± 2 degrees differential phase balance and ± 0.1 to +0.3/0.2 dB differential amplitude balance depending on the frequency range. 

Example DUT with AM Noise

I have selected for a practical example one of my favorite “desert island” parts, the venerable Si570 which is an older generation programmable oscillator. It was the first 5 mm x 7 mm I2C programmable oscillator that could cover 10 MHz to 1.4 GHz. Radio amateurs may recognize this device as used in some “Softrock” SDR (Software Defined Radio) applications.

Not only can it support such a wide frequency range but it can also be ordered with “real” LVPECL drivers. By this I mean it can drive DC-coupled LVPECL loads defined as 50 Ω terminated in to VDD – 2V.  (By contrast, clock devices typically provide LVPECL compatible modes where they can supply the right swing when AC-coupled.)  There is some CM (Common Mode) AM noise using this mode. However, this is mitigated when used differentially as intended. 

Below we will tabulate several measurement scenarios with and without a balun and LA. The DUT is an evaluation board with P/N 570AAA000121DG installed operating AC-coupled.  This is a differential programmable XO with a 100 MHz starting frequency, output format 3.3V LVPECL. 

Here are the phase jitter results for various configurations.

The biggest bang for the buck so to speak was using a balun. That got us to the 300fs range or less which is what we expect this device to yield. (The closest Si570 datasheet spec is 360 fs typical for Fout from 125 to 500 MHz.)

Here are a few plots to go with this table.

First, the single-ended configuration with the highest phase jitter, over 600 fs. Note the several spurs above 1 MHz in both the AM and phase noise measurement windows. 

Next is the balun only configuration which eliminates some spurs and drops the phase jitter roughly in half, i.e. below 300 fs.

Finally, here is the phase noise plot combining the DUT driving the LA differentially which in turn drives the balun connected to the E5052B. This plot eliminates all the spurs above 1 MHz and still keeps the phase noise floor mostly below -150 dBc/Hz beyond this offset frequency.

Virtual Limiting Amplifier

Ignoring spurs, it is possible in principle to estimate the DUT’s post-LA phase noise performance by mathematically applying a “virtual limiting amplifier”, if you know what the LA AM noise floor will be and what the AM to PM conversion is for your instrument. However, that is a topic for another time.

In practice, as one peels the onion to achieve lower and lower phase noise measurements, spurs play an increasingly larger role. This can be problematic for estimation purposes since even if the location of spurs can be predicted, often their amplitudes cannot.

A Few Rules of Thumb

Based on this and the previous Timing 201 post, here are a few suggested rules of thumb when making phase noise measurements on sources that may have AM noise:

Having a good limiting amplifier and a good balun on your bench can help you make more accurate phase noise and jitter measurements, and help distinguish the type of noise contributors you are dealing with. If you are working with differential clocks, you really should use a balun even if AM noise is not that significant.

Conclusion

I hope you have enjoyed this Timing 201 article. If you have a favorite balun or limiting amplifier you would like to share with others, please let me know.

As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to kevin.smith@silabs.com with the words “Timing 201” in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.

Cheers,

Kevin

Introduction

The Silicon Labs Examples in Simplicity Studio are very easy to access: You connect your Starter Kit and Simplicity Studio will display the list of examples as shown below:

 

We hope that you can find the most appropriate example to test your starter kit and hopefully base your design from one of the examples featured in Simplicity Studio.

But, in case you can’t find the example you were looking for, we have a wide variety of unpublished examples in a public repository. Like when you go to a store and ask one of the store's employees to see if the item you want is in the "back room" because you couldn’t find it on the shelves; The Silicon Labs back room for those examples you couldn’t find as part of Simplicity Studio is our repository in GitHub:

https://github.com/SiliconLabs

There you will find examples for pretty much all the Silicon Labs devices.

In this blog, I will show you how to access the EFM32/EFR32 Peripheral Examples.

 

 

EFM32/EFR32 Peripheral Examples

This repository contains low-level examples for each peripheral on the EFM32 and EFR32 devices:

https://github.com/SiliconLabs/peripheral_examples

The examples are organized by Series and then by Peripheral name as illustrated in Figure 2:

 

 

Device Series

If you want to find out what Series is your device, you can look at the package marking and the number highlighted in the table below is the series number:

EFM32/EFR32 Devices Series
Series 0	Series 1	Series 2
EFM32ZG	EFM32PG1	EFR32BG21
EFM32HG	EFR32MG1	EFR32MG21
EFM32TG	EFR32BG1
EFM32G	EFR32FG1
EFM32LG	EFM32PG12
EFM32GG	EFR32MG12
EFM32WG	EFR32BG12
	EFR32FG12
	EFR32MG13
	EFR32BG13
	EFR32FG13
	EFR32MG14
	EFR32BG14
	EFR32FG14
	EFM32GG11
	EFM32TG11

Table 1 Devices by Series

 

Peripheral Name

The table below lists all the device peripherals along with their description:

EFM32/EFR32 Peripherals
Name	Description
ACMP	Analog comparator (ACMP) Peripheral.
ADC	Analog to Digital Converter (ADC) Peripheral.
AES	Advanced Encryption Standard Accelerator (AES) Peripheral.
ASSERT	Error checking module.
BURTC	Backup Real Time Counter (BURTC) Peripheral.
BUS	BUS register and RAM bit/field read/write.
CHIP	Chip errata workarounds initialization.
CMU	Clock management unit (CMU) Peripheral.
COMMON	General purpose utilities and cross-compiler support.
CORE	Core interrupt handling.
DAC	Digital to Analog Converter (DAC) Peripheral.
DBG	Debug (DBG) Peripheral.
DMA	Direct Memory Access (DMA) Peripheral.
EBI	EBI External Bus Interface (EBI) Peripheral.
EMU	Energy Management Unit (EMU) Peripheral.
GPIO	General Purpose Input/Output (GPIO).
I2C	Inter-integrated Circuit (I2C) Peripheral.
INT	Safe nesting of interrupt disable/enable.
LCD	Liquid Crystal Display (LCD) Peripheral.
LESENSE	Low Energy Sensor (LESENSE) Peripheral.
LETIMER	Low Energy Timer (LETIMER) Peripheral.
LEUART	Low Energy Universal Asynchronous Receiver/Transmitter (LEUART) Peripheral.
MPU	Memory Protection Unit (MPU) Peripheral.
MSC	Memory System Controller.
OPAMP	Operational Amplifier (OPAMP) peripheral.
PCNT	Pulse Counter (PCNT) Peripheral.
PRS	Peripheral Reflex System (PRS) Peripheral.
RAMFUNC	RAM code support.
RMU	Reset Management Unit (RMU) Peripheral.
RTC	Real Time Counter (RTC) Peripheral.
SYSTEM	System.
TIMER	Timer/Counter (TIMER) Peripheral.
USART	Universal Synchronous/Asynchronous Receiver/Transmitter Peripheral.
USBD	USB Device Peripheral.
VCMP	Voltage Comparator (VCMP) Peripheral.
VERSION	Version.
WDOG	Watchdog (WDOG) Peripheral.

Table 2 Device Peripherals

 

 

Accessing the Peripheral Examples

To access the peripheral examples take the following steps:

Clone or Download the repository to the following path in your Simplicity Studio installation:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v#.#\app\

where #.# is the Gecko SDK suite version number

 

Import the example you want from Simplicity Studio by making one of the following series of clicks:

File -> Import, or

Project -> Import -> MCU Project

 

To access the examples from IAR, simply navigate to the desired .eww file and double click on it.

 

 

 

Further Reading

• EFM32/EFR32 Peripheral API Reference: 

https://siliconlabs.github.io/Gecko_SDK_Doc/index.html

• Simplicity Studio Manual:

https://www.silabs.com/documents/public/application-notes/AN0822-simplicity-studio-user-guide.pdf

Last week, the Bluetooth SIG announced to its members an update about security vulnerability related to the encryption key negotiation protocols. According to the SIG, researchers of SUTD, CISPA and Oxford University identified a vulnerability with the encryption key negotiation protocol of Bluetooth BR/EDR. The attack makes it possible for a third party to make the victims to agree on an encryption key with only 1 byte (8 bits) of entropy, which then enables the attacker to brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages in real-time. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. (More information about the details of the attack for example here www.knobattack.com)

Our Wireless Gecko Bluetooth products (Blue Gecko) and BLE112, BLE113, BLE113, BLE121LR and BLED112 module products are not affected by this issue because they are based on Bluetooth LE core specification which does not have this vulnerability.

Our Bluetooth BR/EDR (BT Classic) products, which include the WT12, WT11u, WT41u, WT32, WT32i, BT111 and BT121 modules, are vulnerable to this issue. We plan to release a patches which protect against this vulnerability during October 2019

Recently, Tom R. Halfhill, a senior analyst at The Linley Group and a senior editor of Microprocessor Report, contributed a review of our new Wireless Gecko Series 2 SoCs in the June issue of Microprocessor Report. He analyzes key EFR32 Series 2 upgrades and how the next-generation portfolio compares with the EFR32 Series 1 family in areas such as wireless performance, security features, on-chip CPU and package size.

In this report, Halfhill highlights Series 2 security features such as secure boot with Root of Trust and Secure Loader (RTSL) in addition to hardware crypto accelerations with side-channel countermeasures that considerably strengthen resistance to adversary attacks. The report also compares key specifications of EFR32MG21 and EFR32BG21 SoCs, the first products in the Series 2 portfolio. EFR32MG21 supports multiprotocol, Zigbee®, Thread and Bluetooth® mesh networking, and EFR32BG21 is dedicated to Bluetooth Low Energy and Bluetooth mesh connectivity.

Our Wireless Gecko Series 2 portfolio leads a growing crowd of wireless MCUs and SoCs for connected devices. Halfhill compares EFR32MG21 features and performance with several competing products from other large wireless MCU/SoC vendors:

•            NXP’s Kinetis K32W0x

•            ST Microelectronics’ STM32WB

•            Texas Instrument’s SimpleLink CC1352R

Halfhill acknowledges that our new Series 2 portfolio includes the lowest power wireless SoCs on the market while offering the tiniest footprint, boasting a 4 mm x 4 mm surface-mount QFN package with only 32 pins. The SoCs also offer the highest ambient temperature range, making them suitable for applications with extreme heat exposure such as connected LED lighting and various Industrial IoT applications. The latest Series 2 SoCs are ideal for a wide range of line-powered IoT products including gateways, hubs, lights, voice assistants and smart electric meters.

Series 1 customers can easily upgrade to the Series 2 platform. With IoT security threats increasing, Wireless Gecko Series 2 leads the pack in providing improved security features but comes at virtually no additional cost when upgrading to Series 2. The enhanced radios offer a +20 dBm option for longer range, allowing customers to choose the right power level and wireless range for each design. The Series 2 radio also offers better selectivity, which is helpful as more and more wireless devices use the crowded 2.4 GHz band.

Read the full Microprocessor Report: https://www.silabs.com/documents/public/white-papers/the-linley-group-microprocessor-report-silicon-labs-upgrades-wireless-mcus.pdf

Bluetooth Special Interest Group (SIG) has sent out Deprecated and Withdrawal notices for Bluetooth core specification version v4.1 and all earlier versions down to v2.1. In practice it means that the products, using Silicon Labs modules, which use v4.1 or earlier version, need to be Qualified and Declared at the latest by the withdrawal date of the specific version. Yet, despite the deprecated status of the Core specification versions v2.1 to v4.1, Silicon Lab’s modules are already fully Bluetooth SIG tested, listed and qualified as ‘End Products’ or ‘Controller’ subsystems, which means that the modules are valid as such for Bluetooth products and Silicon Labs customers do not need to perform additional testing when using the modules to Bluetooth SIG qualify their end product designs. The withdrawal date also does not impact Silicon Labs capability to manufacture and supply the modules for customers also after the withdrawal.

Table 1. shows the withdrawal dates for the core specifications and corresponding Silicon Labs module products.

Bluetooth Core specfication version	Withdrawal schedule	Impacted Silicon Labs parts
Bluetooth v2.1 and v3.0	Withdrawal date July 1st 2020	WT11, WT11u, WT12, WT32, WT32i, WT41, WT41u and all variations of their Orderable Part Numbers
	Before withdrawal date, customers can still list and qualify using Silicon Labs modules with no additional testing.
	After July 1st 2020, the specification will be completely withdrawn and no new Bluetooth end product listings will be possible.
Bluetooth 4.0	Withdrawal date February 1st 2022	BLE112, BLE113, BLE121LR, BLED112, BT111 and all variations of their Orderable Part Numbers
	Before withdrawal date, customers can still list and qualify using Silicon Labs modules with no additional testing.
	After February 1st 2022, the specification will be completely withdrawn and no new Bluetooth end product listings will be possible.
Bluetooth 4.1	Withdrawal date February 1st 2023	BT121 and and all variations of its Orderable Part Numbers
	Before withdrawal date, customers can still list and certify using the Silicon Labs modules with no additional testing.
	After february 1st 2023, the specification will be completely withdrawn and no new Bluetooth end product listings will be possible
Bluetooth v4.2 to v5.1	are still Active, no deprecation or withdrawal date has been released. Silicon Labs BGMxx products meets these standards and are recommended for new designs.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 Instructor Application & Electron App and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Kernel 201 Instructor Application

The instructor application is designed to be run by the instructor of a Kernel 201 class, or in the case of someone following along this blog post, by a user. The application communicates via Proprietary Wireless with all of the Thunderboard Sense 2s running the Kernel 201 Application in a one-to-many fashion. When the instructor application sends out a command, it acts as a broadcast to all devices listening. Since the Thunderboard Sense 2s are running Dynamic Multiprotocol, it is possible the radio may be operating in Bluetooth mode when the instructor application broadcasts a message. To mitigate this, the instructor application will actually transmit out the same message multiple times in an attempt to ensure all boards receive the message. The instructor application also can receive data from all Kernel 201 Applications. This is why the Kernel 201 Application only transmits data once every 10 seconds, rather than whenever it receives commands.

Note: It is worth noting that even with the multiple broadcasts, it is still possible for a Kernel 201 Application to miss a Proprietary Wireless message. In a real-world application where missing messages is not acceptable, a basic transmit-ack scheme would help or the use of a more complex wireless stack such as SiLab’s Connect Networking Stack. For this application, in order to keep the wireless portion simpler, it is acceptable for messages to be missed.

The entire instructor application acts as a translator between the Electron App and the Proprietary Wireless stack. When a user sends a command in the Electron App, a LAB_MSG_s packet is built up in the Electron App and sent to the instructor application via serial. The instructor application then takes that data and transmits it out using the RAIL API. When data is received via Proprietary Wireless, the instructor application receives the RAIL packet and then sends the data it received via serial to the Electron App. This allows the instructor application to operate without knowing too many details about the command packets.

Proprietary Wireless Task

 

 

The Proprietary Wireless task design in the instructor application is slightly different than the Proprietary Wireless task in the Kernel 201 Application. In the instructor application the Proprietary Wireless task only handles the receive events. Transmit events are triggered by the VCOM task in the instructor application. 

1. RAIL interrupt fires and the labPropRadioEventHandler() function is called. This function determines that a packet has been received, tells RAIL to hold the packet and sends the packet pointer to the Proprietary Wireless task via a Task Message Queue to be processed.
2. The labPropRxTask() runs due to the message being received and calls labPropRadioRxData() to process the RAIL packet.
3. The function labPropRadioRxData() toggles the LED to signal a packet has been received, then it uses the RAIL Peek function to pull out the data from the packet. The use of the peek function replaces the need for a memcopy or similar to pull data from the packet. After the data has been read from the packet, the RAIL packet is released.
4. The function labVCOMTx() is called to send the data that was pulled out of the RAIL packet to the Electron App. The function then puts the data into the transmit ring buffer and triggers the VCOM transmit where it sends one byte at a time. After every byte is transmitted, the interrupt fires and if there’s more data in the ring buffer to send, the next byte is sent. If there is no more data to send, the transmit operation stops.
5. After the data was loaded into the ring buffer, the labVCOMTx() function returns while the transmit is occurring and the Proprietary Wireless task goes back to pending on the Task Message Queue.

 

VCOM Task

 

The VCOM task takes in data from the Electron App over serial and transmits it to the Kernel 201 Application via Proprietary Wireless. The data received from the Electron App comes in the format of two sync bytes, two bytes for the Task ID, a LAB_MSG_s packet and then two end sync bytes. A state machine is used in the UART interrupt to handle the received data. Once a full packet has been received, a semaphore is posted to signal to the VCOM task to signal that it is time to transmit the data received. The VCOM task takes the data received and calls labPropTx() where the data is loaded into the RAIL transmit queue. After the data is successfully transmitted, the task goes back to pending waiting for another message to send.

 

Kernel 201 Instructor Electron App

The Electron App is a cross-platform desktop application that communicates via serial to the Kernel 201 Instructor Application. The app allows you to interact with all Thunderboard Sense 2s running the Kernel 201 application.

To get started, you need to have npm installed on your machine and have the Kernel 201 Instructor Electron App source code from the Kernel 201: Project Resources page.

From the electron app directory run the following commands:

npm install
npm start

The install command will download all necessary packages for the application. The command npm start will run the application. There is also the option to generate executable packages for both Windows and Mac via the following commands:

npm run package-win
OR
npm run package-mac

Windows packages can only be generated on Windows and Mac packages can only be generated on Mac. The advantage of generating packages is you do not need to have npm or node installed on a machine when a package is used.

Using the Kernel 201 Instructor Electron App

 

The first screen that should appear is the Scan Serial Ports window. Make sure the instructor application board is plugged into your computer and click scan.

 

After scanning you should see at least one device. On Mac’s the SiLabs boards show up as /dev/tty.usbmodem and on Windows they will show up as COM. There is a filter in place to not show every serial device connected in an effort to make this simpler. If you find that you can not find the device, look at the file serial.js located in the app/js directory and remove the Silicon Labs filter.

Note: If you have the Blue Gecko and the Thunderboard Sense 2 connected to the same computer, both will show up. Be sure to select the right device!

 

Once connected to the serial device, you will be presented with the window above. To view all Kernel 201 Application devices, click View Devices. To send commands to all Kernel 201 Application devices, click Control Devices.

 

Under View Devices, any Kernel 201 Application devices should show up. Remember, those boards only transmit their status once every 10 seconds so it may take a little while for them to appear. If you make changes to the board via the WebBluetooth App, those changes should eventually be reflected here as well.

 

To send commands to the boards, go to the Control Devices window. Here you have the ability to configure the LEDs and then either send it once or send it repeatedly. If you have the WebBluetooth App open and connected to the Kernel 201 Application, as you push changes out via the Electron App you should see the changes reflected in the WebBluetooth App immediately.

 

Final Thoughts

The instructor application and Electron App provide a simple way to interact with the Kernel 201 Application via Proprietary Wireless. While the response time is very slow compared to Bluetooth and the WebBluetooth App, the Proprietary Wireless provides a way to communicate with more than one board at a time which can be extremely useful. 

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

 

Introduction

Up until this point, all of the tasks covered in this blog series have been for wireless communication and the system watchdog. This post will cover the two user interface tasks: LEDs and buttons. These tasks are simple interfaces that take advantage of some of the hardware on the Thunderboard Sense 2. In a real-world application, these tasks would be just part of a number of application tasks that may interact with other sensors, user input or even other processors.

 

LED Task

When the LED Task is first created, there are two sets of LEDs that are initialized. The Thunderboard Sense 2 provides a simple red and green LED controlled by GPIO pins, but it also has RGB LEDs on both sides of the board. The RGB LEDs require the use of a hardware timer to control the color, so they can show any color you wish. To keep the lab simpler, the LEDs only offer red, green and yellow since those colors are available on both the GPIO LED and the RGB LEDs.

 

The LED Task is structured like all other tasks in the system (except for the watchdog task) in that it pends on a task message queue to perform an action.

The Task Message Queue processes two events and one RTOS error. These events are:

• RTOS_ERR_TIMEOUT
• LAB_Q_ID_MSG
• LAB_Q_ID_LED_TMR

 

RTOS_ERR_TIMEOUT

As part of the software watchdog, the LED Task must feed the software watchdog at a specified rate. There is a define in lab.h that all tasks use called LAB_WDOG_TASK_TIMEOUT_MS. This define specifies how often every task should check-in with the software watchdog. If the Task Message Queue does not receive a message before the timeout value is hit, the pend call returns with RTOS_ERR_TIMEOUT. Since it’s a timeout the LED Task knows that no message was received, it only feeds the software watchdog and then starts pending on the Task Message Queue again.

 

LAB_Q_ID_MSG

When another task in the system wishes to send a command to the LED Task, a lab message must be sent to the LED Task via the Task Message Queue. In most cases, this is either the Bluetooth or Proprietary Wireless task relaying LED control messages.

After a valid command message is successfully processed, an update is sent to both the Bluetooth and Proprietary Wireless tasks to alert them that the LEDs have been changed. The Bluetooth Web App will immediately reflect these changes due to the use of Bluetooth notifications. The Kernel 201 Instructor Application will be delayed on updating the LED status due to the Proprietary Wireless task transmitting on a fixed interval.

 

LAB_Q_ID_LED_TMR

When the LED Task is sent a command to blink the LED, a software timer is enabled. When the Micrium OS Software Timer expires, a callback function is executed similar to how an interrupt may trigger an interrupt routine. The software timer callback is treated similar to an interrupt function in that the code must be short because the callback function is executing out of the software timer’s callstack. Rather than controlling the LEDs from the callback, a message is sent to the LED Task via the Task Message Queue sending the message LAB_Q_ID_LED_TMR to signal that a software timer timeout occurred. The LED Task then knows based on the signal from the timer callback that it should blink the LEDs.

 

Button Task

After the Button Task is created, it initializes the two push buttons on the Thunderboard Sense 2. The Button Task is structured like all other tasks in the system (except for the watchdog task) in that it pends on a task message queue to perform an action. The button state is obtained by polling the GPIO state for each button’s GPIO. In low-power systems, interrupt-based buttons would make more sense but in the Kernel 201 Application, it is assumed the board is always powered via USB so low-power is not a concern.

 

The Button Task’s Task Message Queue processes only one event and one error. If there was a desire to add the ability to change the polling rate of the buttons, the Task Message Queue could be adjusted to accept a lab message to change the polling rate.

• RTOS_ERR_TIMEOUT
• LAB_Q_ID_BTN_TMR

 

RTOS_ERR_TIMEOUT

As part of the software watchdog, the Button Task must feed the software watchdog at a specified rate. There is a define in lab.h that all tasks use called LAB_WDOG_TASK_TIMEOUT_MS. This define specifies how often every task should check-in with the software watchdog. If the Task Message Queue does not receive a message before the timeout value is hit, the pend call returns with RTOS_ERR_TIMEOUT. Since it’s a timeout the Button Task knows that no message was received, it only feeds the software watchdog and then starts pending on the Task Message Queue again.

 

LAB_Q_ID_BTN_TMR

The Button Task operates by polling the GPIO state for the buttons. The task uses a Micrium OS Software Timer similar to the LED Task. When the timer expires, a callback is executed from the software timer’s call stack. The callback function quickly checks the state of the buttons. The callback function then sends the state of the buttons to the Button Task via the Task Message Queue specifying the button state in the void* parameter.

The Button Task passes the data it receives from the time callback to the function labBtnCheckUpdate(). This function determines if either button state has changed. If one or both buttons have had a state change, the information is sent via the Task Message Queue to both the Bluetooth and Proprietary Wireless tasks. In the Bluetooth Web App the change will be seen immediately due to the use of the Bluetooth notifications. The Kernel 201 Instructor Application will not see the change immediately due to the Proprietary Wireless Task transmitting on a fixed interval. This means if you wish to see a “pushed” state for either button in the Kernel 201 Instructor Application you must hold the button until after the Proprietary Wireless task has transmitted.

 

Final Thoughts

The LED and Button Tasks are two very simple UI tasks implemented in the Kernel 201 Application. In a real-world application, other more complex tasks that communicate with external sensors/hardware would most likely exist alongside simple tasks such as these. These two tasks provide a solid framework to build a more complex application on top of.

As always, if there are any comments, questions or concerns, feel free to leave them below.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Note: It is important to understand RAIL API calls are not thread-safe. The design of the Proprietary Wireless task is to ensure multiple transmit or receive RAIL calls are not made simultaneously.

 

Introduction

The goal of the Proprietary Wireless task in the Kernel 201 Application is to communicate with another Silicon Labs board running the Kernel 201 Instructor Application. In a lab setting there may be many Thunderboard Sense 2s running the Kernel 201 Application and they would all communicate to one Kernel 201 Instructor Application board.

Just like the Bluetooth task, the Proprietary Wireless task will handle only the wireless communication and pass messages to other tasks in the system as needed. The Proprietary Wireless task will handle both transmitting and receiving in one task rather than having them split into two separate tasks.

 

Kernel 201 Proprietary Wireless Initialization

When the Proprietary Wireless task is started, the first action it needs to perform is to configure the radio. This is a separate configuration than the Bluetooth configuration which has already occurred (Bluetooth task has a higher priority than the Proprietary Wireless task). The configuration of the radio is done in two different locations: the Proprietary Configurator and the labPropRadioInit() function.

 

The kernel201.isc file holds the Proprietary Wireless Configuration in addition to the Bluetooth Configuration. For the Kernel 201 Application, the default configuration in the Proprietary Configurator is all that is needed. In the screenshot above, the second profile was removed, but it is not necessary to do so.

labPropRailHandle = RAIL_Init(&labPropRailCfg, NULL);       // 1

RAIL_SetTxFifo(labPropRailHandle,                           // 2
               labPropTxFifo,
               0,
               LAB_PROP_TX_FIFO_SIZE);


RAIL_TxPowerConfig_t railTxPowerConfig = {
#if HAL_PA_2P4_LOWPOWER
    .mode     = RAIL_TX_POWER_MODE_2P4_LP,
#else
    .mode     = RAIL_TX_POWER_MODE_2P4_HP,
#endif
    .voltage  = HAL_PA_VOLTAGE,
    .rampTime = HAL_PA_RAMP,
};

if (channelConfigs[0]->configs[0].baseFrequency < 1000000000UL) {
    railTxPowerConfig.mode = RAIL_TX_POWER_MODE_SUBGIG;
}

RAIL_EnablePaCal(true);                                     // 3
status = RAIL_ConfigTxPower( labPropRailHandle,
                            &railTxPowerConfig);
APP_RTOS_ASSERT_CRITICAL((status == RAIL_STATUS_NO_ERROR), 1);

RAIL_SetTxPower(labPropRailHandle,
                HAL_PA_POWER);

RAIL_ConfigChannels(labPropRailHandle,                      // 4
                    channelConfigs[0],
                    NULL);

RAIL_ConfigCal(labPropRailHandle,
               RAIL_CAL_ALL);

RAIL_ConfigEvents(labPropRailHandle,                        // 5
                  RAIL_EVENTS_ALL,
                  RAIL_EVENT_SCHEDULER_STATUS
                  | RAIL_EVENTS_TX_COMPLETION
                  | RAIL_EVENTS_RX_COMPLETION
                  | RAIL_EVENT_CAL_NEEDED);

RAIL_SetFixedLength(labPropRailHandle,                      // 6
                    LAB_PROP_PACKET_SIZE);

schedulerInfo.priority = 200;                               // 7
RAIL_StartRx( labPropRailHandle,
              LAB_PROP_RX_CHANNEL,
             &schedulerInfo);

 

The configuration performed in labPropRadioInit() is shown above. There is a great multi-part tutorial on RAIL that walks through each of these calls and can be found here: RAIL Tutorial.

1. The labPropRadioInit() function first initializes the RAIL handle. The same RAIL handle will be used for transmit and receive in the Proprietary Wireless task.
2. The RAIL_SetTxFifo() function passes in the transmit FIFO buffer required for queueing up data to send. It is not necessary to specify a receive buffer because one is already allocated internally in the RAIL stack.
3. Based on the railTxPowerConfig above, the PA calibration is enabled (must be done before RAIL_ConfigTxPower()) and the transmit power is configured. After the transmit power has been configured, a call must be made to RAIL_SetTxPower() to reapply the transmit power configuration.
4. After the radio transmit power has been configured, the channels we will use must be configured. The channelConfigs[0] array comes from the Proprietary Configurator. For the Kernel 201 Application we will use two channels: 0 and 9. Data will be received on channel 0 and transmitted on channel 9.
5. The call to RAIL_ConfigEvents() configures what callbacks events are enabled. The RAIL_EVENTS_TX_COMPLETION and RAIL_EVENTS_RX_COMPLETION will signal when a transmit has completed and we need to start listening for data again or when we’ve received a packet and need to process it.
6. The call to RAIL_SetFixedLength() changes the size of the packet we expect to receive from the default of 32 bytes to LAB_PROP_PACKET_SIZE (48 bytes in this case). This is necessary because the default size of a LAB_MSG_s message is 32 bytes and we must include extra data to indicate what task it must be sent to.
7. After all of the configurations have been made on the RAIL handle, a call is made to RAIL_StartRx() on the LAB_PROP_RX_CHANNEL to begin listening for messages. Because of the way the radio is configured for Bluetooth and Proprietary Wireless, the radio is now shared between the two protocols. Bluetooth has a higher priority than Proprietary so it has the ability to take control of the radio away from the Proprietary stack if it needs to transmit or receive. This is something that must be taken into account when designing the Kernel 201 Instructor Application.

 

Kernel 201 Proprietary Wireless Task Design

The Proprietary Wireless task loop is structured just like all other tasks in the Kernel 201 Application (except for the watchdog task). When the task is created, a call is made to labPropRadioInit() which goes through the initialization as shown above. After the radio is configured for Proprietary Wireless it waits on the Task Message Queue.

 

while (DEF_TRUE) {
    p_msg = OSTaskQPend( LAB_WDOG_TASK_TIMEOUT_MS,
                         OS_OPT_PEND_BLOCKING,
                        &lab_q_id,
                         0,
                        &err);

    do {
        if(err.Code == RTOS_ERR_TIMEOUT) {
            break;
        } else if(err.Code != RTOS_ERR_NONE) {
            APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);
        }

        switch(lab_q_id) {
            case LAB_Q_ID_PROP_RX:
                labPropRadioRxData((RAIL_RxPacketHandle_t)p_msg);
                break;

            case LAB_Q_ID_PROP_TMR:
                labPropRadioTxData();
                break;

            case LAB_Q_ID_MSG:
                labPropUpdateStatus(p_msg);
                labUtilMsgFree(p_msg);
                break;

            default:
                break;
        }

    } while(0);

    labWDOGFeed(LAB_TASK_PROP);
}

 

The Task Message Queue processes three events and one RTOS error. These events are:

• RTOS_ERR_TIMEOUT
• LAB_Q_ID_MSG
• LAB_Q_ID_PROP_TMR
• LAB_Q_ID_PROP_RX

 

RTOS_ERR_TIMEOUT

As part of the software watchdog, the Proprietary Wireless task must feed the software watchdog at a specified rate. There is a define in lab.h that all tasks use called LAB_WDOG_TASK_TIMEOUT_MS. This define specifies how often every task should check-in with the software watchdog. If the Task Message Queue does not receive a message before the timeout value is hit, the pend call returns with RTOS_ERR_TIMEOUT. Since it’s a timeout the Proprietary Wireless task knows that no message was received, it only feeds the software watchdog and then starts pending on the Task Message Queue again.

 

LAB_Q_ID_MSG

When another task in the system wishes to send data via Proprietary Wireless, a lab message must be sent to the Proprietary Wireless task via the Task Message Queue. In most cases, this is used when a task has completed a request and is updating the remote Kernel 201 Instructor Application. Unlike the Bluetooth task, data is not transmitted immediately. Instead it is stored in a status structure and transmitted on a fixed interval.

 

LAB_Q_ID_PROP_TMR

The Kernel 201 Application is designed to be used in a lab class situation, with many Thunderboard Sense 2 boards running and only one Kernel 201 Instructor Application running. In order to not overwhelm the Kernel 201 Instructor Application, the Kernel 201 Application transmits status data on a fixed time interval. This is necessary because if the Kernel 201 Application responded to changes immediately, this would mean every time the Instructor Application pushed out an LED change every Kernel 201 Application would respond at the exact same time and messages would be dropped.

 

When the status data is transmitted, it must fit into the same packet size as the data we receive, specified by LAB_PROP_PACKET_SIZE. Since there may be multiple devices transmitting on the same channel to the Kernel 201 Instructor Application, each device must be differentiated.

typedef struct {
    CPU_INT16U seq_num;
    CPU_INT08U device_name[LAB_DEVICE_NAME_MAX_LEN];
} LAB_PROP_DATA_TX_s;

 

The struct above is used to inform the Kernel 201 Instructor Application who sent the data it is receiving. The seq_num value is not used in the current revision of the application on the transmit side, but it is used on the receive side which will be covered in another section of this post.

typedef struct {
    LAB_MSG_LED_s led;
    LAB_MSG_BTN_s btn;
    LAB_MSG_SI7021_s si7021;
    CPU_INT32U err_cnt;
    CPU_INT32U updated;
} LAB_PROP_STATUS_s;

 

The LAB_PROP_STATUS_s struct is the second part of the data sent to the Kernel 201 Instructor Application. When lab messages are received from other tasks in the system, the data is stored in this structure and transmitted on a fixed interval. The reason for the separate struct is this data will be peeled away from the LAB_PROP_DATA_TX_s and sent to a desktop application on the Kernel 201 Instructor Application side.

The diagram below shows how the Proprietary Wireless task uses a software timer to trigger transmits. All data that is received from other tasks in the system is stored in a status structure and when the timer expires, the status structure is transmitted.

 

1. When the labPropTmr hits the timeout value, the callback labPropTmrCallback() is executed from the OS Timer stack. The labPropTmrCallback() function sends a signal to the Proprietary Wireless task via the Task Message Queue by sending LAB_Q_ID_PROP_TMR in the msg_size field.
2. The Proprietary Wireless Task Message Queue releases upon receiving a message from the timer callback. It determines based on the lab_q_id that it is a timer callback. The Proprietary Wireless Task then grabs the current status data, writes it to the RAIL Tx FIFO and starts the transmission via RAIL_StartTx(). The RAIL_StartTx() call is a non-blocking call, so it will return as soon as it successfully initiates the transfer.
   Note: Typically in an RTOS application a guard should be placed around the RAIL_WriteTxFifo() and RAIL_StartTx() to prevent a second call to either before receiving the RAIL events callback to signal success or error on the transmit. Since the application only transmits on a fixed interval it is not as important to protect multiple writes since they are spaced out by multiple seconds.
3. After the transmit is complete, the RAIL events callback will execute. The events flag will be set to RAIL_EVENTS_TX_COMPLETION which signals it is now ok to switch the radio to another mode. Since the radio is used by both Bluetooth and Proprietary Wireless, a call must be made to RAIL_YieldRadio() to signal that the radio is free. After yielding the radio we must call RAIL_StartRx() to start background listening for Proprietary Wireless packets in-between Bluetooth transmissions.
   Note: If you were to transmit and receive on the same channel, the RAIL_StartRx() call would not be necessary. Since the Kernel 201 Application transmits and receives on different channels, it is necessary to call RAIL_StartRx() and specify what channel to listen on.

 

LAB_Q_ID_PROP_RX

 

When the radio is not communicating via Bluetooth or transmitting a Proprietary Wireless message, it is in a listening state for Proprietary Wireless messages from the Kernel 201 Instructor Application. All boards running the Kernel 201 Application listen for messages on the same channel. This allows the Kernel 201 Instructor Application to broadcast messages to all boards running the Kernel 201 Application.

typedef struct {
    CPU_INT16U seq_num;
    CPU_INT16U task_dest;
    void* p_data;
} LAB_PROP_DATA_RX_s;

 

When data is received, it is expected to be a specific size and in a specific format. The size was configured during the RAIL configuration; all packets are LAB_PROP_PACKET_SIZE. The format of the data is a combination of the structure above and a LAB_MSG_s. By reusing the LAB_MSG_s structure this allows the Proprietary Wireless task to just “peel off” the LAB_PROP_RX_s data and send the LAB_MSG_s data to the appropriate task. The images below show how an LED message fits into the RAIL Rx packet.

 

After a packet is received, the Proprietary Wireless task will copy the LAB_MSG_s data into a lab message and send it to the task specified in the task_dest field. The following flowchart shows how packets are received in the Kernel 201 Application.

 

1. When a packet is received on the radio, the RAIL stack triggers a callback to the specified callback function labPropRailEventHandler(). Once it is determined that the event triggering the callback is a packet has been received, the RAIL Event Handler must determine if we’ve seen this message before. The Kernel 201 Instructor Application sends out multiple copies of the same message due to the possibility that some Thunderboard Sense 2s may be communicating via Bluetooth or transmitting Proprietary Wireless messages. By using a sequence number, this allows the RAIL Event Handler to quickly determine if the message has already been seen, and if so release the message. If it is a new sequence number that we have not yet seen, the pointer for the packet is passed to the Proprietary Wireless task to be processed.
2. The Task Message Queue releases when the RAIL packet pointer is received from the RAIL Event Handler. The packet pointer is passed into labPropRadioRxData() where a lab message is allocated, a lab message is extracted from the RAIL packet and the message is copied into the allocated buffer. The destination of the lab message is also pulled from the RAIL packet, the data is sent to the appropriate task and then the RAIL packet is released.

 

Final Thoughts

The Proprietary Wireless task is a much more complex task than the Bluetooth task when it comes to wireless communication. This is partially due to the flexibility of the Proprietary Wireless stack but also because the RAIL API calls are the lowest level calls available to interface with the radio. When the Bluetooth stack wishes to use the radio, it also must use RAIL API calls under the hood.This application only uses a small subset of the Proprietary Wireless Configurator and RAIL API. For more detailed information on RAIL, check out the resources on this page.