SWRU439M October   2015  – April 2022

 

  1.   Trademarks
  2. 1Introduction
  3. 2Overview
    1. 2.1 Sensor Controller and AUX Domain Hardware Overview
      1. 2.1.1 Hardware Functionality
      2. 2.1.2 Power and Clock Management
        1. 2.1.2.1 CC13x0 and CC26x0 Operation Modes
        2. 2.1.2.2 CC13x2 and CC26x2 Operation Modes
        3. 2.1.2.3 Communication With the System CPU Application
    2. 2.2 Sensor Controller Interface Driver
      1. 2.2.1 Tailored How-To-Use Guide
      2. 2.2.2 Doxygen Documentation
    3. 2.3 Sensor Controller Programming Model
    4. 2.4 Sensor Controller Tasks
      1. 2.4.1 Data Structures
      2. 2.4.2 Task Code Blocks
      3. 2.4.3 High-Level Program Flow
    5. 2.5 Task Testing and Debugging
    6. 2.6 Run-Time Logging
  4. 3Prerequisites
    1. 3.1 Driver
    2. 3.2 Examples
  5. 4Installation
    1. 4.1 Sensor Controller Studio for Windows
      1. 4.1.1 Update Service
    2. 4.2 Sensor Controller Studio CLI for Linux (64-Bit)
  6. 5Sensor Controller Studio Tutorials
  7. 6Sensor Controller Studio Walkthrough
    1. 6.1  Start Page and Navigation
    2. 6.2  Documentation
    3. 6.3  Open the Example
    4. 6.4  Project Panel
    5. 6.5  Task Panel Settings
    6. 6.6  Constants and Data Structures Panel
    7. 6.7  Task Code Editor Panels
    8. 6.8  I/O Mapping Panel
    9. 6.9  Code Generator Panel
    10. 6.10 Compiling Example Applications in IAR or CCS
    11. 6.11 Task Testing Panel
      1. 6.11.1 Task Testing Setup
      2. 6.11.2 Task Testing Session
      3. 6.11.3 Data Handling
      4. 6.11.4 Task Debugging Panel
    12. 6.12 Run-Time Logging Panel
      1. 6.12.1 Run-Time Logging Setup
      2. 6.12.2 Run-Time Logging Session
  8. 7References
  9. 8Revision History

2.3 Sensor Controller Programming Model

Sensor Controller Studio is project-based. All data associated with a Sensor Controller project is stored in one file (*.scp). Each project may contain one or more Sensor Controller tasks (for example, capacitive sensing and ADC measurement). The output of a project is one SCIF driver.

The task code programming language uses a syntax that is similar to C, but has limited features compared to C because it specifically targets the instruction set and architecture of the Sensor Controller Engine. For example, there is only support for 16-bit variables.

Hardware peripherals and software algorithms are available as resources. For each task, a set of resources must be selected and configured to enable different types of functionality, such as:

  • Analog and digital peripheral modules (ADC)
  • Analog and digital general-purpose I/O (GPIO) pins
  • Simple and complex software algorithms
  • Bit-banged serial interfaces
  • Task scheduling and event handling,
  • Communication with the System CPU

Each task resource enable a set of procedures (equivalent to functions in C), with associated constants and variables. The task code can call these procedures to access hardware modules, firmware framework features, and optimized software algorithms.

It is possible to add user-specified constants and variables that can be linked to resource configuration values (for example, the number of ADC input pins).

The programming model and firmware framework are optimized for low overhead when communicating with the System CPU application, low AUX RAM memory footprint, and efficient use of the Sensor Controller's instruction set. To minimize power consumption, the Sensor Controller enters standby mode when it is idle.