This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
This FAQ post will contain a list of the most common questions regarding the use of Sensor Controller Studio (SCS). SCS is still under development and we continue to work on and release maintenance releases which includes both (potential) bug fixes and new features. Feedback is appreciated.
The Sensor Controller is the terminology used to describe the sensor module in the CC26xx and CC13xx family of devices. This is in a separate power domain (AUX_PD) which contains a dedicated low power 16-bits processor, 2 KB RAM, Peripherals (ADC, Comparator, timers, TDC, etc). This module is designed for ultra low power and high flexibility. The sensor controller has the ability to do its own power and clock management of AUX_PD, independently of the MCU domain. Sensor Controller Studio (SCS) is a GUI tool used to write, test and debug code for the CC26xx/CC13xx Sensor Controller. This GUI tool generates a Sensor Controller Interface driver, which is a set of C source files that are compiled into the System CPU (ARM Cortex-M3) application. These source files contain the Sensor Controller firmware image and allow the System CPU application to control and exchange data with the Sensor Controller.
You can press F1 (Help Menu) in SCS or go to the “Help->Sensor Controller Studio Help” menu item in Sensor Controller Studio (SCS) to open the comprehensive help documentation. This covers almost everything except for for the generated driver API documentation which is found directly in the driver source files (scif.c, scif_framework.c, scif_osal_tirtos.c/scif_osal_none.c).
In short, very little. Look at this thread post for some details. An even more detailed description will be written in the future:
https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/467128/1681248#1681248
Refer to section 17.5.2.1 Active Mode in the TRM. The sensor controller, which is in the AUX power domain, has power modes which is independent upon the device power mode. In active mode the SCS framework will enable the 24 MHz clock source (derived from SCLK_HF). In standby mode the SCS framework will either turn off the clock or switch to the low speed 32 kHz clock if TIMER or GPIO event trigger is enabled. This is also the speed at which the sensor controller processor is running at. The maximum frequency is 24 MHz, and the configuration of clock division is controlled by the system CPU by configuring the AON_WUC:AUXCLK.SCLK_HF_DIV register.
This section contains guidelines for how to integrate a SC driver into an application.
(Optional) Move the SCS project file (.scp) into your project folder and set the Source code output directory to your source project folder. Then the SCS compiled source files (driver and framework) will be updated directly in your application workspace.
SCS will generate the following files that you need to include (mandatory) in your project: - scif.c ( AUX RAM Image, IO Mapping, SC RAM variables memory address, some low level functions) - scif.h - scif_framework.c ( General Driver Framework ) - scif_framework.h - scif_osal_tirtos.c ( OS Specific ) - scif_osal_tirtos.h
In the examples that is included in the SCS Installer the main.c or main_tirtos.c is pre-made application source code which will run on the main application processor (APP CPU). There is multiple ways on how to synchronize the sensor controller processor (SCP) and the APP-CPU. In the Analog Light Sensor example a TI-RTOS task is pending on a semaphore which is released in the HWI call back function scTaskAlertCallback. This callback is triggered by an event that is generated at the end of the SC task execution if the fwGenAlertInterrupt() procedure has been called. When the task is released from pending on the semaphore, new data is read from AUX RAM (ADC light sensor bin value). This use demonstrates low power because the system will enter standby when the task is pending on the semaphore and the callback HWI will allow the system to wake up from sleep.
The application developer must chose how to integrate and synchronize the main application with the sensor controller driver. Below there is listed a few general concepts in TI-RTOS that can be used for use cases that is similar to the analog light sensor example. The only way to set up signalling that can wake the main system is through enabling the callback which will run in HWI context.
For more general training on our devices (including TI-RTOS concepts) check out our SimpleLink Academy Training:http://software-dl.ti.com/lprf/simplelink_academy/overview.html
...
Place the attached fix (uart_emulator.asm) into C:\Users<xxxxxx>\Documents\Texas Instruments\Sensor Controller Studio\proc_defs
/cfs-file/__key/communityserver-discussions-components-files/538/uart_5F00_emulator.asm
Best Regards, Eirik
Please see the TI BLE Wiki www.ti.com/ble-wiki and sticky forum threads for additional examples & answers to most common questions!
Thank you for marking the thread as answered if your question was answered :)
In reply to JXS: