PSoC6 devices have multiple types of protection units to control erroneous or unauthorized access to memory and peripheral registers.

• CM4 and CM0+ have ARM MPUs for protection at the bus master level.
• Other bus masters (Crypto and Test Controller) use additional MPUs designed by Cypress similar to ARM MPUs.
• Shared memory protection units (SMPUs) help implement memory protection for memory/ resources that are shared among multiple bus masters.
• Peripheral protection units (PPU) that are designed for protecting the peripheral register space.

We will be learning mostly about SMPU in this blog, but most of the things apply to the PPU as well. Irrespective of the type of protection unit you intend to use, they are defined by the same fundamental structure:

• Address region
• Access control attributes

The address region is defined by:

• The base address of a region as specified by ADDR.ADDR
• The size of a region as specified by ATT.REGION_SIZE
• Individual disables for eight sub-regions within the region, as specified by ADDR.SUBREGION_DISABLE

Whenever you define any address region, you need to take care that the base address is aligned with the region size. For example, if you define the base address as 0x1002_0000 it is 128KB aligned, but not 256KB or higher byte aligned. This means that you can use 0x1002_0000 as the base address only if the region size you define is 128KB or lesser to be protected.

To calculate if a memory address is aligned with the region size, find out where the first bit is 1 from the LSB. For example, for base address 0x1002_0000 the binary value is:

0001 0000 0000 0010 0000 0000 0000 0000

The position of 1 here is at index 17 counting from 0 and the value of 2^17 is 128KB. So, it is 128KB aligned at max. It is also 64KB, 32KB, …. 2B aligned but max 128KB.

Specifying a value that is invalid causes the base address to automatically change according to the region size specified. For any device, the flash usually starts from 0x1000_0000. Check the Architecture TRM of the particular device for more information on the memory organization.

If the base address is defined as 0x1002_0000 (128KB aligned) and the region size is set as 512KB, then since the base address is not aligned, all the bits [0:18] will be ignored and only bits [19:31] will be taken into consideration. This means that the invalid region size causes the base address to be set as 0x1000_0000. Note that 0x1000_0000 is aligned with all region sizes max being 2^28 = 256MB aligned.

The region to protect is always a power of 2 in the range of [256B to 4GB]. Check Architecture TRM of your device for these range values.

Let’s say you want to protect the memory region between 0x1002_0000 to 0x1006_0000. How do you do it?

First, find out the memory alignment of the starting address.

0x1002_0000 is 128KB aligned. The region size between 0x1002_0000 to 0x1006_0000 is 0x40000 (256KB). Even though the region size to be protected is 256KB, you can only set the region size for the SMPU to be 128KB max to adhere to the alignment with the base address. So, you cannot use this address as the base address.

You need to select another base address such that:

• It has a higher byte alignment (>128KB)
• It is lower than the lower address you want to protect (i.e 0x1002_0000)
• The region size covers the highest address (i.e 0x1006_0000)

This leaves us with one option. Using 0x1000_0000 as the base address and setting the region size as 512KB.

So, configure an SMPU with the base address as 0x1000_0000 and region size as 512KB. Now how do you protect just the region between 0x1002_0000 and 0x1006_0000?

The region size you define for an SMPU is divided into 8 equal sub-regions. In this case, 512/8 = 64KB sub-region. So, the 8 sub-regions will have the address mapping as shown:

The sub-regions 2 to 5 cover the regions that we intend to protect. So the sub-regions value 0xC3 (1100 0011) is chosen below where the value 1 in the bit means the region to be disabled or unprotected.

The SMPU structure cy_stc_smpu_cfg_t is used to configure the SMPU parameters. It will be defined as follows:

static const cy_stc_smpu_cfg_t flash_protect = {

          .address = (uint32_t *) 0x10000000,            

          .regionSize = CY_PROT_SIZE_512KB,                

          .subregions = 0xC3,                               

          .userPermission = CY_PROT_PERM_RX,             

          .privPermission = CY_PROT_PERM_RX,

          .secure = false,

          .pcMatch = false,

          .pcMask =  CY_PROT_PCMASK1

};

The .userpermission and .privpermission protection attributes implement a protection scheme to distinguish between read/write or execute access to a specified memory region by a user code or privileged code. The privilege code is typically the kernel code in an RTOS environment.

The .secure protection attribute distinguishes if accesses by a secure processor are enabled or not.

