Software Enablement for PSoC 6 – What to Expect

[JamesT_21]

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.

[HeLi_1220176]

Psoc creator has been hands down the best environment I'll used for a MCU.  Hopefully they don't change too much there.

[JamesT_21]

From the user perspective it is very much the same. How one exports a project to a 3rd party IDE is changing. There are some differences in support of the dual-core architecture. But those are pretty simple. Example - when you want to debug a PSoC 6, you'll see a dialog to select which core. That wasn't an issue before.

[Anonymous]

Does PSOC Creator support Jlink? Because Jlink can be very easy to get, while using Jlink RTT print debugging information is very convenient.

[JamesT_21]

Trying to be very precise here. PSoC 6 supports JLink. I have a JLink Ultra on my desk and have used it with 3rd-party tools. I have not used JLink with PSoC Creator, and I do not believe it is supported "natively" inside PSoC Creator.

For "what to expect", meaning what's coming inside the PDL, there is a utility in the PDL code to support printf() and standard IO output to a terminal window. So you should be able to see printf statements easily coming from your code. There are two other workarounds right now.

1) you can use JLink utilities to download and debug the elf

http://www.cypress.com/forum/psoc-creator-software/jlink-support-psoc-creator

2) you can export to an IDE that has native JLink support. The technical details of how this works are changing in PSoC Creator 4.1. I'm thinking this (export/import) may be a really good topic for some additional "collateral" like a good code example or an app note.

[Anonymous]

Hello,jett

     Thanks for your reply and workarounds.

1. I know how to use Printf () to print debugging information, I do this on PSOC4, but printf () is too occupied RAM, and PSOC Creator debugger is too expensive and not too good to buy.

2.If i export the projec to a 3rd Party IDE,but i have to export the current project everytime i change a clock or anything,this is too annoying.

[JamesT_21]

Understood. No perfect solution.

Let me give you a "high-level" suggestion as an alternative to export/import. This is what's in my head, and why I'm thinking a very precise app note on this topic will help. Your thoughts appreciated. I do not have step by step instructions. But...

Rather than a formal "export/import" here's an idea worth exploring.

You have a project file in some IDE. It is possible to "manually" add files directly from the PSoC Creator generated code folder to your project. Not copies, not exports. Actually point your project at the generated files.

Challenge: which files? (Why I'm thinking an app note here would be good.) For now, assume you get all the right files into your IDE project.

Make a change in the design in PSoC Creator and regenerate the code. The files in the generated_source folder get updates.

Some possibilities over in your IDE:

1) There are new files (new component perhaps). You must add those to your IDE project

2) Some files go away (removed a component perhaps). You must remove those from your project.

3) You get updated files (this is the common case). Because the IDE points right at the files, a good IDE sees that the files are newer than last build, and knows you must recompile your code.

Item 3 is the good part - no export import, Your IDE just connects to the files, and updates as they update.

Items 1 and 2, not so good. You have to do the file management yourself (that's the manual part).

I have done this, and while it's pretty manageable for the kind of code examples we work on, it may be a bigger challenge for a real world project.

We are getting pretty far off topic here. What I'm hearing is....We need a good way to work with Creator-generated code in another IDE. That is, in fact, my primary interest right now, focusing on the PSoC 6 platform

[Anonymous]

Thank you very much for your detailed reply, I will try the way what you say.For me personally, I am also very concerned about the PSOC 6 BLE, its performance is very strong relative to the PSOC 4 BLE. At the same time, I also hope that as soon as possible to get the development board, so as to experience the powerful PSOC 6 BLE

[Anonymous]

Will the CMSIS-DRIVER API be available as part of the PDL? And if not, was this considered? I realize that vendors are not super excited about it, since it might seen as something that erodes vendor lock-in, although on the other hand it would allow for richer eco-systems with time.

[JamesT_21]

Let me see what I can find out, I'm not sure. I'd rather confirm one way or the other, and not hand out something inaccurate. Appreciate your patience.

[Anonymous]

Hi Jett, is there any step to add the support for C++ for this platform ? A multicore system  with a Cortex M4 is shouting a more powerfull language than C. The complexity of the systems that can be developped need a higher abstraction level than C to be kept under control before they get unmaintable systems due to the complexity of the code and the low reusability. I think that is not enough the basic framework as the basic reusable software component.

[JamesT_21]

Thanks for your patience.

As I expected CMSIS driver API is not currently supported in the PDL. It was considered. The challenge for us isn't that it is "open" and a common standard. We actually support lots of those. The decision was based on capabilities and engineering priorities, not fear of losing "vendor lock-in." By its very nature a generic API must be "lowest common denominator" and support only those features and capabilities that are general to all supported hardware. So our focus for now is on driver software that can implement all the features of the hardware. The PDL will be provided in source code when it's ready for distribution.

[JamesT_21]

Hi! For what it's worth I am personally a real fan of object-oriented programming. Having said that, it has probably been 10+ years since I did anything with it. I worked on desktop-level stuff once upon a time, where C++  (and Java) are well entrenched. Since moving into the embedded arena there has been near-zero demand. Now that embedded processors are becoming much more capable, demand is showing up.

The PDL is written in C. And as noted elsewhere it will be provided as source code. In THEORY (I have not done this) you ought to be able to use the PDL source code from C++. I'll add that to my list of "stuff to explore." Honestly, though, that's not near the top of the list.

Finally, I'll make sure the people guiding product direction hear this request. I expect demand will grow.