You are here

PSoC Creator News and Information | Cypress Semiconductor

May 22, 2017

Cypress Maker Lab - Barc is Finally Tamed

Well, I finally finished my Barc project. The design is attached to this blog. I think I learned a lot. Mostly that I should never pick up another soldering iron, always use battery packs with on/off switches, and that blogging takes a lot longer than programming. More usefully I got quite efficient at tuning CapSense and have a very tidy and reliable motor control circuit to use in new designs.

Barc works pretty well now but he tends to be a little excitable. He is quite obedient most of the time and faithfully follows my hand even though I am not holding any treats at all. But I did build a little bit of "personality" into him by breaking all the rules of good CapSense sensor design. To name a few of my engineering crimes:

  • My sensors are just roughly looped wires taped to ABS plastic (this reduces the range a lot)
  • My proximity threshold settings are just a few counts above the noise
  • The SNR was tuned in perfect conditions with no unshielded motors running nearby! Not exactly reality…

It is hardly surprising, then, that after following me for a while he has a habit of running off into the distance or chasing his tail like it has been wrapped with bacon. It is all good fun but I could never take him for a walk in San Jose traffic.

To train him a little bit I built a little thinking time into his main loop. According to the CapSense component each scan takes 512 microseconds. You can see this in the dialog. Each scan slot takes 171us for a total of 512us.

CapSense customizer dialog showing the order and duration of three proximity scans

That means I am detecting just less than 2000 times per second. I can give Barc some rest time by counting the number

of times my main loop executes and forcing a delay, with CapSense and the motors both turned off, if he does the same thing for more than a second. It's just a simple loop counter that increments if the motors are running (compare value not equal to zero) and resets otherwise. If the counter gets to 2000 then Barc stops for a quarter of a second. That seems to be long enough for the noise to die down enough for much improved behavior.

I feel the need to point out, one last time, that this is deliberately doing very naughty things with CapSense. I am ignoring the excellent guidelines set out in our best practices document so that Barc will behave badly, and then using extremely crude measures to limit the "error" rate. If you are making a serious CapSense design please don’t use this project as an example of robust sensing! But, that said, he's my dog and I'll train him however I like!

Attached is a short video of Barc chasing me around the floor.


And here is the snippet of code that senses my hand, adjusts the motor speeds, and, if necessary, takes a short breather to let the noise dissipate.

    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


        if( CapSense_IsWidgetActive( CapSense_LEFT_WDGT_ID ) )


            /* Hand to the left, follow it */

            PWM_Speed_WriteCompare1( 40 );

            PWM_Speed_WriteCompare2( 0 );



        else if( CapSense_IsWidgetActive( CapSense_RIGHT_WDGT_ID ) )


            /* Hand to the right, follow it */

            PWM_Speed_WriteCompare1( 0 );

            PWM_Speed_WriteCompare2( 40 );



        else if( CapSense_IsWidgetActive( CapSense_FRONT_WDGT_ID ) )


            /* Run toward the hand in front of your nose */

            PWM_Speed_WriteCompare1( 60 );

            PWM_Speed_WriteCompare2( 60 );





            /* No hand close so stop */

            PWM_Speed_WriteCompare1( 0 );

            PWM_Speed_WriteCompare2( 0 );

            loopcount = 0;



        /* Each loop takes ~500ns so check for 1s of unchanged state */

        if( loopcount > 2000 )


            /* Turn off the motors */

            PWM_Speed_WriteCompare1( 0 );

            PWM_Speed_WriteCompare2( 0 );

            loopcount = 0;


            /* Turn off CapSense and wait 250ms for noise to settle */


            CyDelay( 250 );




        #ifdef TUNING

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



I have attached my final Barc project to this blog. Feel free to try it out, fix it, add to it, whatever. But do let me know if you do something interesting!

It took me longer than I expected to finish this project - just ask my wife/videographer who got really bored of the whirring motors and runaway dog in the living room - but now I think it is time to move onto the next one. I feel like I actually know what I am doing at last. Next time I am going to use Sparkfun robot/motor parts and see if I can make a Bluetooth-enabled dog…


May 16, 2017

PSoC 6 Early Adopter Program (EAP) Community


Since our announcement of PSoC 6 at Embedded World 2017, we have been getting a lot of traffic on our PSoC 6 EAP Community. In this community, you will get frequent updates on PSoC 6 features and plans. Some of the content on this community are:

PSoC 6 "Did You Knows"
These are posts on PSoC 6 features that are unique and differentiating, such as the Serial Memory Interface or the Inter-Processor Communication.

PSoC 6 Documents
These are drafts of Application Notes (AN) and other documentation for PSoC 6, such as the PSoC 6 Hardware Design Considerations AN or the PSoC 6 Brochure.

PSoC 6 Videos
These are videos of kits and overview of PSoC 6, such as the PSoC 6 BLE Pioneer Kit video or the PSoC 6 Overview video.

Joining is easy, register or log in at, and click the banner below! Also, by joining, you will have a chance to win a PSoC 6 BLE Pioneer Kit!

May 10, 2017

PSoC 6 and PDL 3.0 – Designed for Flexibility

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

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.


May 04, 2017

Code Example Browser Sluggishness / 523 Error

Executive Summary - See this Knowledge Base Article

Hey folks,

I find myself using File->Code Example all the time, but recently I had some problems with the browser hanging and return with a 523 error. It turns out this is a known problem with some versions of the Adobe reader.  The fix is to update to the latest version. The workaround is to "Disable protected mode at startup" in the Adobe Acrobat Reader. See the KBA above for details on how to do that.

While I'm posting, I thought I would show the code example browser for those that haven't seen it.  Again, you can access it from File->Code Example in PSoC Creator.  You can filter by device family and/or keyword.  In the screenshot below I have selected a BLE Battery Level example.  Also note that there are two tabs in the browser, Documentation and Sample Code.  The image below shows what the Documentation tab looks like for this code example.


The next image shows what the Sample Code tab looks like.  You can copy/paste sections of code or just click the "Create Project" button and PSoC Creator will create a new project using this code example.



Have any ideas for a new code example?  Hit me up in the blog comments or send an email to

Yours in PSoC,


May 02, 2017

Hackster Sensing the World Contest - Smart Home Controller


Here's an update on one of the winners of the "Sensing the World" Contest with our partner, Hackster.
Abdullah Sadiq built a Smart Home Controller using  Cypress' PSoC Analog Coprocessor. The key message in this Smart Home Controller is the versatility, meaning fulfilling every possibility. This project is a proof of concept showing how the data from the analog sensors on the PSoC Analog Coprocessor Pioneer Kit can be sent to a Blynk server via a LinkIt ONE through WiFi. IFTTT is then used to control a smart device (such as a Nest Thermostat), "smart" enough to connect to the Internet, based on the data from the analog sensors.

Below is a shot of the proof of concept of the Smart Home Controller:

For details on the project and video, check out these links:
​Project: Smart Home Controller 
Link to project video:

Congratulations to Abdullah Sadiq for this unique project!


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.