The same logic applies for PPU and MPU, it all depends on where the memory region belongs, and which protection unit will be the most suitable. You can use SMPU to protect peripheral memory spaces, it is not a problem, but PPU is available only for the protection of peripherals and could have been used instead.

Once the structure is defined you need to call the following PDL APIs:

Cy_Prot_ConfigSmpuSlaveStruct(PROT_SMPU_SMPU_STRUCT2, &flash_protect);

Cy_Prot_EnableSmpuSlaveStruct(PROT_SMPU_SMPU_STRUCT2);

The index of the structure highlighted above is used to define the priority of the SMPU. Here the priority is 2.

There are 15 SMPUs that you can use in PSoC6 to protect a memory region. In cases where you have two SMPUs protecting the same region, the priority is for the SMPU structure with the highest number. The highest SMPU priority is 15 and the lowest is 0.

Next, we need to configure the Protection Units and the Bus Masters. A protection unit is a hardware block that implements the protection scheme. Each protection unit has one or more protection structures associated with them. A protection structure is a group of registers which define a memory region (address and size) and a set of protection attributes that are to be applied to it.

Protection Context (PC) provides a more precise way of applying memory restrictions. A bus master with a Protection Context 0 can access any memory or register region no matter how the protection units are configured. PC=0 is a special case that allows any bus master to have full access to the entire memory space including registers.

The PC state works together with protection units (SMPU, PPU). Each of the protection units has a field called .pcMask which is used to specify which protection context can have access to the memory region.

There are six bus masters in PSoC6:

• CM0+ Core
• CM4 Core
• Crypto Block
• DataWire0 (DMA)
• DataWire1 (DMA)
• Test Controller (TC)

Their macros are available through the enum en_prot_master_t.

typedef enum

{

        CPUSS_MS_ID_CM0                 =  0,

        CPUSS_MS_ID_CRYPTO          =  1,

        CPUSS_MS_ID_DW0                 =  2,

        CPUSS_MS_ID_DW1                 =  3,

        CPUSS_MS_ID_CM4                 = 14,

        CPUSS_MS_ID_TC                    = 15

} en_prot_master_t;

You can assign a particular PC using the API shown below where the CM0+ is assigned the PC 1.

Cy_Prot_ConfigBusMaster(CPUSS_MS_ID_CM0, false, false, CY_PROT_PCMASK1);

To activate the PC, you will need to call:

Cy_Prot_SetActivePC(CPUSS_MS_ID_CM0, CY_PROT_PC1);

Let’s say you have defined an SMPU memory region as follows:

static const cy_stc_smpu_cfg_t main_flash_prot_cfg_s = {

        .address = (uint32_t *) 0x10000000,

        .regionSize = CY_PROT_SIZE_512KB,                

        .subregions = 1,                               

        .userPermission = CY_PROT_PERM_RX,             

        .privPermission = CY_PROT_PERM_RX,

        .secure = false,

        .pcMatch = false,

        .pcMask =  CY_PROT_PCMASK1 | CY_PROT_PCMASK2  

};

All the values in the above snippets like CY_PROT_PERM_RX, CY_PROT_SIZE_512KB, etc. are macros that are already defined internally. You don't need to define them.

This memory region protected by the SMPU as defined above provides access to only bus masters that have the PC value of 1, 2, and 0. To understand this better, find the project “PSoC6_Memory_Protection.zip” attached with this blog. The project demonstrates how you can protect a memory region in the CM0p memory space from being accessed by CM4. The project details can be found in the ReadMe PDF file in the project folder.

See if you can relate your understanding with the project implementation!

Now here’s something interesting to know and try. Although it seems like we have protected the memory regions of CM0p from being accessed by CM4 in the project, we have not protected the PC Mask registers themselves. Any of the bus masters can change this and set their current PC mask value to whatever they want and have access to the required memory regions.

So, usually, you would set up all the memory protections and also protect the PC Mask registers while CM0p is still PC=0 and then switch the bus master to something other than PC=0. That way you have locked the door and thrown away the key

Stay tuned for the next blog that reveals how you can do this! For clues, use the Protection Units section in the PSoC6 Architecture TRM.

The attached document contains a project based on AN83902 that contains the implementation of the MDIO Interface component for PSoC 6.

Hello! Here's some information on the multi-counter watchdog (MCWDT) resource in the PSoC 6 architecture.

