Synergy Software Package User's Manual
Touch Panel V2 Framework

Table of Contents

Touch Panel V2 Framework Introduction

The Touch Panel V2 Framework module provides a high-level API for obtaining touch data on coordinates and events from the touch controller. The Touch Panel V2 Framework module uses the touch chip driver SSP Supplement module for communication with the touch panel.

Touch Panel V2 Framework Module Features

  • Provides position data (X and Y coordinates).
  • Provides rotation of touch coordinates.
  • Provides the touch event type (down, up, move, hold, or invalid).
  • A callback can be registered or an API function can be used to get touch data.
  • Supports calibration of the touch panel for key elements: scalar, rotation and mechanical shifts.
  • Provides a common API interface to touch chip drivers.
  • Supports an adjustable update frequency.
touch_panel_v2_BD.png
Touch Panel V2 Framework Module Block Diagram

Touch Panel V2 Framework Module APIs Overview

The Touch Panel V2 Framework module defines API functions such as opening, calibrating, starting, stopping or closing. A complete list of the available APIs, an example API call and a short description of each can be found in the following table. A table of status return values follows the API summary table.

Touch Panel V2 Framework Module API Summary

Function Name Example API Call and Description
open g_sf_touch_panel_v2_0.p_api->open(g_sf_touch_panel_v2_0.p_ctrl, g_sf_touch_panel_v2_0.p_cfg);
Create required RTOS objects, call a lower level module for hardware specific initialization and create a thread to post touch data to a user application.
calibrate g_sf_touch_panel_v2_0.p_api->calibrate(g_sf_touch_panel_v2_0.p_ctrl, p_display, p_touchscreen, timeout);
Begin calibration routine based on provided expected and actual coordinates.
start g_sf_touch_panel_v2_0.p_api->start(g_sf_touch_panel_v2_0.p_ctrl);
Start scanning for touch events.
stop g_sf_touch_panel_v2_0.p_api->stop (g_sf_touch_panel_v2_0.p_ctrl);
Stop scanning for touch events.
touchDataGet g_sf_touch_panel_v2_0.p_api->touchDataGet (g_sf_touch_panel_v2_0.p_ctrl, p_payload, timeout);
Reads the touch data and fills in the touch payload data.
reset g_sf_touch_panel_v2_0.p_api->reset(g_sf_touch_panel_v2_0.p_ctrl);
Resets touch controller if reset pin is provided.
close g_sf_touch_panel_v2_0.p_api->close(g_sf_touch_panel_v2_0.p_ctrl);
Terminates touch thread and closes channel at HAL layer.
versionGet g_sf_touch_panel_v2_0.p_api->versionGet(g_sf_touch_panel_v2_0.p_version);
Retrieves API version and stores it in the version pointer.
Note
For more complete descriptions of operation and definitions for the function data structures, typedefs, defines, API data, API structures and function variables, review the SSP User's Manual API References for the associated module.

Status Return Values

Name Description
SSP_SUCCESS API call successful.
SSP_ERR_ASSERTION A pointer parameter was NULL, or a lower level driver reported this error.
SSP_ERR_INTERNAL The touch panel thread or event flags could not be created, or a lower level driver reported this error.
SSP_ERR_CALIBRATE_FAILED Actual touch value was not in expected range.
SSP_ERR_NOT_OPEN Touch panel is not configured. Call SF_TOUCH_PANEL_V2_Open.
SSP_ERR_IN_USE Mutex was not available, or a lower level driver reported this error.
Note
Lower-level drivers may return common error codes. Refer to the SSP User's Manual API References for the associated module for a definition of all relevant status-return values.

Touch Panel V2 Framework Module Operational Overview

The Touch Panel V2 Framework module scans data from a touch controller and invokes the user registered callback. If user callback is not registered the sf_touch_panel_v2_api_t::touchDataGet API function can be used to retrieve the data. The touch data contains touch coordinates (X and Y coordinates) and the touch event type (down, up, move, hold, or invalid). The Touch Panel V2 Framework uses an internal thread to read the touch controller.

Touch Panel V2 Framework Module Important Operational Notes and Limitations

