CTSU Touch Button Program
Running Requirements
In a bare-metal system, the CTSU APIs should be called in a loop at certain time intervals.
In the QE for Cap Touch tool-generated Cap Touch Sample Code
• Use while(true) to implement a loop that calls CTSU APIs
• Use R_BSP_SoftwareDelay() to implement an appropriate timing interval
In an embedded multi-tasking system, the CTSU APIs also need to be run in a loop at certain time intervals.
• The relevant ISRs and APIs for CTSU operation can be directly ported to the multi-tasking system.
• The CapTouch Sample Code generated by the QE for Cap Touch tool needs to be rewritten.
Basic Considerations When Porting Embedded Operating Systems
Basic content to consider when porting the CTSU driver and application to an RTOS system:
When porting the CTSU low-level driver and application to an RTOS system, the following basic considerations are generally required:
• Setting of SysTick in RTOS
• Use of RTOS delay functions
• Setting of MCU interrupt priority and RTOS task priority
• Rewriting of the CTSU CapTouch Sample Code generated by the QE for Cap Touch tool
Setting of SysTick
For example, in a FreeRTOS project created using e2 studio, the default setting for SysTick is 1ms.
Use of RTOS Delay Functions
For example, in FreeRTOS, the delay functions vTaskDelay() and vTaskDelayUntil()
• FreeRTOS provides two system delay functions: relative delay function vTaskDelay() and absolute delay vTaskDelayUntil().
• These two delay functions differ from self-implemented delay functions; once called, the current task immediately enters a blocked state, whereas a self-written delay function (implemented as a software delay using for loops, etc.) is treated as an active task and continues to execute.
• Relative delay means that each delay starts from the execution function vTaskDelay() and ends after the specified delay time;
The parameter xTicksToDelay of the vTaskDelay() function indicates the number of system tick clock cycles to delay (SysTick).
void vTaskDelay( const TickType_t xTicksToDelay )
• Absolute delay means that every specified time interval, the task calling vTaskDelayUntil() is executed. In other words: the task executes at a fixed frequency.
Setting of MCU Interrupt Priority and RTOS Task Priority
For example, consider the task priority in FreeRTOS.
The highest task priority in FreeRTOS is configured through the configMAX_PRIORITIES in the FreeRTOSConfig.h file, and the user can actually use a priority range from 0 to configMAX_PRIORITIES – 1. It is recommended that users set the maximum value of the configMAX_PRIORITIES macro definition to not exceed 32. The larger the configuration, the more memory space is required based on actual application configuration.
In a FreeRTOS project created using e2 studio, the default configMAX_PRIORITIES is 5.
Difference Between MCU Interrupt Priority and FreeRTOS Task Priority
Simply put, there is no relationship between the two; regardless of the interrupt priority level, the MCU interrupt priority is always higher than any FreeRTOS task priority, meaning that during execution, if an MCU interrupt occurs, the interrupt service routine starts executing.
The lower the numerical value of the MCU interrupt priority, the higher the priority; whereas for FreeRTOS, the lower the task priority numerical value, the lower the priority.
MCU Interrupt Priority and RTOS Task Priority
Common priority allocation schemes:
• IRQ tasks: IRQ tasks are tasks triggered by interrupt service routines, having the highest priority among all tasks.
• High-priority background tasks: such as key detection, touch detection, USB message processing.
• Low-priority time-scheduled tasks: such as LCD display, LED digital tube display.
IRQ tasks and high-priority tasks must be set as blocking (calling message wait or delay functions), only then can high-priority tasks release CPU usage rights, allowing low-priority tasks the opportunity to execute.
CTSU CapTouch touch button tasks are recommended to be configured as high-priority tasks and set as blocking.
Rewriting the CTSU CapTouch Sample Code
The default CTSU CapTouch Sample Code
• The QE for Cap Touch tool can generate the default CapTouch Sample Code
• Sample Code uses while(1) to wait indefinitely for measurement completion, and uses R_BSP_SoftwareDelay() to implement a loop call to CTSU APIs approximately every 20ms.
• CapTouch touch buttons do not have high real-time requirements, but many parameters related to CTSU operation are related to the timing interval of loop calls, thus greatly determining the sensitivity of the touch buttons.
For example, Drift Correction Interval
The setting value in the figure below is 255, the actual value is 255 x API timing call interval, the positive noise filter when the button is pressed and the negative noise filter when the button is released are also like this.
Therefore, users need to reasonably rewrite the default CTSU CapTouch Sample Code according to the system’s requirements for Cap Touch touch button real-time performance and sensitivity.
Rewriting the Default CTSU CapTouch Sample Code
For example, using FreeRTOS
• Reasonably set the priority of Cap Touch Thread, for example, set it to the highest priority.
• Rewrite the API call error handling
while(true){} changed to return
• Rewrite the delay R_BSP_SoftwareDelay() to vTaskDelay()
• Rewrite Qe_touch_main() and CTSU_FN_ISR measurement completion interrupt callback functions
Increase OS Timer and Semaphore, periodically start the CTSU measurement, releasing CPU time while waiting for the measurement completion interrupt, at this point, while(0 == g_qe_touch_flag) and R_BSP_SoftwareDelay() / vTaskDelay() can be canceled.
Use RTOS analysis tools to analyze
the runtime sequence of the CapTouch thread
Purpose: Analyze the operational relationship between the CapTouch thread and user threads in the entire system.
Based on the number of touch buttons:
• Ensure that the CapTouch thread runs in a loop at appropriate time intervals.
• Ensure that the key processing phase of the CapTouch thread is not preempted by other user threads.
• Ensure that during the touch button measurement phase, other user threads can run.
Some RTOS-supported analysis tools
FreeRTOS: SEGGER Systemviewer
Azure ThreadX: TraceX
RT-Thread: SEGGER Systemviewer
Using SEGGER SystemView to analyze the basic operation process of the CapTouch touch button.
SEGGER SystemViewer Application Example
Basic operation process of CapTouch touch button.
———— END ————
Share an advanced AI/ML development tool Reality AI Tools Explorer
Is the end of MCU competition MPU?
Tutorial on Porting CoreMark Source Code Based on RA Microcontroller