DesignSpark Electrical Logolinkedin
Menu Search
Ask a Question

2 Nov 2018, 15:03

Experimenting With Peripherals and the Clicker 2 for PSoC 6

The PSoC 6 device from Cypress Semiconductor is a very powerful and flexible microcontroller with a vast array of great features. Which is great, except that it can be quite daunting to look at all the documentation (Cypress are very good at documenting everything) and ponder how steep your learning curve will be to get going with even a fairly simple project, especially if laying out your own board for the application is the ultimate goal.  

That is where the Mikroelectronica Clicker 2 for PSoC 6 (MIKROE-2849) can help bring the elements of a simple project into focus. In this article, we go back to basics and set ourselves up so we can easily experiment with sensors (or other peripherals) we may want to use in a PSoC 6 project.

Introducing the Clicker 2 for PSoc 6

The Clicker 2 (170-8233) is a pretty minimalist design, especially compared to most modern dev boards that try to show off every feature the MCU has - on one board. If you look at the schematic, you will see a PSoC 6, a PSoC 5 (for programming and debugging the PSoC 6), an LTC3586 USB power manager and connectors to mount two Mikroelectonica Click boards. Apart from the requisite passives to set up and ensure the smooth running of our devices, there isn’t much else. Don’t worry though, you still get the button switches and LEDs essential to any proper application…

This simplified design makes it easy to focus on what you want from an MCU project without the clutter of devices and features that you don’t intend to use. It also makes it easy to experiment with sensors and other devices (by simply changing Click board) to help decide if they are really the parts you want to design into your project.  

Which brings us nicely to what we are doing today. I have had an MQ-7 based carbon monoxide detector click board (CO click) in my drawer for months. I have been thinking of using it in creating an IoT (or maybe Bluetooth) based alert system, so it seems like a great opportunity to try it out with an MCU that will easily handle the complete application.

Setting Up

One thing embedded systems don’t do much is let you know what’s going on inside, so it can be difficult to figure out what is working and what isn’t when you’re developing an application. We are going to fix this problem by using FreeRTOS, which is built into PSoC Creator, to redirect STDOUT to a terminal window connected via the USB. This will allow us to use the trusty ‘printf’ function to let us know what’s going on with our programs. This is a simple setup that can be re-used at the start of any PSoC project to aid debugging.

Open PSoC Creator 4.2 and select ‘File -> New Project’. You will be asked for a target device. If you have already used PSoC 6, you will see something like this:

In our case, we are using the PSoC 63 device. Hit next, and next again for the following window (we’re not changing the defaults) until you get to ‘Select project template’. Here, we want the empty schematic. Give the project a name and hit ‘Finish’. You will be presented with a blank workspace:

We will be using a UART for our comms, so we need to get one from the Component Catalog, to the right of the main window. The easiest way to find components is to type what we want into the search bar at the top of the Component Catalog window. Then we just drag the component and drop it onto our main window:

We are going to leave the UART settings as default, so we don’t need to double-click on it (to bring up the settings screen) but we will need to connect the UART to the correct output pins, which we can find on the Clicker 2 board schematic:

So we need P12.1 and P12.0, which we can set up by double-clicking on ‘pins’ in the Workspace Explorer (to the left of the main window):

Hmm. Looks like there may be a discrepancy between my version of the Schematic and PSoC Creator as to which pin is Rx and which pin is Tx, so we will go with PSoC Creator.

Now we need to retarget our STDIO to the UART so that we can get our ‘printf’ statements sent to the terminal. We will start by setting up FreeRTOS. Right click on the project name and select ‘Build Settings…’:

We then go down to ‘Peripheral Driver Library’’ and check ‘Memory Management’ under FreeRTOS (using the default heap) and ‘Retarget I/O’:

At this point, we can go to the top menu bar and select ‘Build -> Generate Application’ to make sure we have everything setup correctly. Great!

PSoC Creator has now added some files to our project, including FreeRTOS, stdio_user.c, stdio_user.h and retarget_io. We will need to modify stdio_user.h:

We are adding a:

#include <project.h>

At the top and changing the UART definitions:

#define IO_STDOUT_UART          UART_1_HW
#define IO_STDIN_UART           UART_1_HW

Next, we open FreeRTOSConfig.h

And we comment out the warning at line 45 before modifying the heap size on line 71:

#define config_TOTAL_HEAP_SIZE      (48*1024)

Now we are done with the mods, we can then go over to main_cm4.c (open from the Workspace Explorer) and add some code to start the UART for our comms and print something to the terminal.

#include "project.h"
#include <stdio.h>
int main(void)
    __enable_irq(); /* Enable global interrupts. */
    /* Place your initialization/startup code here (e.g. MyInst_Start()) */
    printf("\033[2J\033[H"); // Clear Screen
        /* Place your application code here. */

There’s just one more thing we need before we can run our code: a terminal emulator like Putty or Tera Term. In order to set that up we need to open the Windows Device Manager and see which COM port the KitProg2 USB UART is connected to:

So I’m on COM12. We can set that into our terminal settings. I’m using Putty and my settings will look like this:

Open the terminal and then go back to PSoC Creator and hit the ‘program’ button (just above the Workspace Explorer). After the application is built and loaded onto the PSoC 6, we can go back to our terminal and, voila! There is our message:

Adding The Sensor

Now that our debugging scheme is set up we can get to some real experimenting. Looking at the schematic for the CO Click board, we can see that we have an analog output from the sensor to the AN pin:

Going back to our Clicker 2 board schematic, we can see that the AN pin of Click board site 1 is connected to P10.4 of the PSoC 6. So we will need to set up an analog to digital converter (ADC) to read the voltage on this pin.

If we search the component catalog in PSoC creator for ‘ADC’, we find the Scanning SAR ADC that we can drop onto our top-level design:

We will need to set this up to take a single-ended input with enough input range for our 5V device:

After we have set these parameters, we need an analog pin to connect the ADC too. We can find that in the Component Catalog. Drop it into the design and connect it to the input of our ADC:

We then connect this pin to P10.4 in the pins map:

We then need some code to drive our data collection. I found an equation to convert the voltage measured by the ADC to a parts-per-million (PPM) value in the example code for the CO Click on the Mikroelectronica code website. We will use that in our own code:

/* ========================================
 * Reading data from an MQ-7 CO sensor
 * ========================================
#include "project.h"
#include <stdio.h>
#include <math.h>

const double Rl       = 5000.0;              // Rl (Ohm) - Load resistance
const double Vadc_2x  = 0.0016113281;        // ADC step 2*Vref/4096 1.61mV (12bit ADC)
const double Vadc_33  = 0.0008056641;        // ADC step 3.3V/4096 0.81mV (12bit ADC)
double Vrl;                                  // Output voltage
double Rs;                                   // Rs (Ohm) - Sensor resistance
double ppm;                                  // ppm
double ratio;                                // Rs/Rl ratio

int16_t adc_rd, adc_V;
char txt[16];

//Calculation of PPM
void calculatePPM() {
  double lgPPM;
  Vrl = (double)adc_rd * Vadc_2x;            // For 3.3V Vcc use Vadc_33
  Rs = Rl * (5 - Vrl)/Vrl;                   // Calculate sensor resistance
  ratio = Rs/Rl;                             // Calculate ratio
  lgPPM = (log10(ratio) * -3.7)+ 0.9948;     // Calculate ppm
  ppm = pow(10,lgPPM);                       // Calculate ppm

int main(void)
    __enable_irq(); /* Enable global interrupts. */

    printf("\033[2J\033[H"); // Clear Screen
    printf("Terminal Output Running...\r\n");
    printf("Conversion starting now...\r\n\n");

        adc_rd = ADC_1_GetResult16(0);                // Connected to mikroBus1 AN pin/P10.4
        adc_V = ADC_1_CountsTo_Volts(0, adc_rd);  
        calculatePPM();                               // Calculating PPM value
        printf("ADC value = %d, Volts = %f, ppm = %f\r\n", adc_rd, Vrl, ppm);

/* [] END OF FILE */

We’re now ready to program the PSoC 6. When we load this all up to the device and look at our terminal, we are getting some data – yea!

As a double-check: measuring the voltage across the AN and ground pins on the CO Click (with our trusty RS Pro digital multimeter) we see the same voltage levels. Great, our ADC is working as we expect.

So if I am going to get the PSoC 6 to let me know that I have a high level of CO in the air, the question now becomes: how do I tweak my voltage (with the potentiometer on the CO Click) to get PPM measurements that are in the right ballpark? Time to refer to the MQ-7 datasheet.

OK, just noticed something interesting: turns out that the sensor really needs a more complicated set up than we are using. To get the most accurate readings, we need to set the on-sensor heater to run through high and low heating cycles, where (after heating at 5V for 48 hours) we apply 5V for 60 seconds and don't use these readings. Then we apply 1.4V for 90 seconds and use these readings for our CO measurements. The High-temperature phase evaporates CO (and any other combustible gas compounds) from the sensor plate, essentially cleaning it for the lower temperature measurement phase, allowing for accurate measurements. We would continue repeating these cycles.

Our CO click is not set up to supply this cycle, so while we are still able to detect the presence of carbon monoxide looks like I will have to rethink our design beyond what we have on the module to get truly accurate measures.

Final Thoughts

Although accurately measuring carbon monoxide with the MQ-7 sensor has turned out to be more involved than I first thought, the Clicker 2 for PSoC 6 board made trying it out a pretty simple proposition. It would also be just as easy to try out the other carbon monoxide click board (CO 2 Click), though I may read the sensor datasheet before trying that!

As a bare-bones PSoC 6 development board, I like the Clicker 2. It allows you to clearly focus on the sensors or other peripherals you are using in your project and I am keen to tinker with some of the other Click board modules on this board in the near future.

Mark completed his Electronic Engineering degree in 1991 and went on to work in real-time digital signal processing applications engineering, later moving into technical marketing.

2 Nov 2018, 15:03