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

PSoC 6 MCU Community

5 Posts authored by: JimT_21
JimT_21

IDEs for PSoC 6 Development

Posted by JimT_21 Apr 18, 2017

Here’s the good news. You can use just about any IDE to create firmware for PSoC 6 devices. How easy or hard it will be may vary, but the choice is yours. Read Software Development Models for PSoC 6 to learn more. I discuss PSoC Creator relative to PSoC 6 and the Peripheral Driver Library (PDL) in that article. The PDL is designed to be used with any IDE.

 

Let me group third-party IDEs into two categories: those that are “supported” and those that aren’t. You can use any IDE effectively, even "unsupported" IDEs.

 

Supported IDEs

The list of supported IDEs is subject to change, but as I write this the plans include:

  • IAR Embedded Workbench
  • Keil µVision
  • Atollic TrueStudio
  • iSystem WinIDEA
  • Command-line tools (make file)

 

For a supported IDE, you get some extra goodies to make life easier. These include

  • A template project for each core
  • Project build settings set for the particular device
  • IDE-specific files like startup code, linker files, or a flash loader
  • A defined export/import process for generated files

 

The export/import process varies significantly per IDE, so once you get the PSoC 6 platform you’ll want to read the PSoC Creator help files on how to import the code. You are not required to use the export/import process, you can always just add files from the Generated_Sources folder to your IDE’s project file. And that takes us to the "other" IDEs.

 

Other IDEs

So what if your preferred IDE isn’t on the “supported” list? Well, there is no formal export/import process. You manually add the PSoC Creator generated files to your IDE's project. You don’t have a template project, so you have to set up your own project completely. But it's your IDE, and you're familiar with what options are required and how to set them. You may need to develop some IDE-specific code, like a linker command file. However, you can examine those provided with the PDL to see how it’s done.

 

In all cases, whether it is a “supported” IDE or not, you can use PSoC Creator generated code if you want, or develop entirely without PSoC Creator. PSoC 6 Components and PDL Drivers talks a little bit about the trade-offs. I am personally very much a believer in code generation tools. Your mileage may vary.

 

IDEs are highly variable. Some have compilers that do a better job optimizing code. Some support dual-core debugging, and some do not. It’s quite likely that you have your favorite. I learned long ago to not argue over matters of taste or preference, like which IDE is best. I have a suspicion that in my near future I'll be writing some formal detailed collateral on how to use PSoC Creator generated code in your IDE for PSoC 6 development.I'd like to hear from you on whether you think that's a worthwhile bit of information.

 

What really matters is: can you choose the IDE you want? The answer to that is simple. Yes.

In this article I want to go a bit deeper into the difference between using a PSoC Creator component, and using the PDL directly. I talked about development models for PSoC 6 here. (You can find out what the PDL is here; and how it is designed, here.)

 

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.

PDL Component.png

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.

APIDiff.png

 

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.

KeyDiffs.png

 

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.

In Software Enablement for PSoC 6 – What to Expect I talked about what the Peripheral Driver Library (PDL) is. In PDL 3.0 – Designed for Flexibility I described the high-level design that supports multiple peripherals working on either core and operating on multiple data streams. You can use the PDL to take advantage of the power inherent in the PSoC 6 family, while simplifying software development.

 

There is an entirely different level of flexibility, and that's your choice of development tools. Until you get your hands on the PDL 3.0, this remains theoretical. But you’ll have some choices.

 

First, a tiny bit of background on the Cypress development tools. Then we’ll get back to PSoC 6.

 

Cypress provides PSoC Creator, an integrated design environment. If you aren’t familiar with PSoC Creator, let me describe it briefly. It enables the concurrent design of both the hardware system and the associated firmware. You drag components into a design, configure them and (when necessary) wire them together. You use a friendly UI to manage component configuration, pin assignments, system clocks, and interrupts. PSoC Creator is an expert system, and analyzes your design for conflicts or potential problems. Based on your design, PSoC Creator generates configuration and initialization code that you can use when writing the firmware. It supports iterative development – change the design, the generated code changes to match. PSoC Creator is free. It runs on the Windows OS.

 

PSoC Creator is a really good tool, and I thought that long before I joined the Cypress team. I have worked with code generators in one form or another for years, and I really like them. However, a fundamental principle that I subscribe to is, “your mileage may vary.” As much as I like PSoC Creator, you may not. We’re all about enablement, not about limits, and that includes your choice of IDE. This flexibility is designed into the PDL. We won’t make you change IDEs.

 

At a high level there are three paths you can take when you develop code using the PDL for PSoC 6.

 

Use PSoC Creator from beginning to end.

Use it for the system design, and as a development environment for your software. It includes a compiler and linker, a programmer to download the executable to the platform, and a debugger. It has all the features you would expect to find in a good IDE, like code browsing.

 

Use PSoC Creator generated code in your preferred IDE.

There are a couple of ways to do this. For supported IDEs (IAR Embedded Workbench and Keil µVision tools are on the list), PSoC Creator has defined an export/import process for project files. For any IDE, even if not “officially” supported, you can add PSoC Creator generated source files to the project file in your preferred IDE.

 

Use your preferred IDE from beginning to end.

While PSoC Creator can handle a lot of the system configuration for you (like clocks, setting up interrupts, and so forth), you absolutely can do this yourself. The PDL is, after all, a source code library. Just use the files you need. For example, the PDL includes code to manage the system and peripheral clocks. When PSoC Creator generates code to do this, it uses the PDL function API to get the work done. You can use the PDL source code directly, rather than the generated code.

 

When you use a third-party IDE from beginning to end, you lose access to only one PSoC feature. PSoC 6 devices have universal digital blocks (UDBs). A UDB contains programmable logic devices that enable you to build logic at the hardware level that links other hardware in your design, or to create a stand-alone block that performs a new function. If you want to develop a UDB, you must use PSoC Creator.

 

Of course, in the “real” world things can be a lot fuzzier. These three paths are real, but you can also find your personal sweet spot among these choices. For example perhaps you prefer to use snippets of code from the generated source files rather than complete files (a complex configuration structure perhaps). Or you like the PDL driver for one peripheral, but intend to create your own for another peripheral because of your unique requirements.

 

All of this is possible. The PDL is an enablement tool. You get all the source code. You can use it as you see fit.

 

Finally, you should be aware that choosing to use PSoC Creator components in your design presents some interesting benefits, and tradeoffs. I talk about that in a separate post, PSoC 6 Components and PDL Drivers.

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.

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:

 

PDL_Block.png

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.