PSoC Creator 4.2 and Peripheral Driver Library 3.0.1 | Cypress Semiconductor
PSoC Creator 4.2 and Peripheral Driver Library 3.0.1
With all the fuss and excitement over Embedded World last month I forgot to tell you about the production release of PSoC Creator 4.2. If you have not already been prompted by the update manager, you can download and install the software from the Cypress web site.
As you must know by now, the big new thing is PSoC 6 and the PSoC 6 BLE Pioneer kit. Some of the PSoC 6 devices, specifically the PSoC 63 line, support Bluetooth Low Energy (BLE) and enable access to a secondary processor core, an Arm Cortex M0+. This core enables extremely low power operation in Bluetooth applications by executing the timing-sensitive lower layers of the Bluetooth stack and only interrupting/waking the Cortex-M4 application processor when computation is necessary. There is a little more information about the new features in the Start Page under "New in 4.2".
Any PSoC 6 user will also notice a change in our component firmware. Rather than generating the API for every instance of a component, we now ship a peripheral driver library (PDL). Using a driver instead of generating functions for every component instance saves a lot of memory space because there is only one copy of the code required in flash. It is also much more easy to use with third-party IDEs, where more of the device setup is done in firmware, and fewer files need to be checked into revision control systems.
Note: The PDL API is documented in HTML format, rather than in the PDF component datasheet, which can be accessed by right-clicking the component instance and selecting "Open PDL Documentation...".
The main change with PDL is that instead of calling a function that has hard-coded references to the hardware blocks you pass the address of the hardware block into the function. PSoC Creator generates macros and a configuration structure, based on your customizer settings for the instance, so the arguments are easy to figure out once you get the hang of things. Taking an SCB component, configured as a UART (called "MyUART") as an example, here is the code you need to do simple serial I/O.
Cy_SCB_UART_Init( MyUART_HW, &MyUART_config, &MyUART_context );
Cy_SCB_UART_Enable( MyUART_HW );
ch = Cy_SCB_UART_Get( MyUART_HW );
if( isalpha( ch ) )
Cy_SCB_UART_Put( MyUART_HW, toupper( ch ) );
For the most part, the API is very similar to the instance-based method, except you need to pass a pointer to the block you are using. This is the macro "MyUART_HW", which is generated by PSoC Creator in MyUART.h. This argument always comes first in the list. Once you get used to the style, it this is no harder to write "Cy_SCB_UART_Get( MyUART_HW )" than the traditional 'MyUART_UartGetChar()".
Another change is that you no longer call a _Start function. Instead you call Cy_SCB_UART_Init() and Cy_SCB_UART_Enable(). This lets you separate initialization of the component from actually starting it from running. In some cases you may also want to add more initialization code, for example to enable interrupts or set a PWM trigger mode, and I'll expand on that in a future post. For the UART the _Init() function takes two extra arguments - the configuration and the context - both of which are also generated for you by PSoC Creator. The context is just a little piece of memory that the driver needs to keep track of the component state. It saves the driver from having to use malloc(), which is not always a good idea in an embedded system, and you only ever need to use it in the _Init() function call. The configuration structure is a pointer to a C struct (cy_stc_scb_uart_config_t *) that is generated from your customizer settings. If you look in MyUART.c you will see the code and recognize the parameters. You can locate this struct in flash, to minimize RAM usage, or in RAM if you want to modify the settings in firmware by using the "Config Dtata in Flash" setting from the customizer Built-In tab.
This may seem like a big change but it is very much a normal driver API style, and offers several benefits. The code size is reduced. Configuration is much more in the control of the firmware developer, which is really useful for people who do not develop applications in PSoC Creator. You can also use PDL to write code that is independent of the target communication block. I shall be using this in RTOS-based applications where a UART task gets started with a pointer to the SCB hardware. The task can be used with any configured UART just by changing the argument that gets passed in at start-up. It is also possible, and simple, to swap the UART used in the middle of a program. I'll be posting some more examples of PDL-based coding over the next few weeks to give you a more complete overview of how to use it.