PSoC 6 actually has multiple watchdogs - a single basic watchdog timer (WDT) and one or more multi-counter watchdogs (MCWDT). Each MCWDT has three counters, two of which can generate a watchdog reset. However, if you use the WDT for the basic watchdog function, then all of the MCWDT counters are available for general counter/timer functions such as measuring time between events and generating periodic interrupts.

Note that the counters can be cascaded, allowing you to create combinations of 16-, 32-, 48-, and 64-bit counters.

All watchdog timers - WDT and MCWDT - are clocked by the 32.768-kHz ClkLf.

Feel free to leave comments and ask questions, we appreciate the feedback!

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

Hardware:

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)

Software:

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.

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.

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

            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

                                 …\mbed-os-example-aws-iot-client\subscriber\BUILD\CY8CPROTO_062_4343W\GCC_ARM.

        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!

Prerequisites:

Hardware – CY8CKIT-062-WIFI-BT/CY8CKIT-062-BLE/CY8CPROTO-063-BLE

Software/IDE – PSoC Creator 4.3 and PDL 3.1.1

Introduction: 

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.
  

Note:

• 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.
  

Hello!

Thought I'd introduce the PSoC 6 Character LCD (CharLCD) feature.

PSoC 6 supports a Character LCD (CharLCD) which follows the Hitachi 44780 4-bit interface. The enhanced features of PSoC 6 have no limitation of pin assignment other than a group of seven sequential pins, and it supports the multiple "E" signals for the multiple CharLCDs, as shown in the figure below. The key difference of driver is that the PSoC 6 CharLCD is a part of Cypress' Peripheral Driver Library(PDL), so it can be used with other IDEs.

Some of the key features are the following:

• Implements the industry-standard Hitachi HD44780 LCD display driver chip protocol
• Support multiple "E" signals (Support multiple CharLCDs)
• Requires seven I/O pins for one CharLCD and eight I/O pins for two CharLCDs
• Displays text data using predefined character in CGROM
• Displays eight custom characters
• Displays horizontal or vertical bar graphs

Feel free to leave comments and ask questions, we appreciate the feedback!

We are pleased to announce that PSoC 6 MCUs are supporting AliOS Things, an embedded RTOS for the IoT market!

AliOS Things is Alibaba's IoT version of AliOS Family, and is an embedded RTOS for the IoT market.
AliOS Things targets designing turnkey solutions for IoT infrastructures, with  high-performance, simplicity, security, cloud integration, and rich components . Furthermore, it natively supports the connection between smart devices and the Alibaba Cloud system; therefore it can be widely applied in smart home, smart city, and next-generation travel.

Cypress’ PSoC 6 MCUs is supporting AliOS Things RTOS now, and designers can use PSoC 6 MCUs to design wireless systems to connect to the Alibaba Cloud for their IoT devices.

To find out more and get started, view the “Getting Started” Guide attached to this post and also visit AliOS-Things/platform/mcu/cy8c6347 at master · alibaba/AliOS-Things · GitHub .

In addition, we have AliOS Things support for our PSoC 4 MCUs. To find out more, check out this blog post.

Lastly, feel free to leave your comments and feedback, we appreciate that!

FreeRTOS is a class of RTOS that is designed to be small enough to run on a microcontroller - although its use is not limited to microcontroller applications. It provides the core real time scheduling functionality, inter-task communication, timing and synchronization primitives only. This means it is more accurately described as a real time kernel, or real time executive. Additional functionality, such as a command console interface, or networking stacks, can then be included with add-on components.

Cypress’ PSoC 6 MCUs is supporting FreeRTOS and designers can develop PSoC 6 MCU systems for IoT applications.

See it in a PSoC 6 project here, FreeRTOS for PSoC 6 MCUs.

Also, check out code examples and articles based on FreeRTOS.

Lastly, if you have any feedback, comments, or questions, feel free to leave them here, we appreciate the discussions!

Hello,

Here is an update on the PSoC 6 I2S feature we have.

PSoC 6 has one I2S hardware block able to produce/receive digital audio streaming data to/from external I2S devices, such as audio codecs, microphones or simple DACs. The frames generated by the IP can be configured to generate data word length of 8-bit/16-bit/18-bit/20-bit/24-bit/32-bit per channel. The channel length is also configurable. The hardware IP provides two hardware FIFO buffers, one each for the Tx block and Rx block. Any writes and reads to/from the FIFOs can be handled by DMAs or CPU.

The overall I2S block diagram it shows below.

Feel free to leave comments and ask questions, we appreciate the feedback!