Skip navigation
Home > All Places > Product Forums > MCU & PSoC > PSoC 6 MCU > Blog > 2020 > February




Software/IDE PSoC Creator 4.3 and PDL 3.1.1




DHT-11 is a popular sensor to measure temperature and humidity. The sensor is manufactured by many companies one of which is Adafruit and the Adafruit sensor can be found here. This blog provides 2 ways to interface DHT-11 with PSoC 6 one using the interrupts and the other without. The PSoC Creator projects for the two applications are attached as part of this blog.


Working of DHT-11 Sensor:


DHT-11 is a single wire digital humidity and temperature sensor, which provides humidity and temperature values serially with one-wire protocol. DHT11 sensor provides relative humidity value in percentage (20 to 90% RH) and temperature values in degree Celsius (0 to 50 °C). DHT11 sensor uses a resistive humidity measurement component and NTC temperature measurement component.


The sensor has 3 pins – Vcc, Data, Gnd. The operating voltage of the sensor is 3.3V to 5V and thus Vcc is connected to 3.3V and Gnd to Ground of the kit. Data pin acts as the asynchronous interface between the sensor and the PSoC device. The Data pin should be configured as a bidirectional pin with drive mode set as Resistive Pull Up. The communication protocol followed by the sensor is asynchronous with a START condition, ACKNOWLEDGEMENT and 5 bytes of Data.

The 5 bytes contain the following data –


Byte 1 - Humidity (whole number part)

Byte 2 - Humidity (fractional part)

Byte 3 - Temperature (whole number part)

Byte 4 - Temperature (fractional part)

Byte 5 - Checksum


1. START – Start condition is sent by the PSoC 6 device. An 18 ms low pulse is sent to the sensor.


Figure 1: Communication protocol of sensor



2. ACKNOWLEDGMENT – The sensor detects the low pulse from the MCU and sends an acknowledgment signal by pulling the Data line low for approximately 54 us. The sensor then sends a logic high for about 80 us and then starts sending Data to the PSoC MCU.


3. DATA – Data is sent serially in terms of bits. Bit-level logic is represented as follows,

  • Logic 0 – 54 us low and 24 us high signal
  • Logic 1 – 54 us low and 70 us high signal

40 bits are sent in a similar way after which the communication terminates. The last byte contains the checksum and needs to be verified to ensure that the data received is valid. The checksum is obtained by simply adding the first 4 bytes.


Figure 2: Bit 0


Figure 3: Bit 1




Application 1:


  • The first approach puts the CPU to sleep when not in use and makes use of the interrupt. The interrupt is triggered at the rising edge of the Data pin which wakes the CPU.
  • The START condition is sent first and the ACK is checked. The interrupt is now enabled, and the CPU is put to sleep.
  • To transmit a ‘0’ (Logic LOW), the sensor sends a 54 us low signal followed by a high signal. This LOW to HIGH transition wakes up the CPU.
  • If the sensor is transmitting a ‘0’ then it sends a 24 us high signal followed by the 54 us low signal of the next bit. If the sensor is transmitting a ‘1’ then it sends a 70 us high signal followed by the 54 us low signal of the next bit.
  • Therefore, the value of Data pin is read after a delay, greater than 24 us, which gives the value of the bit. So, if the bit is ‘0’ then after 24 us the Data pin is low and if the bit is ‘1’ then after 24 us the Data pin is high. Hence, reading the data pin after the will directly provide the bit that was sent by the sensor.
  • This is repeated for 40 times (for 5 bytes) and the bit values are stored in a separate variable for each byte. The interrupt is then disabled.
  • The checksum is verified by summing the first four bytes and checking with the fifth byte, and the temperature and humidity values are calculated. The firmware can then run the application to process these values (in this case report to the user via UART protocol).
  • All the variables are cleared for the next iteration and the process is repeated.


