The CSDADC middleware is the CYPRESS™ ADC solution, which uses the CSD HW block.The CSD HW block is mainly used to implement the touch sense applications and proximity sensors (refer to the CAPSENSE™ Middleware API Reference Guide), but can also be used to implement the ADC, which is especially useful for the devices that do not include another hardware option to implement the ADC. CSDADC provides the following measurement capabilities:
The listed capabilities are making the CSDADC useful for a variety of applications, including home appliances, automotive, IoT, and industrial applications. The CSDADC middleware can use the same CSD HW block with other CSD-based middleware (CAPSENSE™, CSDIDAC, etc) in the time-multiplexed manner.
Features:
Include cy_csdadc.h to get access to all functions and other declarations in this library. The Quick Start Guide is offered in this API Reference Guide.
Refer to the Supported Software and Tools for the compatibility information.
Refer to the Changelog for the differences between the Middleware versions.
The Changelog also describes the impact of the changes to your code.
The CSD HW block enables multiple sensing capabilities on PSoC™ devices including the self-cap and mutual-cap capacitive touch-sensing solutions, a 10-bit ADC, IDAC, and Comparator. The CSD driver is a low-level peripheral driver, a wrapper to manage access to the CSD HW block. Any middleware access to the CSD HW block happens through the CSD Driver.
The CSD HW block can support only one function at a time. However, all supported functionality (like CAPSENSE™, CSDADC, etc.) can be time-multiplexed in a design. I.e. you can save the existing state of the CAPSENSE™ middleware, restore the state of the CSDADC middleware, perform ADC measurements, and then switch back to the CAPSENSE™ functionality. For more details and code examples, refer to the description of the Cy_CSDADC_Save() and Cy_CSDADC_Restore() functions.
This section describes only the CSDADC middleware. Refer to the corresponding sections for documentation of other middleware supported by the CSD HW block. The CSDADC library is designed to use with the CSD driver. The application program does not need to interact with the CSD driver and/or other drivers such as GPIO or SysClk directly. All of that is configured and managed by the middleware.
The CSDADC API is described in the following sections:
CYPRESS™ CSDADC middleware can be used in various Development Environments such as ModusToolbox™, MBED, etc. Refer to the Supported Software and Tools. The quickest way to get started is using the Code Examples. Infineon Technologies continuously extends their portfolio of code examples at the Infineon Technologies and at the Infineon Technologies GitHub.
This quick start guide assumes that the environment is configured to use PSoC™ 6 (psoc6pdl) or PSoC™ 4 (psoc4pdl) Peripheral Driver Library (depending on the platform used). Also, include the Peripheral Driver Library into the project.
The following steps are required to set up the CSDADC and to run the measurement:
PSoC™ 6 | PSoC™ 4 | |
---|---|---|
const cy_stc_sysint_t CSDADC_ISR_cfg = { .intrSrc = csd_interrupt_IRQn, /* The interrupt source is the CSD interrupt */ .intrPriority = 7u, /* The interrupt priority is 7 */ }; | const cy_stc_sysint_t CSDADC_ISR_cfg = { .intrSrc = csd_interrupt_IRQn, /* The interrupt source is the CSD interrupt */ .intrPriority = 3u, /* The interrupt priority is 3 */ }; |
The CSDADC middleware operates on the top of the CSD Driver included in the PSoC™ 6 (or PSoC™ 4) Peripheral Driver Library (psoc6pdl/psoc4pdl). Refer to the "CSD (CAPSENSE™ Sigma Delta)" section of the PSoC™ 6 Peripheral Driver Library (psoc6pdl) (or PSoC™ 4 Peripheral Driver Library (psoc4pdl)) API Reference Manual. This Configuration Considerations section guides how to set up the CSDADC middleware for the operation with the following parameters:
Channel | PSoC™ 6 | PSoC™ 4 |
---|---|---|
0 | P6[2] | P0[2] |
1 | P6[3] | P0[3] |
There are two approaches to the CSDADC Middleware configuration:
Generation of the initialization code using the ModusToolbox™ Device Configurator Tool which is part of the ModusToolbox™, greatly simplifies the PSoC™ configuration. The ModusToolbox™ Device Configurator Tool provides the user interface to set up and automatically generate the initialization code (including analog routing) and configuration structures.
Manual implementation of the initialization code (including analog routing) and configuration structures is recommended for expert Users only. This will include the code for the following settings which in case of the Device Configurator usage are generated automatically based upon the settings entered in its UI:
The following steps are required to generate the initialization code using the ModusToolbox™ Device Configurator Tool :
Now, all required CSDADC initialization code and configuration prerequisites will be generated:
The generated code will be available under the GeneratedSource folder.
Refer to Quick Start Guide section for the application layer code required to set up CSDADC and run the measurement.
The steps required to implement the initialization code manually:
PSoC™ 6 | PSoC™ 4 | |
---|---|---|
{ {GPIO_PRT6, 2u}, /* Assign Channel-0 to P6[2] */ {GPIO_PRT6, 3u} /* Assign Channel-1 to P6[3] */ }; | { {GPIO_PRT0, 2u}, /* Assign Channel-0 to P0[2] */ {GPIO_PRT0, 3u} /* Assign Channel-1 to P0[3] */ }; |
Set the configuration of the HSIOM_AMUX_SPLIT_CTL switches to route signal from input pins configured as the CSDADC channels to the CSD HW block. The AMUX_SPLIT_CTL[4] switches are closed to connect port P6 with the CSD HW block (for the PSoC™ 6 platform). Refer to the Technical Reference Manual (TRM) for more information regarding the analog interconnection. See the code example below and refer to the main() routine code snippet in Quick Start Guide.
Refer to Quick Start Guide section for the application layer code required to set up CSDADC and run the measurement.
This section provides descriptions and links to additional documentation for some specific CSDADC use cases.
The CSD HW block and CSDADC middleware can operate in CPU active and CPU sleep power modes. It is also possible to switch between low power and ultra low power system modes. The CSD HW block interrupt can wake-up the CPU from sleep mode. In System Deep Sleep and Hibernate power modes, the CSD HW block is powered off and CSDADC conversions are not performed. When the device wakes up from CPU/System Deep Sleep, the CSD HW block resumes operation without re-initialization and the CSDADC conversions can be continued with configuration set before CPU/System Deep Sleep transition. When the device wakes up from System Hibernate power mode, the CSD HW block does not retain configuration and CSDADC requires re-initialization. If the user performs communication to transmit CSDADC results via I2C, UART etc., transitions to CPU sleep, Deep Sleep or Hibernate modes are performed with recommendations both for CSDADC and communications' drivers/middleware.
Refer to the Cy_CSDADC_DeepSleepCallback() function description and to the SysPm (System Power Management) driver documentation for the low power design considerations.
Sleep mode
The CSD HW block can operate in the CPU sleep mode. The user can start CSDADC and move the CPU into Sleep mode. After every conversion, the CPU is woken-up by the CSD interrupt, the results are read, and the CPU goes to sleep again to reduce a power consumption. After the whole conversion cycle completes, the user can read the results, process them, and start a new cycle. Then, the user configures the CSDADC middleware as described in Configuration Considerations, and updates the main() routine with the following code:
Deep Sleep mode
To use the CSDADC middleware in the CPU/System Deep Sleep mode, the user configures a wake-up source (e.g. a pin, WDT, LPC or any other entities that are active in CPU/System Deep Sleep mode), configures the CSDADC middleware as described in Configuration Considerations, configures CSDADC and other drivers' and middleware's (if presented) Deep Sleep Callback structures, registers callbacks, and updates the main() routine with the following code:
Refer to the Cy_CSDADC_Calibrate() function description for the CSDADC calibration considerations. Cy_CSDADC_Enable() performs first-time calibration at the start of CSDADC operation. Periodical re-calibrations are required to keep the measurement results accurate.
Refer to the Cy_CSDADC_Save() and Cy_CSDADC_Restore() functions descriptions to implement the time-multiplexing operation of CSDADC and CAPSENSE™ by using a common CSD HW block.
This version of the CSDADC Middleware was validated for the compatibility with the following Software and Tools:
Software and Tools | Version |
---|---|
ModusToolbox™ Software Environment | 2.4.0 |
- ModusToolbox™ Device Configurator | 3.10 |
- ModusToolbox™ CSD Personality for PSoC™ 6 in Device Configurator | 2.0 |
- ModusToolbox™ CSD Personality for PSoC™ 4 in Device Configurator | 1.1 |
PSoC™ 6 Peripheral Driver Library (PDL) | 2.4.0 |
PSoC™ 4 Peripheral Driver Library (PDL) | 1.6.0 |
GCC Compiler | 10.3.1 |
IAR Compiler | 8.42.1 |
Arm Compiler 6 | 6.13 |
MBED OS | 5.13.1 |
FreeRTOS | 10.0.1 |
Consult Changelog to learn about the design impact of the newer version. Set up your environment in accordance with Supported Software and Tools. You might need to re-generate the configuration structures for either the device initialization code or the middleware initialization code.
Ensure:
The Cy_CSDADC library has the following specific deviations:
MISRA Rule | Rule Class (Required/Advisory) | Rule Description | Description of Deviation(s) |
---|---|---|---|
2.5 | A | A project should not contain unused macro declarations. | The middleware library provides an API to the hardware. The macro is part of the API, which is defined for the application-level only. |
4.8 | A | If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden. | The middleware library uses data structures defined in the PDL library. |
4.9 | A | A function should be used in preference to a function-like macro where they are interchangeable. | Deviated since function-like macros are used to allow more efficient code. |
5.8 | R | Identifiers that define objects or functions with external linkage shall be unique. | During the code analysis, the same source files are compiled multiple times with device-specific options. All object and function identifiers are unique for each specific run. |
5.9 | R | Identifiers that define objects or functions with internal linkage should be unique. | During the code analysis, the same source files are compiled multiple times with device-specific options. All object and function identifiers are unique for each specific run. |
8.7 | A | Functions and objects should not be defined with external linkage if they are referenced in only one translation unit. | During the code analysis, the same source files are compiled multiple times with device-specific options. All object and function identifiers are unique for each specific run. |
8.13 | A | A pointer should point to a const-qualified type whenever possible | This violation appears in the Deep Sleep callback function only. A function argument cannot be const because of the conflict with Cy_SysPmCallback typedef in the cy_syspm.h file. |
11.5 | A | A conversion should not be performed from pointer to void into pointer to object. | The cast from a void pointer to an object pointer does not have any unintended effect, as it is a consequence of the definition of a structure based on the function pointers. |
This section lists the known problems with the CSDADC middleware:
Cypress ID | Known Issue | Workaround |
---|---|---|
319100 | The GPIO simultaneous operation with unrestricted strength and frequency creates noise that can affect the CSDADC operation. | Refer to the errata section of the device datasheet for details. PSoC™ 63 with BLE Datasheet Programmable System-on-Chip |
Version | Changes | Reason for Change |
---|---|---|
2.10 | Added the support of PSoC™ 4 CAPSENSE™ Forth Generation devices | Devices support |
Minor documentation update | Documentation cleanup | |
2.0 | Made public the CY_CSDADC_NO_CHANNEL macro | Defect fixing |
Changed the Cy_CSDADC_InterruptHandler() function prototype. Added function argument: const CSD_Type * base | User experience improvement | |
Changed the Cy_CSDADC_StartConvert() function prototype. Changed the mode argument type from uint32_t to cy_en_csdadc_conversion_mode_t | User experience improvement | |
Renamed function Cy_CSDADC_ConversionStatus() to Cy_CSDADC_GetConversionStatus() | User experience improvement | |
The CSDADC MW sources are enclosed with the conditional compilation to ensure a successful compilation for non-CSDADC-capable devices | A compilation for non-CSDADC-capable devices | |
After conversion, the ADC channel is still connected to the CSD HW block, and disconnected only prior to new channel connection | Defect fixing | |
Changed the cy_stc_csdadc_config_t structure: the ptrPin field is replaced with the ptrPinList field. It is a pointer to the array of the size determined by the numChannels field of this structure versus the ptrPin field that was an array of pointers with fixed CY_CSDADC_MAX_CHAN_NUM size. | User experience improvement | |
Added the cpuClk field to the cy_stc_csdadc_config_t structure. Changed the software watchdog counter calculation in the Cy_CSDADC_Restore() function where cpuClk is used instead of periClk. | Defect fixing | |
1.0.1 | Improvements to documentation | User experience improvement |
Forbidden the usage of the CSDADC for non-CSDADC-capable devices in module.mk file | A Compilation for non-CSDADC-capable devices | |
1.0 | The initial version |
For more information, refer to the following documents: