Skip navigation
Home > All Places > Topics > Cypress Community Blogs > ModusToolbox Blog > Blog > 2020 > July

In the previous blog, I shared the PSoC Creator projects to interface a PSoC 6 device with the DHT-11 sensor. The previous blog also covered details regarding the DHT-11 sensor and its working. In this blog, we will be creating the project on ModusToolbox 2.1 to achieve the same functionality with a few additional features. You can download ModusToolbox 2.1 here and learn about the new exciting features of ModusToolbox 2.1 release here.


We will start by creating an Empty_PSoC6_App. You can create a new project by clicking on New Application in Quick Panel. Select the BSP of your choice. I will be using the CY8CPROTO-062-4343W Kit for this blog. Select the Empty_PSoC6_App, you can rename the project if needed. Click on Create. You can even create the project using the CLI option which you can learn more about here.


Now that we have an empty project ready, we need to add the libraries that we will be using for this project. In this project, we will be using the retarget-io and the FreeRTOS middleware libraries. To do that, click on Library Manager under Tools in the Quick Panel and select retarget-io (under Board Utils) and freertos (under PSoC 6 Middleware) as shown. You can now build the project to confirm that there are no errors so far. The ‘project directory’ is now the ‘application directory’. So, in this case, the application directory will be the folder Empty_PSoC6_App or the name of your application in case you have renamed it.

I have predominantly used the code from the Temperature_Sensor_Direct project from my previous blog. The PSoC Creator project was created using PDL. The project would still work if I just copy the entire code and place it in the main.c file. All I have to do is select the right pin in the Device Configurator and name it accordingly. But the problem here is that this makes my project device-dependent. What I mean by this is that if at all I change my device, I will have to reconfigure the pin.  With the release of ModusToolbox 2.0 and 2.1, you would have noticed most of us talk about ‘device agnosticity’. The idea is that the project should work without any changes even when the device is changed. If you are just curious and you want to try out your project on all your devices or if you are as fickle-minded as I am you will soon realize that this is a lifesaver, especially in a project that uses a lot of hardware blocks.


To achieve that, I will be using the Hardware Abstraction Layer (HAL) and the Board Support Package (BSP) feature. HAL allows me to easily initialize all my hardware resources in my source code and BSP takes care of the pin allotment of some of the common resources in each device. For example, if I have to use an LED that is on my kit, I can just use the CYBSP_USER_LED macro. This macro is defined specific to each device. Now even if I change my device, I can be assured that I will be using the appropriate LED pin itself. I will be talking in detail about how these features are used in the project when going through each of the source files.


In this project, I have also used FreeRTOS to create separate tasks so that each task can just be picked up and used in any FreeRTOS project.


To keep the code modular and perspicuous, I have separated the application into three source files –

  • main.c
  • print_task.c
  • dht_task.c


main.c file contains the initialization code and the task creation code. You can consider this as the master code and in this file, the FreeRTOS scheduler is started. All the pin/middleware initialization code can be found here. The code first initializes the device and board peripherals and the hardware manager. Next, the retarget-io is initialized. Retarget-io allows you to transmit messages to and from the board via standard printf/scanf functions using a UART SCB block. Just by including cy_retarget_io.h file and initializing the middleware you can use printf and scanf statements directly. So, it saves the time and effort needed to manually map the printf/scanf functions to the UART block. The DATA pin is initialized as shown below –

Each HAL API starts with cyhal followed by the name of the driver and then the functionality. In this case, the API initializes a GPIO pin. The LED is also initialized in a similar way. You can refer to the following link to learn about the different HAL drivers and their usage: HAL Documentation.

The next part is the initialization of FreeRTOS objects. A queue is used for communication of sensor readings between the tasks. The queue-handle is passed as an argument to the tasks. The two tasks, namely, DHT_Task and Print_Task are created with DHT_Task having a higher priority.


Moving on to dht_task.c file. As I have mentioned before, this primarily consists of the code used in the Temperature_Sensor_Direct project. I have changed the PDL functions to its HAL counterparts –

  • CY_GPIO_Write()         =>      cyhal_gpio_write()
  • CY_GPIO_Read()         =>     cyhal_gpio_read()
  • CyDelay()                       =>     cyhal_system_delay_ms()
  • CyDelayUs()                  =>      cyhal_system_delay_us()

The task reads the sensor values and if the value is valid, an LED is toggled, and the readings are sent to a queue. If the queue is full, the task will wait until the queue has a vacancy.  Now in case there is a connection failure or the sensor values read are not valid, the error code along with the previous data is sent to the queue. As the sampling rate of the sensor is approximately 2 seconds the task then goes into the blocked state for 2 seconds. After this, the cycle repeats.