Application 2:


  • The second approach is simpler and more direct without the use of any interrupts.
  • START condition is sent as usual. A counter variable is incremented continuously from the START condition until the next rising edge.
  • The entire duration will be a little over 54 us which is the ACKNOWLEDGEMENT and the counter variable value is stored. If the counter value is more than the maximum allowed value (user-defined), it means there is a communication error. So, communication is terminated and needs to be restarted.
  • The counter variable is reset, and the CPU waits till the signal is low – for the 54 us low signal of the first bit. The counter variable is again incremented for as long as the Data line is high. If the counter value is greater than half of the previously stored value (half of 54 us ~ 27 us) i.e., if the data signal is high for more than 24 us, then the bit value is 1 or else, it is 0.
  • This is repeated 40 times and the bit values are stored in a separate variable for each byte.
  • The checksum is verified, and the temperature and humidity values are calculated. The firmware can then run the application to process these values (in this case report to the user via UART protocol).
  • All the variables are cleared for the next iteration and the process is repeated.


Comparison of the two approaches:


  • The first approach is to be used when power efficiency is crucial. The CPU remains in Sleep state for almost half the time during communication and wakes up only to read the bit value thereby increasing power efficiency. Please refer to the respective device datasheet for information regarding the current consumption of the device in Active and Sleep mode.
  • The second approach is more reliable comparatively and the user need not worry about interrupt latency, interrupts not getting triggered or false interrupts. The program can easily be ported. The only disadvantage being that this method polls for bit value, wasting the CPU processing time.
  • Also, for the second application to work as expected, there should not be any interrupts disturbing normal code execution flow during the communication. If that happens the communication fails. To avoid this the communication logic in the code is put in a critical section.




  • The projects have been tested on CY8CKIT-062-WIFI-BT using PSoC Creator 4.3 and PDL 3.1.1.
  • DHT-22 also follows the same communication protocol and the same projects can be used to interface the DHT-22 sensor.

Alexa Skills Demo on PSoC 6 Wi-Fi BT Prototyping Kit

1. Objective

The objective of this blog is to explain how to use Alexa Skills to control ‘things’ using PSoC 6 Wi-Fi BT Prototyping kit. We will control the speed of a fan on PSoC thermal management expansion board by instructing an Alexa device.


2. Requirements


      1. CY8CPROTO-062-4343W PSoC 6 Wi-Fi BT Prototyping kit
      2. CY8CKIT-036 PSoC thermal management expansion board kit
      3. Amazon Echo device (use Alexa simulator in the Alexa Skill Developer console if echo device is not available)


      1. Amazon developer account to use Alexa Skill developer console
      2. AWS account to use
        1. Compute service - Lambda
        2. Security, Identity, & Compliance service – IAM
        3. Internet of Things service – IoT core
      3. Mbed CLI to run subscriber application on PSoC 6 using Mbed OS ecosystem
      4. Serial terminal (Eg. Tera term) to view output and debug messages.

3.   Summary

Figure 1. Data flow from Amazon Echo to the fan

Amazon Echo is tuned to our use case of controlling the speed of a fan by building a custom skill using Alexa Skills Kit.

The developed custom skill is hosted on AWS Lambda service. Lambda function is triggered from Alexa Skills and the function is coded to publish messages to a topic in AWS IoT based on the input from the developed custom Alexa skill.

The physical device (PSoC6 + 4343W) subscribes to this topic in AWS IoT and generates appropriate PWM signal to control the speed of the fan. In this project, we will operate the fan at three different speeds namely low speed, mid speed and high speed.


Low speed

20% duty cycle (0 to 20% duty cycle will operate the fan in the kit at   its minimum speed).

Mid speed

50% duty cycle

High Speed100% duty cycle

However, in case of general instructions to Turn On/Off or increase/decrease of the speed, following will be the behavior.The user is expected to control the fan by asking Alexa to set or run at one of these speeds.

However, in case of general instructions to Turn On/Off or increase/decrease of the speed, following will be the behavior.


  Turn On

  Fan will run at mid speed
  Turn Off  Fan will run at low speed
  Increase the speed  Fan will run at high speed
  Decrease the speed  Fan will run at low speed

4. Setting up the project


     4.1.  Building Custom Skill

    1. Login Amazon developer account and navigate to Alexa developer console.
    2. Choose Create skill.
    3. Enter name of the skill and leave the rest at default as shown in Figure 2.

               (Ensure default language is English (US).

               Default settings allows us to create a custom skill and use our own AWS lambda endpoint)


Figure 2. Alexa Custom Skill Creation

