You are here

PSoC Creator News and Information | Cypress Semiconductor

Mar 27, 2017

Introducing PSoC 6: Purpose-built MCU Architecture for the IoT

If you were following Cypress news for the last couple of weeks, I’m sure you saw some interesting and exciting announcements…in between reading Mark’s posts about Barc: My Cypress Maker Lab Project.  Take a look at the below to learn more and join us in the PSoC 6 Early Adopter Program to continue learning more.  


Here it is…Cypress’ PSoC 6 MCU Architecture…


At the heart of every IoT device lies a mixed-signal embedded system that is taking on an increasing amount of processing, fueled by cloud connectivity. Devices such as door locks, factory machinery, and wearables are becoming smart — sensing, connecting, learning and responding — to make life easier. With connectivity, security becomes critical to protect end users from malicious activity. These next-generation IoT devices require increased processing and security without incurring power and cost penalties.

Cypress’ new PSoC 6 MCU architecture is purpose-built for the IoT, bridging the gap between expensive, power hungry application processors and low performance MCUs. The ultra-low-power PSoC 6 MCU architecture offers the processing performance needed by IoT devices. Security is built-in, enabling a single-chip solution. PSoC 6 enables engineers to uniquely create innovative, next-generation IoT devices leveraging the unique PSoC fabric with its easy-to-use, software-defined peripherals.   


Ultra-Low Power
IoT devices are often battery powered, making battery life a critical factor. The PSoC 6 MCU architecture is built on a cutting-edge, ultra-low-power, 40-nm process technology, and provides two ARM® Cortex-M® cores. Active power consumption is as low as 22-μA/MHz for the M4 core, and 15-μA/MHz for the M0+ core. PSoC 6 delivers extended battery life without sacrificing performance.

PSoC Possibilities
The rapid growth of the IoT is sparking a need for innovation in IoT products. The PSoC 6 MCU architecture’s best-in-class flexibility enables the addition of new features and addresses the need for unique IoT products with multiple connectivity options, such as USB and BLE, software-defined peripherals to create custom analog and digital circuits, and the industry’s best capacitive sensing solution, CapSense®. In addition, a flexible dual-core architecture is used to optimize for system power consumption and performance. The possibilities are endless.

With more devices becoming connected to the IoT, cybersecurity becomes an important issue to address. Secured connections must be established between hardware, cloud applications and servers, and finally users and services. The PSoC 6 MCU architecture supports multiple, simultaneous secure environments without the need for external memories or secure elements, and offers scalable secure memory for multiple, independent user-defined security policies, preventing your IoT device from becoming a security liability. PSoC 6 provides you with a new standard for IoT security.


Join the PSoC 6 Early Adopter Program today and learn more, download datasheets, get application notes, software, and a chance to win a development kit.


Mar 23, 2017

Cypress Maker Lab - Barc gets a nose

If you read my last post about Barc you will know that I was feeling pretty confident prior to the Embedded World show. All I needed to do was add some CapSense proximity loops (a.k.a. wires) to the robot, tune the CapSense sensors, and add a simple firmware state machine to move the robot based on which sensor notices a nearby hand. Simple!

And, for the most part it was. I fashioned a head for the dog from ABS plastic and taped in three loops of wire facing (pun intended) the front, left and right. I connected the wires to PSoC pins via the breadboard and got ready to finish the PSoC Creator project. Here are some pictures.

More alert readers will notice that the color of the PSoC kit has changed. More on that in a moment. Some will also see that programming the kit now requires me to feed the USB cable through the dog's mouth. Oops. That is pretty silly and, now I have done it about 600 times, I strongly advocate turning the kit around by 180 degrees. Unfortunately that would require me to rip off the breadboard and battery pack, which would make a nasty mess of the robot. I really do not want to do that… so I decided to live with it. And anyone who has tried measuring or tuning a sensitive electrical circuit like a proximity sensor will see that it is going to be tricky to get right with a big shielded cable running straight through the middle of the loop! I am, officially, a twit.

Then things got worse. My boss called. He never does that. So I knew it was likely bad news on the eve of Embedded World.

Boss: So, how is the robot car coming along?


Just fine Boss.
Boss: Will it be ready for the show? We need you talking in our theater three times day.


No problem. I am just tuning the CapSense so that the dog will chase me around the floor.
Boss: Good. I saw the last blog and it looks like you are using the PSoC 5LP kit.


Yyyyeeeessssss. And?
Boss: Well we brought out the PSoC 4 kits and they have the next generation CapSense IP.


I am building a robot dog. No-one will notice.
Boss: Well we brought out the PSoC 4 kits and they have the next generation CapSense IP.


I am building a robot dog. It has wire loops taped inside its skull. No-one will notice.
Boss: Well we brought out the PSoC 4 kits and they have the next generation CapSense IP.
Me: OK.
Boss: Good talk!


It was very reminiscent of the famous Office Space movie and the end result was weekend work for me. The good news is that I already had a handy PSoC 4 M-series prototyping kit - a pretty red one at that - and that changing the design in PSoC Creator took less time than it took to go another round with the soldering iron. In the time-honored tradition I swapped the kits and had the design working again in about an hour, then I told the boss I worked all weekend. It's a rule…

So, for the tuning, I added a CapSense component and an EZI2C to the project. The I2C is used as a bridge between the tuning software and the target. It can update the CapSense parameters live, which really helps you iterate to a solution. In the CapSense component I set up three proximity sensors, named FRONT, LEFT sand RIGHT, and selected manual tuning.



I also turned on filtering (in the Advanced tab) to remove as much noise as possible. This turned out to be really important at the show because the noise - probably from the very static-y carpet - was way higher than on my hardwood floors at home. I shall put the full list of CapSense edits in the project file, which I will post in a blog once I finish the whole project.

Here is the C code I wrote to run the tuner. In the I2C code I just tell it about a buffer (CapSense_dsRam) in the CapSense code and the tuner program uses this to communicate with the device. To avoid a lot of silliness - chasing a robot dog around the room - I did not start the PWM while I was tuning!


    /* Start EZI2C component and prepare it for tuning */



        sizeof( CapSense_dsRam ),

        sizeof( CapSense_dsRam ),

        (uint8 *) &CapSense_dsRam );   

    CapSense_Start();               // Turn on CapSense   



        /* Start a scan and wait for it to complete */


        while( CapSense_IsBusy() )


            /* Busy loop */


        CapSense_ProcessAllWidgets();   // Read all sensors and determine widget status

        CapSense_RunTuner();            // Send data to tuner (I2C)



After building and programming I right-clicked the CapSense component and selected "Run Tuner". The tuner starts up and looks like this.


​I start tuning in the graph view. CapSense uses a "raw count" value from its sensors and it is best to set the baseline value to 80% of maximum so there is room for the counts to go up (when a hand is close) and noise is minimized. You adjust the resolution and Modulation IDAC values to make that happen. Increasing the resolution  improves the range of the sensor but also increases scan time (I do not care much in this application). Increasing the IDAC pulls the raw count value down to that 80% point.



Once I have that working I use the SNR Measurement tab. You just select the sensor and Acquire Noise. Then you put your hand by the sensor and Acquire Signal. It tells you the noise level and the SNR, which should be above 5.



I'm in good shape now. I set the Noise and negative Noise Thresholds to 5, which leaves a little wiggle room versus the measured value of 3. The Proximity threshold is 10, which is much closer to the noise than I would like, BUT I want maximum sensitivity and, if I do get some false readings it gives my dog a will of his own! I set the Touch Threshold to 100 which means that the sensor can register both proximity and, if I get really close, a touch. I might use that in the final project to change Barc's behavior in firmware.



As a sanity check I look at the Status graph, which shows the off / proximity / touch readings as I move my hand around the robot.



Once I have the settings I like I can send them To Project and quit the tuner. Back in PSoC Creator I open the parameter editor for CapSense and it lets me accept the edits from the tuner. Now, when I rebuild the program I have the tuned IDAC and threshold values for the left sensor.



I added a little code to the program, turned the PWM back on, and checked that my doggy reacts to my hand.


        if( CapSense_IsWidgetActive( CapSense_RIGHT_WDGT_ID ) )


            PWM_Speed_WriteCompare2( 40 );




            PWM_Speed_WriteCompare2( 0 );


Here is a video of Barc sensing a hand near his face - did you notice that I actually video'd the left sensor instead of the right?

When I get back from vacation I will post my final Barc blog. I will complete the tuning of the other sensors and add a simple state machine to drive the motors and make him follow my hand. I will also include a bill of materials so you can re-create your own robot, with PSoC, for about $50.

Mar 21, 2017

Feedback Requested on New Product Page Template


We have been working on a new layout for our product pages based. Before changing our template though, we want to make sure that the proposed site we’ve been working on developing will best meet your needs. This is a demo site with varying degrees of functionality (exact functionality for each tab is listed below). We are interested in all feedback from font sizes to content placement and selection.   



Demo Site:

​Google Feedback Form: 



As this is a demo site created to obtain feedback, not all of the tabs or items are functional at this time. Below I’ve briefly listed the functionality of each tab with expectations for the production site.


Product Tree: (Expand by clicking on the three lines on the left.) Limited functionality. In production, you will be able to open families without selecting an item so you can view the sub-families and related products.

Overview Tab: Fully functional.

Getting Started Tab: Limited functionality. Not all links are properly working.

Products Tab: No functionality. At the lowest level, the Products tab will open a new Product Selector Guide (PSG). This is a picture of the new PSG layout we are currently working to develop.

Documentation Tab: Limited functionality. Filtering and searching are not functional. Most links are working but some may not be linked to the proper document. Show all Results is working on most categories.  

Videos Tab: Limited functionality. Page links and video links are not working. On the production version, videos will enlarge and play on-screen.

Tools & Software Tab: Limited functionality. Buy button is not functional. Titles of kits, software, etc. should be linked to their respective pages.

Solutions Tab: No functionality. This tab is currently a picture of what we would like to add. Solution titles would link to their respective solutions pages. End Products would link to their respective solutions pages.

Support & Training: Limited functionality. Icons are not linking properly.


We appreciate all feedback on the page. 


On behalf of the entire Cypress Web Marketing Team, I would like to thank you for taking the time to review our proposed Product Page,


Mar 13, 2017

Ready, Set, Go Embedded World 2017


Embedded World 2017 is here. After an exciting year, we wanted to invite you to our booth, located in Hall 4A, #148, and check out the super exciting demos we have!
We are showing some really creative and innovative demos this year, we have a CapSense and Inductive sensing enabled Tic-Tac-Toe demo,
Bluetooth enabled Liquid Level Sensing demo, our Type-C CCG3 Power Delivery, and much more! Be sure to stop by and check out our booth, you will surely leave
with many ideas to develop your next design!

Mar 12, 2017

Cypress Maker Lab - Barc Go! Barc Stop! Barc Chase Your Tail!

It's time for the finishing touches on Barc's motor control circuit. It's high time I took notice of the motor driver FLT (fault) signal and I want to add the ability to walk backwards.

I started by tidying up the wiring on the breadboard. Sree was giving me some mean looks about it. Here is the neater layout with the PSoC moved closer to the driver board and the wires running underneath where the two board plug in.

I thought the FLT signal would be easy. The documentation says that it is normally high and drives low if there is an over-voltage or over-heating problem in the driver chip. So I figured I could just AND the SLP (standby) and FLT. This should automatically turn off the motors if the FLT goes low. This would be another example of how flexible PSoC is and I drew up this circuit.

I thought this looked really neat and made the fault protection really robust because it is in hardware, with no risk of an interrupt getting masked or anything naughty like that. There was just one problem. It doesn't work. The motors don't run. So I messed about with the circuit. I questioned my logic. I checked signals by wiring them to the LED. I questioned my sanity. And then I gave up and called my mate Sree. Sree is a real engineer and has a super-power I shall never possess. He can be bothered to read the documentation. I had burned most of my Sunday on this. Sree figured out over lunch that, when you enable the motors (via SLP) the FLT signal always drops low for 380 microseconds. Now, if I am honest, it actually took Sree about 3 minutes to find out the problem and the rest of lunch was taken up with me moaning about hardware and how much easier it would be to do this with software after all. But the end result didn’t change - my circuit cannot work.

I need to enable SLP, wait a while, and then start worrying about FLT. I was mulling over a plan of using a second counter to start timing when the button is pressed and sample FLT after 380us. But it seemed like overkill for the actual problem and I did not like that it meant we would be running the motor without checking FLT, even if it was for a really short period of time. Ideally I wanted to turn on SLP but keep the AIN and BIN signals low (so no load was put on the motors) until FLT was ready to be read and was high. Enter the PWM kill signal. The PWM I am using to drive the motors has an optional kill input which sets the outputs low when the kill is high. This is a really easy way to protect the motors. Press the switch and enable the motors with the PWMs killed. As soon as the FLT goes high the PWMs start. This is a really elegant solution that does not require an extra counter or make any assumptions about how long the delay on the fault signal is. I programmed it into Barc and tested that FLT does, indeed, stop the motors by wiring it up to ground before and after pressing the switch.

I feel a lot safer now. With Embedded World just a few days away I am less likely to blow up my demo! Let's add some maneuverability to this hound. I can go forward, left and right, but I cannot reverse or spin on the spot. Real dogs are pretty good at that. I need to be able to switch the PWM outputs to the AIN and BIN pins. I am going to do that by using a control register. This is an 8-bit register (I only need 2 bits) that lets me set hardware signal from firmware. Each bit shall define the direction of the motor and, in the schematic, I will simply use some more AND gates to send the signal to the desired pin. Pictures are worth a thousand words, so here is my circuit, starting with the control register, which I have called Direction.

Note how I have named the wires to make the drawing easier - it helps to see what is going on that way too. The PWM outputs get ANDed with the direction signals to either hold the pin low or pass through the PWM signal. Note that I re-enabled the HW connection on the AIN2 and BIN1 pins so I can connect them to the gates (and I no longer set them from firmware).

A little splash of firmware and we have a dog that can walk forwards and backwards and chase his tail in both directions.

#include "project.h"

int main(void)


    uint8 dir = 0;




        Direction_Write( dir++ );

        CyDelay( 1000 );   




I am happy with Barc's agility now. He is nearly ready for the big dog show in Germany! Just one last problem to solve . How to make him "see" people and interact with them. This sounds like a big task, but PSoC's CapSense makes this quite simple… next time.



Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.