Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Embedded and Microcontrollers blog PSoC 6 Components and PDL Drivers
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • cypress
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

PSoC 6 Components and PDL Drivers

Mark Saunders
Mark Saunders
June 16, 2017

[re-printed from Cypress Developer Community by Jim Trudeau - to learn more about PSoC 6 join the Cypress PSoC 6 EAP Community]

In this article I want to go a bit deeper into the difference between using a PSoC Creator component, and using the PDL directly. Most PSoC 6 peripherals have a corresponding PSoC Creator Component. You drag the Component into your design and configure it inside PSoC Creator. Based on your design and configuration, PSoC Creator generates the code required to configure the peripheral. It generates an API for that specific component. All of this is unchanged for PSoC 6 and the PDL.

Here's what's new. The PSoC 6 Component is built on top of the PDL.

In the past, the Component API was the only option. For PSoC 6, the Component API uses the PDL. PDL 3.0 is a separate entity. That means you have a choice. You can use the Component API, or you can use the PDL API directly. The PDL is designed to work with, or without, PSoC Creator.

Here’s an example. Your PSoC Creator design might include a PWM component, which you could name “MyPWM.” You would at some point write code modify the compare value in the PWM to change the duty cycle. Here’s the Component API code that sets the compare value for that Component.

Notice that the generated Component API calls the PDL API. Let’s start with the PDL API call. This function has three parameters. The first is the base hardware address for the peripheral. (Read PDL 3.0 - Designed for Flexibility to learn about base hardware addresses.) Because the PWM actually has multiple counters, you also specify which counter to use. And of course there is the actual compare value.

By contrast, the Component API call has only one simple parameter: the value. That’s because PSoC Creator “knows” which base hardware address to use, and which counter, based on the system design and pin assignments you set up in the tool.

These two APIs, Component and PDL, are fully compatible. You can mix and match as you see fit. The Component API is often simpler, but adds a level of indirection (a function call to make a function call). In many cases the overhead is trivial or non-existent, and might even be optimized away. In other cases it might be more significant.

The table summarizes some of the key differences.

There is absolutely no requirement to use PSoC Creator. If you do not use PSoC Creator, then you make PDL API function calls directly, providing all parameters. You get the Component API whenever you use PSoC Creator to generate code. You can use it even if you import the code into your preferred IDE.

One neat thing about the Component API in the generated code is that it is often just a wrapper on top of the PDL API. Even if you don’t want to use PSoC Creator as a production tool, you can use it as a learning tool. You will be able to explore the generated code to see how it makes PDL function calls, and learn how to use the PDL effectively.

Anonymous
Embedded and Microcontrollers blog
  • Adapting Kubernetes for high-performance IoT Edge deployments

    Alexandre Peixoto Ferreira
    Alexandre Peixoto Ferreira
    In this blog post, we address heterogeneity in IoT edge deployments using Kubernetes.
    • August 21, 2024
  • Evolving Edge Computing and Harnessing Heterogeneity

    Alexandre Peixoto Ferreira
    Alexandre Peixoto Ferreira
    This blog post identifies heterogeneity as an opportunity to create better edge computing systems.
    • August 21, 2024
  • Demonstrating a Hybrid Runtime for Containerized Applications in High-Performance IoT Edge

    Chris Adeniyi-Jones
    Chris Adeniyi-Jones
    In this blog post, we show how a hybrid runtime and k3s can be used to deploy an application onto an edge platform that includes an embedded processor.
    • August 21, 2024