Skip navigation
Home > All Places > PSoC 6 MCU Community > Blog


Posted by MichiyukiY_91 Mar 24, 2017



Thought I’d give a quick overview of the General Purpose Input Output (GPIO) pins available on PSoC 6. In general they share the high level of configuration and routing flexibility found in PSoC 4 MCUs. The key features are:

  • Several 8-pin ports include Smart_IO logic, which can be used to perform Boolean operations on signals going to, and coming from pins. Can avoid off chip logic and allow device to enter low power modes by offloading CPU processing.
  • Eight drive strength modes
    • Analog input mode (input and output buffers disabled)
    • Digital Input only
    • Weak pull-up with strong pull-down
    • Strong pull-up with weak pull-down
    • Open drain with strong pull-down
    • Open drain with strong pull-up
    • Strong pull-up with strong pull-down
    • Weak pull-up with weak pull-down
  • Hold mode for latching current pin state state in Hibernate mode minimizing system power requirements.
  • Selectable slew rates for dV/dt-related noise control to improve EMI and assist with regulatory compliance testing.
  • A multiplexing network known as a high-speed I/O matrix (HSIOM) is used to multiplex up to 32 analog and digital signals that connect to each I/O pin. Route options include routing peripheral signals to multiple pins and routing Digital System Interconnect (DSI) signals to almost any pin. Routing flexibility simplifies PCB board layout and greatly reduces effort spent allocating pin resources.
  • Every I/O pin can generate an interrupt if enabled and each I/O port has an interrupt request (IRQ) and interrupt service routine (ISR) vector associated with it. Improved pin interrupt functionality and register access makes pin ISR configuration and interaction easy.
  • Standard GPIO pins are rated up to 3.3V.
  • Four GPIO pins are capable of overvoltage tolerant (OVT) operation where the input voltage may be higher than VDD. These may be used for use cases like I2C to allow powering the chip off while maintaining physical connection to an operating I2C bus without affecting its functionality.


Happy reading!

The Peripheral Driver Library v3, for PSoC 6, is more than a driver library. It’s a complete software development kit. I talked about what the PDL is in Software Enablement for PSoC 6 – What to Expect. In this article I want to give you some insight into the very high level design of the PDL drivers. I’ve seen a lot of code in my time, and the PDL is really well designed.


Although this article is about the PDL, just as a teaser, in a coming post or two I'll talk about how PSoC Creator and PDL are integrated. They work together seamlessly. But I get ahead of myself. Back to PSoC 6 and PDL.


The underlying hardware capabilities of the PSoC 6 present unique challenges. For one thing (and it’s a big thing), PSoC 6 is a dual-core architecture, with both a Cortex® M4 and a Cortex M0+ device. Among the many complications you might have to deal with are:

  • Different cores with different instruction sets
  • Drivers for each core
  • Inter-processor communication
  • Sharing resources between the cores


The PDL makes a lot of the complexity go away, from a software perspective. We’re doing our best to make this as easy as possible.


The first big design choice is that the cores use the same register and memory maps for all peripherals. The PDL source code takes advantage of that choice. With very few exceptions, either core can use any peripheral driver. For example, if you want to implement a real-time clock in your design, you create a single RTC driver, not separate CM4 and CM0+ RTC drivers. Write once, use for either core.


It gets better.


The set of available peripherals varies per device. In some cases there are multiple instances of the same peripheral; for example, there are multiple Serial Communication Blocks (SCB). On top of that, each peripheral instance may itself operate on multiple instances of user data.


Imagine if you will (because this is in fact how it works), a platform where you create a peripheral driver used by either or both cores. Where you configure and customize each peripheral. Where you have multiple instances of peripherals, each configured differently. Where each of those peripherals can operate on multiple instances of data. Imagine multiple SCBs, each operating on multiple data buffers, with status and indices into each buffer. All of this happening in a dual-core environment with all the corresponding issues involving potential resource and timing conflicts.


There are many, many ways to make this complicated. The PDL is designed to make it easy. The PDL implements a simple, consistent design based on three fundamental concepts.


Base Hardware Address: At the hardware level, peripheral features and behavior are controlled by registers. Each peripheral instance has its own base hardware address that points to the registers for that instance. The PDL uses this base address to access the necessary registers. Constants for each base address are defined in device-specific header files. It’s easy to find what you need.


Configuration Structure: Each peripheral instance is configurable. You modify values in a PDL configuration structure to change behavior to fit your requirements. When you initialize, enable and use a peripheral, the PDL manages register access using the base hardware address.


Context Structure: A single peripheral instance (however configured) may work on multiple instances of data. For example, an SCB configured as a UART operates on data buffers, and maintains status information about those buffers. The peripheral does not allocate this memory. The PDL defines the necessary data structure on which the peripheral operates. You allocate the structure in memory and provide it to the peripheral.


Many PDL API function calls require a parameter representing one or more of these three concepts. The precise details vary per peripheral, but the design is consistent throughout the PDL. When you look at the actual wording of function prototypes, you will discover that not only is the design consistent, so are the parameter names. The base hardware address is always called base. The configuration structure is always called config.


It’s a little thing, name consistency. Someone new to PDL 3.0 may not even notice. But it has a big impact. Once you get it, you’ve got it! There is no need to figure out, ok, so how is this driver put together? Of course each driver is functionally different, with its own API. But each uses the same parameters for the same things. And that will make your life as a developer a lot easier.


Interrupts in PSoC 6

Posted by MichiyukiY_91 Mar 20, 2017

Hello out there!

This is an update on PSoC 6 interrupts and its features/capabilities. Feel free to read through and leave a comment!


  • PSoC 6 BLE has 139 device interrupt sources from various peripherals such as TCPWM, GPIO, IPC, UDB, SCB, RTC, MCWDT, DMA and many more. These can be connected to either of the two cores - the CM4 which has 240 NVIC lines or the CM0+ which has 32 NVIC lines. Since CM0+ has lesser number of NVIC interrupt lines than the device interrupt sources, a 240:1 multiplexer structure is present on each of the 32 lines to select one of the 139 device interrupt sources.
  • There are 33 interrupt sources that are capable of waking up the core from deepsleep mode. CM4  NVIC lines 0 to 32 and CM0+ NVIC lines 0 to 7 support these deepsleep capable device interrupt sources. 
  • CM4 supports configurable priority from 0 to 7 and CM0+ supports configurable priority from 1 to 3. Priority 0 in CM0+ is reserved for system calls. CM0+ has 32 NVIC lines out of which 4 interrupts are reserved for IPC system calls, IPC Crypto, and IPC pipe interrupts.


Happy reading!

As a developer, working on new hardware is pretty common. The product team says “We’re going to use X in the next version.” About the first question on your mind when this happens is, “How do I write software for this platform?”


Let me give you a quick peek into what’s coming for PSoC 6. It’s pretty sweet. It is called the Peripheral Driver Library (PDL), The version for PSoC 6 is version 3.0. The PDL  is much more than just a driver library. It is actually a complete software development kit. It will look something like this:



The PDL includes:

  • All the device-specific header files and startup code, for every PSoC 6 part and package
  • A driver library provided in source code that you can easily configure for customized drivers
  • Fully-integrated middleware, like the Cypress BLE stack
  • FreeRTOS


In short, it will have everything you need to fill the gap between your application and the hardware. It supports every functional block on the device. The code for each function in each driver is fully documented. The same library works for both the CM0+ and the CM4 cores on the PSoC 6.


PDL 3.0 for PSoC 6 is entirely new, just like the PSoC 6 family, and a lot more comprehensive than earlier versions of the PDL. PDL 3.0 will support PSoC 6 only. I am personally up to my eyeballs helping to get this ready for you. And that’s pretty exciting.


If you've got a topic you'd like to see discussed, about the PDL or software development for PSoC 6, let me know in the comments. I'll see what I can do. For now, I recognize this is all theoretical, until you can get your hands on the actual software. Stay tuned, there’s a lot of neat stuff coming.