 |
PSOC E8XXGP Device Support Library
|
|
PSOC E8XXGP Device Support Library
|
The system libraries provide APIs that can be called in the user application to handle the timing, logical checking or register.
The functions and other declarations used in this driver are in cy_syslib.h. You can include cy_pdl.h to get access to all functions and declarations in the PDL.
The SysLib driver contains a set of different system functions. These functions can be called in the application routine. Major features of the system library:
Assertion Usage
Use the CY_ASSERT() macro to check expressions that must be true if the program is running correctly. It is a convenient way to insert sanity checks. The CY_ASSERT() macro is defined in the cy_utils.h file, which is part of the Cypress Core Library (core-lib). The macro behavior is as follows: if the expression passed to the macro is false, the CPU is halted.
Starting from the driver version 2.50, the CY_ASSERT macro was moved to the Cypress Core Library (core-lib). Also, the CY_ASSERT implementation was changed not to call Cy_SysLib_AssertFailed() function, so user application that relied on that should take this change into account.
The PDL source code uses this assert mechanism extensively. It is recommended that you enable asserts when debugging firmware.
Assertion Classes and Levels
The Cypress Core Library defines three assert classes, which correspond to different kinds of parameters. There is a corresponding assert "level" for each class.
| Class Macro | Level Macro | Type of check |
|---|---|---|
| CY_ASSERT_CLASS_1 | CY_ASSERT_L1 | A parameter that could change between different PSoC devices (e.g. the number of clock paths) |
| CY_ASSERT_CLASS_2 | CY_ASSERT_L2 | A parameter that has fixed limits such as a counter period |
| CY_ASSERT_CLASS_3 | CY_ASSERT_L3 | A parameter that is an enum constant |
Firmware defines which ASSERT class is enabled by defining CY_ASSERT_LEVEL. This is a compiler command line argument, similar to how the DEBUG / NDEBUG macro is passed.
Enabling any class also enables any lower-numbered class. CY_ASSERT_CLASS_3 is the default level, and it enables asserts for all three classes. The following example shows the command-line option to enable all the assert levels:
After CY_ASSERT_LEVEL is defined, firmware can use one of the three level macros to make an assertion. For example, if the parameter can vary between devices, firmware uses the L1 macro.
If the parameter has bounds, firmware uses L2.
If the parameter is an enum, firmware uses L3.
Each check uses the appropriate level macro for the kind of parameter being checked. If a particular assert class/level is not enabled, then the assert does nothing.
Delay Functions
Delay functions are supported with different flavors of delays and are implemented by executing known instructions in a loop considering the CPU cycles consumed by these instructions to execute. The loop count is calculated based on the amount of delay required. Cycles taken for the execution of instructions has a direct impact on the accuracy of the delay. For the best accuracy of delay, these functions need to be executed from the single cycle memory. Devices with CM7, CM33, or CM55 processor have I-Cache which ensures the accuracy of the delay as the loop executes from the I-Cache. However, for the devices without I-Cache, user needs to move these functions to faster memory, such as SRAM using appropriate memory section directive listed in the cy_syslib.h file. On devices with CM33 Core, user must ensure that the code is executed using C-BUS. This ensures the execution of the code happens through I-Cache.
Refer to the technical reference manual (TRM).
API Reference | |
| Macros | |
| Functions | |
| Data Structures | |
| Enumerated Types | |