Touch Panel V2 Framework Module Operational Notes

The key operational elements of the Touch Panel V2 Framework are described below:

Auto Initialization and Auto Start

The "Auto Initialization" property in the Synergy configurator window must be enabled to automatically initialize the framework. The "Auto start" property in the configurator window must be enabled to automatically receive touch data from the touch chip.

User Callback

The user callback must be registered to obtain touch data. If the user callback is registered then the framework will invoke the callback when touch events occur.

API to Get the Touch Data

The sf_touch_panel_v2_api_t::touchDataGet API function can be used to obtain touch data. This function will wait until new touch event data is available or it will timeout (based on the timeout argument passed to the API).

Update Frequency

The application will be notified with repeated touch events (like touch event down and touch event hold and touch event invalid) at the specified update frequency (Update Hz) configured in the Synergy configurator property window.

Note
The touch event UP and touch event DOWN will be notified regardless of the update frequency.

For example,

If the "Update Hz" property is set to 10 Hz, then only 10 repeated touch events will be notified to the application in a second.

Calibration

The touch panel V2 framework supports calibration of touch data to overcome the issues in the touch panel like: Scalar, rotation and Mechanical shifts.

To obtain the calibrated data the user needs to call the sf_touch_panel_v2_api_t::calibrate API function and pass 3 sets of expected coordinates and the obtained coordinated.

Note
The framework must be initialized before calling sf_touch_panel_v2_api_t::calibrate API.

For ex ample:

Consider a scenario where a touch panel with resolution 480 x 272 is being used. The touch panel is touched at upper left, upper right and lower right and the obtained coordinates (x, y) when touched at these touch panel locations and their expected coordinates are as illustrated below:

 Table 3   Touch Panel Coordinates

Location on Touch Panel Expected Coordinates Obtained Coordinates
Upper left corner (0, 0) (17, 20)
Upper right corner (480, 0) (464, 17)
Lower right corner (480, 272) (463, 258)

These 3 sets of values (expected and obtained coordinates) are passed into the calibrate function in the expected format. Once the sf_touch_panel_v2_api_t::calibrate API function is called, the required calibration factors are calculated and stored in the control structure. The touch data now obtained will be calibrated.

Note
Once the sf_touch_panel_v2_api_t::close API function is called the stored calibration factors are erased and the calibrate API must be called again to obtain the calibrated touch data.

Create a Custom Touch Panel Chip Driver

To create your custom Touch Chip Driver, refer to the existing touch chip driver code in SSP which is located at synergy/ ssp_supplemental / touch_drivers .

Note
This directory will only be visible if any existing touch chip driver touch_panel_chip_ft5x06 or touch_panel_chip_sx8654 is selected in the Synergy configurator . To do this go to the Synergy configurator and select New > Framework > Input >  Touch Panel V2 Framework on sf_touch_panel_v2 > Add Touch Driver. Select any existing touch driver for reference and generate project content .
Refer to the  SSP Module Development Guide document to learn more about creating a custom driver. The document can be found using this link: https://www.renesas.com/us/en/document/apn/ssp-module-development-guide-application-note.

The following instructions can be used to connect a custom touch chip driver to the Touch Panel V2 Framework:

  • Implement Touch Chip Driver Instance (synergy/ssp_supplemental/inc/framework/instances) and source file (synergy/ssp_supplemental/touch_drivers).
  • Make sure the chip specific settings are configured based on the touch screen used and the applications use case.
  • Implement the payloadGet function to obtain touch events and touch coordinates from the Touch Panel Controller.
  • Implement a reset function reset  to reset the touch chip.
  • If the touch chip is using communication protocol other than I2C or if it doesn't support external IRQ then modify the open, payloadGet, reset and close functions. Also the touch chip driver Configuration XML (located under .module_descriptions folder) must  be modified.

Configure the Custom Touch Panel Chip Driver

To configure a custom touch chip driver to a project, follow the steps below:

Step 1. Create a Synergy C project.

Step 2. Update existing touch driver XML for the custom touch driver by following these steps.  Modify any existing touch XML as described below:

  • Go to the .module_descriptions folder under the project root folder.
  • Edit touch chip driver XML:
    • Renesas##HAL Drivers##touch panel##touch_panel_chip_ft5x06####<version>.xml Or 
    • Renesas##HAL Drivers##touch panel##touch_panel_chip_sx8654####<version>.xml
  • Change name of the instance structure with name of custom driver instance structure. For example "g_touch_panel_chip_xxxxx"
  • Add the new instance declaration and api declaration in <header> tab. For example,
      <header>
             extern const sf_touch_panel_chip_instance_t g_touch_panel_chip_xxxxx;
               extern const sf_touch_panel_chip_api_t g_sf_touch_panel_chip_xxxxx;
      </header>
  • Rename all touch chip number in the XML with custom touch chip number.
  • If communication protocol other than I2C is used then change the interface and id under the <requires> tag. For example,
      <requires>
             id="module.external.ex_touch_panel_chip_ft5x06.requires.spi "     interface=" interface.framework . sf_spi_v2_on_sf_spi " display="Add framework"
      </requires >
  • Save and close the XML file

Step 3. Open project configurator and add Touch panel V2 framework, by selecting New > Framework > Input > Touch Panel V2 Framework on sf_touch_panel_v2 (If the configurator was already opened, close and open it again).

Step 4. Configure all components.

Step 5. Add the custom touch panel chip driver to the "Add Touch Driver" box. (The custom touch driver open will be visible if XML is modified correctly).

Step 6. Generate Project Content and add new directory (for example, touch_panel_chip_xxxxxx) structure under synergy/ ssp_supplemental/ touch_drivers, the directory structure will look like this:  synergy/ ssp_supplemental/ touch_drivers/ touch_panel_chip_xxxxxx (replace xxxxxx with touch controller part no).

Step 7. Add the custom driver code into this directory (ssp_supplemental/ touch_drivers/ touch_panel_chip_xxxxxx).

Step 8. Exclude existing driver from build if any (right-click the .c file > Exclude from build... > Select all > OK).

Step 9. Build the code.

Touch Panel V2 Framework Module Limitations

  • Refer to the most recent SSP Release Notes for any additional operational limitations for this module.

Including the Touch Panel V2 Framework Module in an Application

This section describes how to include the Touch Panel V2 Framework module in an application using the SSP configurator.

Note
This section assumes you are familiar with creating a project, adding threads, adding a stack to a thread and configuring a block within the stack. If you are unfamiliar with any of these items, refer to the first few chapters of the SSP User's Manual to learn how to manage each of these important steps in creating SSP-based applications.

To add the Touch Panel V2 Framework module to an application, simply add it to a HAL /Common thread using the stacks selection sequence given in the following table. (The default name for the Touch Panel V2 Framework module is g_sf_touch_panel_v2_0. This name can be changed in the associated Properties window.)

Touch Panel V2 Framework Module Selection Sequence

Resource ISDE Tab Stacks Selection Sequence
g_sf_touch_panel_v2_0 Touch Panel V2 Framework on sf_touch_panel_v2 Threads New Stack> Framework> Input> Touch Panel V2 Framework on sf_touch_panel_v2

When the Touch Panel V2 Framework module on sf_touch_panel_v2 is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description include Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.

touch_panel_v2_MS.png
Touch Panel V2 Framework Module Stack

Configuring the Touch Panel V2 Framework Module

The Touch Panel V2 Framework module must be configured by the user for the desired operation. The SSP configuration window will automatically identify (by highlighting the block in red) any required configuration selections, such as interrupts or operating modes, which must be configured for lower-level modules in order to ensure successful operation. Furthermore, only those properties that can be changed without causing conflicts are available for modification. Other properties are 'locked' and are not available for changes, and are identified with a lock icon for the 'locked' property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous 'manual' approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP configurator, and are shown in the following tables for easy reference.

Note
You may want to open your ISDE, create the module and explore the property settings in parallel with looking over the following configuration table settings; this will help orient you and can be a useful 'hands-on' approach to learning the ins and outs of developing with the SSP.

Configuration Settings for the Touch Panel V2 Framework Module on sf_touch_panel_v2

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		Selects if code for parameter checking is to be included in the build.
Thread Stack Size 512 Specify the touch panel thread stack size.
Name g_sf_touch_panel_v2_0 Module name.
Thread Priority 3 Specify the thread priority.
Update Hz 10 Specify the update rate in Hertz.
Touch Coordinate Rotation Angle (Clockwise) 0, 90 (Select this if 'Screen Rotation Angle' is 'CW' or '90'), 180 (Select this if 'Screen Rotation Angle' is FLIP or '180'), 270 (Select this if 'Screen Rotation Angle' is 'CCW' or '270')

Default: 0 		Select the touch coordinate rotation angle.
Name of generated initialization function sf_touch_panel_v2_init0 Specify the name of the generated initialization function.
Auto Initialization Enable, Disable

Default: Enable 		Select if sf_touch_panel_v2 will be initialized during startup.
Auto Start Enable, Disable

Default: Enable 		Enabling this will start to get the touch data.
Name of touch panel callback function to be defined by user NULL Touch panel callback function name.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

In some cases, settings other than the defaults can be desirable. The configurable properties for the lower-level stack modules are given in the following sections for completeness and as a reference.

Note
Most of the property settings for lower level modules are fairly intuitive and can usually be determined by inspection of the associated Properties window from the SSP configurator.

Configuring the Touch Panel V2 Framework Lower-Level Modules

Typically, only a small number of settings must be modified from the default for lower-level drivers as indicated with red text in the thread stack block. Notice that some of the configuration properties must be set to a certain value for proper framework operation and will be locked to prevent user modification. The following tables identify all the settings within the properties section for the lower-level modules:

Configuration Settings for the Touch Panel Chip sx8654

ISDE Property Value Description
Name g_touch_panel_chip_sx8654_0 Module name.
Horizontal pixel count 480 Specify the number of horizontal pins.
Vertical pixel count 272 Specify the number of vertical pixels.
Reset Port 00:11

Default: 07 		Select the chip reset port.
Reset Pin 00:15

Default: 11 		Select the chip reset pin.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the Touch Panel Chip ft5x06

ISDE Property Value Description
Name g_touch_panel_chip_ft5x06 Module name.
Horizontal pixel count 800 Specify the number of horizontal pins.
Vertical pixel count 480 Specify the number of vertical pixels.
Reset Port 00:11

Default: 10 		Select the chip reset port.
Reset Pin 00:15

Default: 02 		Select the chip reset pin.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the I2C Framework Device on sf_i2c

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: Enabled 		Selects if code for parameter checking is to be included in the build.
Name g_sf_i2c_device0 Give a name to identify the I2C Framework device. API, Config and Control instances will be created based on this name.
Slave Address 0x00 Specify the address of the I2C slave device.
Address Mode 7-Bit, 10-Bit

Default: 7-Bit 		Select the I2C address mode.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the I2C Shared Bus on sf_i2c

ISDE Property Value Description
Name g_sf_i2c_bus0 Module name.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the I2C Master Driver on r_riic

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		If selected code for parameter checking is included in the build.
Name g_i2c0 Module name.
Channel 0 Specify the IIC channel to be used with this configuration.
Rate Standard, Fast-mode, Fast-mode Plus

Default: Standard 		Standard, Fast, and Fast-plus. (See IIC Rate Calculation.)
Slave Address 0x00 Set the address of the slave device the I2C master will be communicating with.
Address Mode 7-Bit, 10-Bit

Default: 7-Bit 		Only 7-bit addresses are currently supported.
Timeout Mode Short Mode, Long Mode

Default: Short Mode 		Select the timeout mode.
Callback NULL A user callback function can be registered in i2c_api_master_t::open. If this callback function is provided, it will be called from the interrupt service routine (ISR) for each of the conditions defined in i2c_event_t. 

Warning: Since the callback is called from an ISR, do not use blocking calls or lengthy processing. Spending excessive time in an ISR can affect the responsiveness of the system.
Receive Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX),

Default: Priority 12 		Select the receive interrupt priority.
Transmit Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX),