print_task.c, as the name suggests, contains the Print_Task function. This task has the lowest priority and executes only when all other tasks are in the blocked state. It receives the sensor reading from the queue and prints the value into the serial terminal. If the queue is empty, the task enters the blocked state until DHT_Task sends the reading to the queue.


I have attached all the .c/.h files, put in source folder, with this blog. You can go ahead and place this folder in the application directory of the new project that you created and delete the default main.c that was in the project. That’s it! The auto-discovery feature in ModusToolbox will take care of the rest. No more ‘Add to Project’!


You can build the project, program the device, and connect the sensor and voila! you now have a simple FreeRTOS project to read the temperature and humidity value using the DHT-11 sensor and print it on a serial terminal. The best part is that it is a ModusToolbox 2.1 project! For your reference, the entire project is shared on our Community Code Examples Git Repo and you can check it out using this link. To know how to import the project, refer to the ReadMe file.


Hopefully, by now you will have a basic idea on how to use ModusToolbox 2.1 to develop simple FreeRTOS applications.


Here are a couple of things you can do next:

> Try changing the BSP in Library Manager and programming a different device to check out the device-agnostic feature.

> The task is in the blocked state for 2 seconds which means that the PSoC 6 is in the idle state most of the time. You can try exploring the low power capability of PSoC 6. Keep in mind that you should be using the Tickless Idle Mode capability of FreeRTOS for this to work. You can use this code example for reference - CE223508 – PSoC 6 MCU Implementing BLE Multi-connection (4 Slaves)

> You can combine this task with any other FreeRTOS task and create an application. Feel free to post your cool applications and share them with the community!


Welcome to the fourth session of the ModusToolbox Training Series!


In the previous Session 3: Introduction to CapSense in ModusToolbox , we learnt about CapSense in ModusToolbox and how to built basic CapSense applications using CapSense Middleware Library.

In this session, we are going to introduce you to the AnyCloud WIFI Design Flow. The session starts with a brief introduction to different software architectures (Mbed, AFR and AnyCloud), followed by AnyCloud Stack. You will get insights on how to build basic WiFi application in Modus Toolbox using the WiFi Connection Manager Library. You will also learn about the required libraries or the minimum set of libraries for getting started with WiFi (WCM, WiFi Middleware Core, Secure Sockets, WHD). In the end, an interesting demo project will help you create your own basic TCP application in Modus Toolbox. Let’s get started!


Duration: 90 mins



The exercises created as part of this training series have been tested to work on the following boards. The exercises might need minor modifications if being used for a different board.





1.  Software Architecture – AnyCloud / AFR / Mbed

2.  AnyCloud Stack

3.  AnyCloud WiFi Libraries

        a. Using Library manager to add Wi-Fi to a PSoC 6 project in AnyCloud

        b. Middleware Core Libraries

        c. Wi-Fi Connection Manager (WCM)

        d. Secure Sockets

4.  WICED Wi-Fi Driver

5.  WHD WiFi Host Driver

6.  Demo – TCP Client

7.  Abbreviations

8.  References


Using the Training Material:

The presentation used in the video is attached to the blog. Jump to 2:08 in the video to get started with the session.






The training material and exercises are hosted here: Community-Code-Examples/mtb_training/session04 at master · cypresssemiconductorco/Community-Code-Examples · GitHub

You can also refer to the documentation tab in the MODUS toolbox that gives you more insights on all the required WiFi libraries (Secure Sockets, WHD, WCM and Middleware Core Library).



Have any Questions?

Feel free to drop in your queries in the Cypress Developer Community.

ModusToolbox supports various build tools used to build the application. ModusToolbox currently uses GCC version 7.2.1 by default. To specify a different toolchain, normally you can modify the file "Makefile" which is under the root directory of your project in ModusToolbox and set the variable "TOOLCHAIN" to other supported values. See below:

Currently ModusToolbox officially supports 3 options: GCC_ARM, ARM and IAR. If you specified ARM or IAR, the correspondent toolchain should be installed by yourself as prerequisite. And you should also specify the path to the desired toolchain using the variable "CY_COMPILER_PATH". See below:

For the most concerned details, please refer to ModusToolbox™ User Guide, Document Number: 002-29893. This blog is intended to give extra information on this.


As we all know, ModusToolbox supports two categories of projects: PSoC 6 projects and WICED Bluetooth projects. One important finding is that the actual supported options may differ according to the project type. To find out the actual supported options of your project, you can execute the following command (within the Cygwin environment and change the working directory to your project directory):


For example, under PSoC 6 projects I got the following result:

The result shows that it actually supports 4 options: GCC_ARM, IAR, ARM, and A_Clang.

But under WICED Bluetooth projects, I got the following result:

The result shows that it only supports 1 option: GCC_ARM.

So if you are facing problems using other toolchains, before you proceed, you can check whether your project actually supports the toolchain you desired, using the command given above.

Filter Blog

By date:
By tag: