SimpleLink™︎ Sub-1 GHz Wireless Microcontroller - Sensor Controller Engine Part 2: RTOS Integration

10 Nov 2016

Complexity: medium

What do you need:

two CC1310 LaunchPads
Code Composer Studio
TI RTOS
Sensor Controller Studio

This blog digs into the sub-module that manages communication with sensors. A dedicated part of the IC that takes care that Radio and CPU can sleep until something meaningful happens in sensor land.

adapted from: ti

You'll learn how to run the system low power and let the Sensor Controller module wake up the rest of the CC1310 only when needed.

In part 2, we look at the TI-RTOS integration between the Engine, ARM core and radio or the CC1310 controller.

Sensor Controller Engine: WSN Node example (cont.)

In the previous post, I looked at the Sensor Controller Engine (SCE) in isolation. I used the Studio and configured the SCE to sample a single ADC input.

And then the Studio talked to the SCE directly. We ran the setup code, sampled the input and showed the measurements on a graph.

This is useful in a way, because we now know that that part works. But this isn't firmware yet. We haven't integrated the sampling in an application.

That full integration is done for us in the remainder of the WSN Node example that we started to review in Part 1.

Here's a summary of what this program does, quoted from the readme file.

I've changed a few parts (in blue italic font) because our board doesn't have a light sensor.

Example Summary

The WSN Node example illustrates how to create a Wireless Sensor Network Node device which sends packets to a concentrator.

This example is meant to be used together with the WSN Concentrator example to form a one- to-many network where the nodes send messages to the concentrator.

This examples showcases the use of several Tasks, Semaphores and Events to get sensor updates and send packets with acknowledgement from the concentrator.

For the radio layer, this example uses the EasyLink API which provides an easy-to-use API for the most frequently used radio operations.

Peripherals Exercised

Board_LED0 - Toggled when the a packet is sent
Board_ADCCHANNEL_A3 - Used to measure an Analog voltage that we set with a potentiometer by the SCE task
Board_BUTTON0 - Selects fast report or slow report mode. In slow report mode the sensor data is sent every 5s or as fast as every 1s if there is a significant change in the ADC reading. in fast reporting mode the sensor data is sent every 1s regardless of the change in ADC value. The default is slow reporting mode.

This is the short application structure (CM3 means ARM Cortex M3 core):

This examples consists of two tasks, one application task and one radio protocol task. It also consists of an Sensor Controller Engine, SCE, Task which samples the ADC.

On initialisation the CM3 application sets the minimum report interval and the minimum change value which is used by the SCE task to wake up the CM3. The ADC task on the SCE checks the ADC value once per second. If the ADC value has changed by the minimum change amount since the last time it notified the CM3, it wakes it up again. If the change is less than the masked value, then it does not wake up the CM3 unless the minimum report interval time has expired.

The NodeTask waits to be woken up by the SCE. When it wakes up it toggles `Board_LED1` and sends the new ADC value to the NodeRadioTask.

The NodeRadioTask handles the radio protocol. This sets up the EasyLink API and uses it to send new ADC values to the concentrator. After each sent packet it waits for an ACK packet back. If it does not get one, then it retries three times. If it did not receive an ACK by then, then it gives up.

RadioProtocol.h* can also be used to change the PHY settings to be either the default IEEE 802.15.4g 50kbit, Long Range Mode or custom settings. In the case of custom settings, the *smartrf_settings.c* file is used. This can be changed either by exporting from Smart RF Studio or directly in the file.

We will ignore the Radio Task and its configurations. This blog covers that.

For this example, you just have to understand that we can tell the radio to wake up and transmit a chunk of data to a WSN concentrator.

Our focus is on the NodeTask. This TI-RTOS task does 3 main things.

initialise the SCE and start it.
Sleep until woken up by SCE
Ask Radio Core to send out the SCE data.

The logic is in the nodeTaskFunction() function in NodeTask.c.

Initialise and start SCE

The core logic of the SCE has been configured in Part 1.

The startup part of our Node task (it's called Node task because we are the Node in the WSN scenario) activates that.

    /* Start the SCE ADC task with 1s sample period and reacting to change in ADC value. */
    SceAdc_init(0x00010000, NODE_ADCTASK_REPORTINTERVAL_FAST, NODE_ADCTASK_CHANGE_MASK);
    SceAdc_registerAdcCallback(adcCallback);
    SceAdc_start();

The callback function's only task is to tell us the sampled value and wake up the Cortex core when the SCE deems that neccessary:

void adcCallback(uint16_t adcValue)
{
    /* Save latest value */
    latestAdcValue = adcValue;

    /* Post event */
    Event_post(nodeEventHandle, NODE_EVENT_NEW_ADC_VALUE);
}

Sleep until woken up

In the loop of our RTOS task, we put the core to sleep. When the SCE wants to wake us up, it'll call the callback adcCallback() above.

    while(1) {
        /* Wait for event */
        uint32_t events = Event_pend(nodeEventHandle, 0, NODE_EVENT_ALL, BIOS_WAIT_FOREVER);

Send Data over the Radio

When that callback is executed by the SCE, our ARM core wakes up the radio and communicates with the Concentrator.

        /* If new ADC value, send this data */
        if (events & NODE_EVENT_NEW_ADC_VALUE) {

            /* Send ADC value to concentrator */
            NodeRadioTask_sendAdcData(latestAdcValue);
        }
    }

Then we go back to the start of the while() loop and go back to sleep. This cycle runs as long as the device is turned on.

You will not be able to appreciate the low power use when you're running this via a debugger.

An attached debugger (software-attached, not just physically attached) prevents the core to go into low power mode.

Testing the WSN

Program your second LaunchPad with the WSN Concentrator example, and off you go.

If you have an LCD Boosterpack (430BOOST-SHARP96) you can mount that on the Concentrator and view the results.

Else open a terminal program to the Concentrator's serial port and check its output (115200 kbps, 8 data bits, 1 stop bit, no parity or flow control).

You don't absolutely need the Concentrator running. The Node sends data and waits for an acknowledgement from the Concentrator.

But it will happily timeout and continue its duties when you don't have a receiving counterpart to send that ACK.

SimpleLink

Sub-1 GHz Wireless Microcontroller - Check Received Signal Strength