Default: Priority 12 		Select the transmit interrupt priority.
Transmit End Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX),

Default: Priority 12 		Select the transmit end interrupt priority.
Error Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX),

Default: Priority 12 		Select the error interrupt priority.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the Transfer Driver on r_dtc Event IIC0 TXI

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		If selected code for parameter checking is included in the build.
Software Start Enabled, Disabled

Default: Disabled 		Include code for software start in the build.
Linker section to keep DTC vector table .ssp_dtc_vector_table Section to place the DTC vector table.
Name g_transfer0 Module name.
Mode Normal Specify the hardware channel.
Transfer Size 1 Byte Select the transfer mode.
Destination Address Mode Fixed Select the transfer size.
Source Address Mode Incremented Select the address mode for the destination.
Repeat Area (Unused in Normal Mode) Source Select the address mode for the source.
Interrupt Frequency After all transfers have completed Select the repeat area. Either the source or destination address resets to its initial value after completing Number of Transfers in Repeat or Block mode.
Destination Pointer NULL Specify the transfer destination pointer.
Source Pointer NULL Specify the transfer source pointer.
Number of Transfers 0 Specify the number of transfers.
Number of Blocks (Valid only in Block Mode) 0 Specify the number of blocks to transfer in Repeat or Block mode.
Activation Source (Must enable IRQ) Event IIC0 TXI Select the DTC transfer start event.
Auto Enable False Auto enable the transfer in open().
Callback (Only valid with Software start) NULL A user callback that is called at the end of the transfer.
ELC Software Event Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX), Disabled

Default: Disabled 		Select the transfer end interrupt priority.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the Transfer Driver on r_dtc Event IIC0 RXI

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		If selected code for parameter checking is included in the build.
Software Start Enabled, Disabled

Default: Disabled 		Include code for software start in the build.
Linker section to keep DTC vector table .ssp_dtc_vector_table Section to place the DTC vector table.
Name g_transfer1 Module name.
Mode Normal Specify the hardware channel.
Transfer Size 1 Byte Select the transfer mode.
Destination Address Mode Incremented Select the transfer size.
Source Address Mode Fixed Select the address mode for the destination.
Repeat Area (Unused in Normal Mode Destination Select the address mode for the source.
Interrupt Frequency After all transfers have completed Select the repeat area. Either the source or destination address resets to its initial value after completing Number of Transfers in Repeat or Block mode.
Destination Pointer NULL Specify the transfer destination pointer.
Source Pointer NULL Specify the transfer source pointer.
Number of Transfers 0 Specify the number of transfers.
Number of Blocks (Valid only in Block Mode) 0 Specify the number of blocks to transfer in Repeat or Block mode.
Activation Source (Must enable IRQ) Event IIC0 RXI Select the DTC transfer start event.
Auto Enable False Auto enable the transfer in open().
Callback (Only valid with Software start) NULL A user callback that is called at the end of the transfer.
ELC Software Event Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX), Disabled

Default: Disabled 		Select the transfer end interrupt priority.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the I2C Master Driver on r_sci_i2c

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		If selected code for parameter checking is included in the build.
Name g_i2c0 Module name.
Channel 0 to 9 Specify the SCI channel to be used with this configuration. SCI has channels as follows: Series S7: 0 1 2 3 4 5 6 7 8 9; Series S3 : 0 1 2 3 4 - - - - 9; Series S1 : 0 1 - - - - - - - 9.
Rate Standard, Fast-mode, Fast-mode plus

Default: Standard 		Select the I2C data rate.
Slave Address 0x00 Specify the slave address.
Address Mode 7-Bit, 10-Bit

Default: 7-Bit 		Only 7-bit addresses are currently supported.
SDA Output Delay (nano seconds) 300 SDA output delay in nanoseconds.
Bit Rate Modulation Enable Enable, Disable

Default: Enable 		Enables bitrate modulation function.
Callback NULL A user callback function can be registered in i2c_api_master_t::open. If this callback function is provided, it will be called from the interrupt service routine (ISR) for each of the conditions defined in i2c_event_t. 

Warning: Since the callback is called from an ISR, do not use blocking calls or lengthy processing. Spending excessive time in an ISR can affect the responsiveness of the system.
Receive Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12 		Select the receive interrupt priority.
Transmit Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12 		Select the transmit interrupt priority.
Transmit End Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12 		Select the transmit end interrupt priority.
Error Interrupt Priority Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX)

Default: Priority 12 		Select the error interrupt priority.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the Transfer Driver on r_dtc Event SCI0 TXI

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		If selected code for parameter checking is included in the build.
Software Start Enabled, Disabled

Default: Disabled 		Include code for software start in the build.
Linker section to keep DTC vector table .ssp_dtc_vector_table Section to place the DTC vector table.
Name g_transfer0 Module name.
Mode Block Specify the hardware channel.
Transfer Size 1 Byte Select the transfer mode.
Destination Address Mode Fixed Select the transfer size.
Source Address Mode Incremented Select the address mode for the destination.
Repeat Area (Unused in Normal Mode Source Select the address mode for the source.
Interrupt Frequency After all transfers have completed Select the repeat area. Either the source or destination address resets to its initial value after completing Number of Transfers in Repeat or Block mode.
Destination Pointer NULL Specify the transfer destination pointer.
Source Pointer NULL Specify the transfer source pointer.
Number of Transfers 0 Specify the number of transfers.
Number of Blocks (Valid only in Block Mode) 0 Specify the number of blocks to transfer in Repeat or Block mode.
Activation Source (Must enable IRQ) Event SCI0 TXI Select the DTC transfer start event.
Auto Enable False Auto enable the transfer in open().
Callback (Only valid with Software start) NULL A user callback that is called at the end of the transfer.
ELC Software Event Interrupt Priority Priority 0 (highest), Priority 1:14, Priority 15 (lowest - not valid if using ThreadX), Disabled

Default: Disabled 		Select the transfer end interrupt priority.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the Transfer Driver on r_dtc Event SCI0 RXI

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		If selected code for parameter checking is included in the build.
Software Start Enabled, Disabled

Default: Disabled 		Include code for software start in the build.
Linker section to keep DTC vector table .ssp_dtc_vector_table Section to place the DTC vector table.
Name g_transfer1 Module name.
Mode Normal Specify the hardware channel.
Transfer Size 1 Byte Select the transfer mode.
Destination Address Mode Incremented Select the transfer size.
Source Address Mode Fixed Select the address mode for the destination.
Repeat Area (Unused in Normal Mode Destination Select the address mode for the source.
Interrupt Frequency After all transfers have completed Select the repeat area. Either the source or destination address resets to its initial value after completing Number of Transfers in Repeat or Block mode.
Destination Pointer NULL Specify the transfer destination pointer.
Source Pointer NULL Specify the transfer source pointer.
Number of Transfers 0 Specify the number of transfers.
Number of Blocks (Valid only in Block Mode) 0 Specify the number of blocks to transfer in Repeat or Block mode.
Activation Source (Must enable IRQ) Event SCI0 RXI Select the DTC transfer start event.
Auto Enable False Auto enable the transfer in open().
Callback (Only valid with Software start) NULL A user callback that is called at the end of the transfer.
ELC Software Event Interrupt Priority Priority 0 (highest), Priority 1:14, Priority 15 (lowest - not valid if using ThreadX), Disabled

Default: Disabled 		Select the transfer end interrupt priority.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the External IRQ Framework on sf_external_irq

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		Controls whether to include code for API parameter checking.
Name g_sf_external_irq0 Framework name.
Event None, Semaphore Put

Default: Semaphore Put 		Event selection.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Configuration Settings for the External IRQ Driver on r_icu

ISDE Property Value Description
Parameter Checking BSP, Enabled, Disabled

Default: BSP 		Parameter checking setting enables or disables the addition of parameter checking code.
Name g_external_irq0 Module name.
Channel 0 Specifies the hardware IRQ channel used.
Trigger Falling, Rising, Both Edges, Low Level

Default: Rising 		Configures edge or level triggering.
Digital Filtering Enabled, Disabled

Default: Disabled 		Digital filter enable/disable.
Digital Filtering Sample Clock (Only valid when Digital Filtering is Enabled) PCLK/1, PLCK/8, PLCK/32, PCLK/64

Default: PCKL/64 		Sets noise filter sampling period.
Interrupt enabled after initialization True, False

Default: True 		Determines if the interrupt is enabled immediately after initialization.
Callback NULL A user callback function can be registered in external_irq_api_t::open. If this callback function is provided, it is called from the interrupt service routine (ISR) each time the IRQn triggers.

Warning: Since the callback is called from an ISR, care should be taken not to use blocking calls or lengthy processing. Spending excessive time in an ISR can affect the responsiveness of the system.
Pin Interrupt Priority Priority 0 (highest), Priority 1:2, Priority 3 (lowest - not valid if using ThreadX)

Default: Priority 2 		An Interrupt priority can be registered in external_irq_cfg_t::irq_ipl.
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings.

Touch Panel V2 Framework Module Clock Configuration

An example implementation of the I2C interface uses the SCI peripheral and is described here. Other implementation choices might have different selections and can be inferred from the following example. The SCI peripheral module uses the PCLKB as its clock source. The PCLKB frequency is set by using the SSP configurator Clock tab prior to a build, or by using the CGC Interface at run-time. During configuration, the I2C transfer rate is calculated and set internally by the driver based on the user selected PCLB rate and the user selected transfer rate. If the PCLKB is configured in such a manner that the user selected rate cannot be achieved, an error will be returned when initializing the driver.

Touch Panel V2 Framework Module Pin Configuration

An example implementation of the I2C interface uses the SCI peripheral and is described here. Other implementation choices might have different selections, but can be inferred from the below example. Synergy Kit specific settings for pins are shown in the following section.  The SCI peripheral module uses pins on the MCU to communicate to external devices. I/O pins must be selected and configured as required by the external device. The following table illustrates the method for selecting the pins within the SSP configuration window and the subsequent table illustrates an example selection for the I2C pins:

Pin Selection Sequence for the Touch Panel V2 Framework Module

Resource ISDE Tab Pin selection Sequence
SCI0 Pins Select Peripherals> Connectivity:SCI> SCI0
Note
The selection sequence assumes the SCI0 is the desired hardware target of the driver.

Pin Configuration Settings for the DAC Driver on r_dac

Pin Configuration Property Value Description
Operation Mode Disabled, Asynchronous UART, Synchronous UART, Simple I2C, Simple SPI, SmartCard

Default: Disabled

Simple I2C 		Select Simple I2C as the Operation Mode for SPI on SCI.
RXD1_SCL1_MISO1 None, P212, P708

Default: None 		SCL pin.
TXD1_SDA1_MOSI1 None, P213, P709

Default: None 		SDA pin.
Note
The example values are for a project using the Synergy S7G2 MCU Group and the SK-S7G2 Kit. Other Synergy Kits and other Synergy MCUs may have different available pin configuration settings.

Using the Touch Panel V2 Framework Module in an Application

The typical steps in using the Touch Panel V2 Framework module in an application are:

  1. Register a user callback in application code to receive touch data (if needed).
  2. Initialize the touch panel V2 framework module using the sf_touch_panel_v2_api_t::open API function (done automatically within SSP if "auto initialization" property is enabled).
  3. Calibration of touch data can be done by using the sf_touch_panel_v2_api_t::calibrate API function (If required).
  4. Start the touch panel framework module to begin scanning the touch data from the touch chip using the sf_touch_panel_v2_api_t::start API function (done automatically within SSP if the "auto start" property is enabled).
  5. The registered user callback is invoked by the framework when a touch event occurs and is processed in application code.
  6. Get the data using the sf_touch_panel_v2_api_t::touchDataGet API function (if the user callback is not registered).
  7. Operate on the received touch data as needed using application code.
  8. Stop receiving the touch data using the sf_touch_panel_v2_api_t::stop API function.
  9. Close the module using the sf_touch_panel_v2_api_t::close API function (if required).

These common steps are illustrated in a typical operational flow in the following figure:

touch_panel_v2_TA.png
Flow Diagram of a Typical Touch Panel V2 Framework Module Application