ASK create skill.png

            4.  Choose template as Start from scratch.

            5.  Start building the custom skill by

                     a. Entering an invocation name – ‘fan controller’ is used in this project. This name is required for launching our custom skill.

                     b. Adding custom intents and utterances –

                         We will add an intent for each of the three speeds that we intend our fan to operate at,

                         namely LOW_SPEED, MID_SPEED and HIGH_SPEED.

                         Add all those phrases the user might utter to achieve the intent’s functionality as its sample utterances.

                         Either create the intents from the GUI in the developer console or use the provided JSON file (intents.json) and copy paste

                         the contents in the JSON editor tab.

                     c. ‘Save model’ followed by ‘Build Model’ and ensure error free build.

                     d. Test your model by using ‘Evaluate model’. Entering a sample utterance should invoke the correct intent.

                     e. Go to Endpoints -> Choose AWS Lambda ARN. Copy the skill Id. This is required in the AWS Lambda services.

                         We will return to the Alexa developer console and add the ARN of the lambda function we create in Section 4.2.

     Refer to Alexa documentation for developing custom skill for more detailed explanation of creating custom skills.

4.2.  Set up AWS IoT core

AWS IoT core requires the following to be set up

1.       Things - Things refer to a representation of the physical device.

2.       Certificates - Certificates should be created to ensure secure communication between AWS and the device.

3.       Policies - you must create and attach an AWS IoT policy that will determine what AWS IoT operations the thing may perform.


Follow the instructions in the amazon documentation to create things, certificates, policies and attach the policies to certificates.

Ensure to have same region selected for AWS lambda and AWS IoT core.

Regions can be selected at the top right corner in both the consoles. N.Virginia (US EAST region was selected in this project).

4.3.  Creating Lambda function

    1. From AWS home page, open lambda services by navigating through Services -> Compute -> Lambda
    2. Choose to create function -> Author from scratch
      1. Enter a function name.
      2. Choose Node.js 12.x
      3. Leave ‘choose/create execution role’ at default (i.e create a new role with basic lambda permissions).
    3. Once the function is created, add a trigger from Alexa Skills Kit. Enable skill id verification and paste the copied skill id from the Alexa skills endpoint section.
    4. Scroll down to the code function area and copy the code provided as index.js to the console.

                Leave the rest at default.

            5. Modify the lambda function to interact with the ‘thing’ related data in AWS IoT.

                    a. Insert Endpoint of your ‘thing’ from the IoT AWS core.

                        Navigate to Things -> Interact and choose the REST API endpoint in the IoT AWS core.

Figure 3. Thing Endpoint in lambda function

                    b. Change the ‘thing’ name in the lambda function per the thing created in AWS IoT as shown below.

Figure 4. Thing name in lambda function


          6. Copy the ARN of your lambda function. Add this to the default region of AWS Lambda ARN in the Alexa Skills Endpoint.

              This is required for invoking this lambda function when the user interacts with ASK.

4.4.  IAM set up

We need to create an IAM policy that provides the minimum required permissions for Alexa Skills to invoke an AWS Lambda function.

      1. Open IAM from AWS home by navigating to Services à IAM (under Security, Identity, & Compliance)
      2. Select Roles and click on the role corresponding to the lambda function created as shown in figure below.

Figure 5. IAM Roles

(*Exact screenshots may differ)

                    3. Click the policy name under permissions tab. Choose Edit policy.

                        Go to JSON tab and copy the content from the attached policy (IAM policy.json).

                        Click on review policy -> save policy.

4.5.  Creating Subscriber Application

                    1.    Install Mbed CLI and Mbed Serial Port driver. Refer to Mbed documentation for more details.

                    2.   Use the PSoC 6 +4343W Prototyping kit in DAPLink mode. Hold SW3 switch for >2 seconds and release.

                          The status LED (LED2) should ramp up an amber light at 2Hz.

                          If you face any issues in entering DAPLink, ensure the kit has latest KitProg3 firmware.

                          Refer to KitProg3 user guide for more details.

                    3. Clone the Code example ‘mbed-os-example-aws-iot-client’.

                         This example connects to a WiFi network and can subscribe to messages from the AWS cloud using the

                         Mbed OS ecosystem from github.

                    4. Enter the subscriber directory and follow the Instructions below to build AWS IoT subscriber code example.

        a.   Change to the application folder (subscriber)

        b.    Prepare the cloned working directory for mbed by entering the following command in command prompt.

   mbed config root .

        c.     Pull the necessary libraries and its dependencies.

                  This will pull mbed-os, AWS_Iot_Client library and its internal 3rd party dependencies

     mbed deploy

        d.     Configure the SSID and password of the desired network in the mbed_app.json file.

                  Replace the word ‘SSID’ with name of the network and similarly for the password.

        e.    Configure the AWS parameters such as Thing name, certificates, private key per the user's AWS account.

            Use the attached sample_aws_config.h for reference.

        f.      Also, configure the AWS topic to be subscribed to receive the messages.

              The lambda code provided in the example updates to shadow of the ‘thing’.

              We will subscribe to the ‘shadow delta’ to receive the messages.

              Refer to Amazon Documentation on shadows for more details.

        g.   We receive messages from AWS thing shadow in JSON format.

              We will use a JSON library to extract the desired state from the JSON formatted message.

        Download the zip JSON parser and extract the contents.

       Create a folder, say mbed-json-parser inside the subscriber folder and place the extracted .cpp and .h files in that folder.

        h.    Replace the subscriber.cpp file in the subscriber folder with the subscriber.cpp file provided.

        i.     Modify the default AWS packet size to high value.

             This is needed to receive the entire message from the shadow and then extract the required state in our subscriber application.

                This macro is available in

                …\mbed-os-example-aws-iot-client-master\subscriber\aws-iot\aws_client.h file.

                Modify AWS_MAX_PACKET_SIZE to 1000 as shown.

                By default, it is set to 100.

Figure 6. Increasing AWS Packet Size


                             j. Build the project using mbed compile --target CY8CPROTO_062_4343W --toolchain GCC_ARM

                             k. Hex file generated can be found in


        Program the hex file using Cypress Programmer or drag and drop the hex file to the DAPLINK drive.

        Alternately, use mbed compile --target CY8CPROTO_062_4343W --toolchain GCC_ARM -f to compile and program.

5. Testing the project

5.1.  Hardware connections:

CY8CPROTO-062-4343W kit is connected to CY8CKIT-036 as shown.

DGND of both the kits are connected. PWM signal for fan 1(PWM1) is connected to P8.7 in this example.


Figure 7. Hardware set up

5.2.  Test Execution

    1. Set up serial Terminal. Connect to the Mbed serial port with a baud rate of 115200.
    2. Speak out the commands to the Echo device/Alexa simulator. Alternatively, you can type the utterances in the simulator. Alexa simulator is available in the ‘test’ tab of your developed custom skill.

   Ensure to select the same language as in Amazon developer account is selected in Alexa Mobile App while setting up the  Amazon Echo device.

   Refer to the Amazon documentation for more details on testing the custom the skill.

   Eg utterances:

        1. Alexa, ask fan controller to set high speed
        2. Alexa, Set low speed from fan controller
        3. Alexa, ask fan controller to run the fan at medium speed

               In these examples, fan controller is the invocation name.

               This must be used in the sentence to launch the custom skill along with connection words such as ask,tell, from etc.

               Refer to Alexa Documentation for more details on how to invoke custom skills.

5.3.  Expected Outputs:

    1. Fan should run at the desired speed.

            2. Echo device/simulator should respond back with the speed at which the fan is running.

                Note: If expected behavior is not observed when using the Echo device,

                please check if Alexa was able to process your speech correctly.

                In the Alexa App, Navigate to Settings -> Alexa Privacy -> Review Voice History to check your interactions with Alexa.

            3. Alexa Simulator Output

                Enter test tab and type the utterance. Alexa skills responds with the output as shown in figure below.

Figure 8. Alexa test (Simulator)


          4. AWS IoT Output

              Enter the activity tab and observe the shadow state being updated as shown.

Figure 9. AWS IoT shadow

        5. Serial Terminal Output

Figure 10. Tera Term Output


Thank you! Enjoy controlling physical devices using PSoC 6 + 4343W through Alexa!

Filter Blog

By date:
By tag: