This is an example of the  8-bit PCM audio playback on PSoC4200M CY8CKIT-044 Pioneer Board using Double-Buffered DMA.

Unlike the previous example, which used single-buffered DMA to update the IDAC8, this project is using a Double-Buffered DMA to transfer the data. This has several benefits, compared to previous example:
     - No limitation on the audio data size.
     - Possibility to mix data from several data sources or manipulate the data
     - Seamless data output (no interruptions).

The drawback of the approach is certain processor load, which has to repeatedly populate the Buffer with fresh data. This load, however is much lower compared to using direct interrupt write without DMA. 

The Double-Buffered DMA uses intermediate RAM Buffer of size 2N=64 bytes made of two equal halves, to store the data coming from the data source. The DMA1 consists of two chained Transfer Descriptors TD0 and TD1, which copy data byte-by-byte from the Buffer to the temporary RAM location (TMP). Once TD0 finishes copying the data from the first half of the Buffer, it chains to the TD1, which copies data from the second half of the Buffer and loops back to TD0. In this demo, the Buffer size is 64 bytes. Actual size should be set depending on the latencies of the processor, but 128+128 is typically a good size. Project dataflow:

Once TD0 (or TD1) is completed, an interrupt is fired, signaling that this Buffer half needs replenishment (while the other one is busy). At this point processor need to copy fresh portion of the data from the data source (here it is a FLASH), and  wait for the next data request, while the Buffer content is being continuously played without interruption. 

The data source can be RAM, FLASH, SD card, or processor generated data (sine, etc.).  

To get the data to the IDAC8, the 8-bit data is first copied by DMA1 from the Buffer into intermediate (16-bit) location in RAM, where the MSB keeps IDAC control settings, and LSB has the data. The DMA2 then transfers 2 bytes {MSB, LSB} to the IDAC8 control register. Such intricate scheme is required because the DMA transfer to the IDAC is always 16-bit, thus the attempt to send only the data byte wipes off the IDAC control settings.      

The project is configured to play on startup the Sawtooth test waveform  in the continuous loop. Optionally, it can be configured to play a single time by enabling the SINGLE_SHOT directive.

The audio data are stored in the PSoC FLASH in 8-bit unsigned PCM format. Attached project includes several test PCM audio files in 8-bit unsigned format:
sawtooth_8-bit_S.h                             - test sawtooth, 8-bit, Unsigned (size= 256 bytes)  
smb_world_clear_5k5_N_U.h        - Super Mario theme, 5.512kHz, Normalized, Unsigned (size=33600 bytes)
smb_world_clear_11kHz_N_U.h   - Super Mario theme, 11.025kHz, Normalized, Unsigned (size=65536 bytes)
smb_world_clear_22kHz_U.h        - Super Mario theme, 22.05kHz, Unsigned (size=65535 bytes, clipped)

The WAV files have been converted to the C code using  WAVtoCode v1.1.1 by Colin Seymour. The original WAV data have been Normalized to fill the entire 8-bit scale, which has increased the dynamic range.

Project attached contains all necessary files. It was tested using both Creator 4.0 and 4.4.

Credits:
     WAVtoCode v1.1.1 by Colin Seymour:         https://colinjs.com/software.htm#t_WAVToCode

Figure 1. Project schematic. The PCM data are copied from the FLASH to the Buffer by code, and then from Buffer to the  IDAC using chained DMA. The IDAC is configured as a Source. The IDAC current is converted into voltage using 3.3k load resistor buffered by the Opamp in the follower mode, producing 0-1V signal at full scale.. For sound generation, the output is directly connected to the headphones with combined impedance of 64oHm (32+32).

Figure 2. Project annotation using the PSoC Annotation Library v1.0 and KIT-044. The Opamp output is directly loaded on the headphones with combined impedance of about 64oHm (32+32).

Figure 3. Output waveform on startup. The test data is Sawtooth, 256 points per period, played in the loop continuously.

Figure 4. Sawtooth waveform output when configured for a SINGLE_SHOT. The number of data points is 256, played once. After the end of data, the output can be set to some pre-defined value (here is 127).

Provided below is the SerialRx v0.0 component implementing simple command line interface between UART Terminal and PSoC microcontroller.

Using this component, human-readable UART Terminal messages can be easily received and processed by the microcontroller. Component is, in essence, a software library, which splits the incoming stream of bytes into individual control messages using standard termination characters.

Component features:

* Compatible with PSoC4 SCB UART and PSoC5 UART
* Optional external or internal interrupt mode
* Standard \n and \r termination characters
* Optional Comma, Space and Tab separators

Component can be useful for process control or parameters update, such as: PID tuning, setting control voltages, PWM frequency, etc. Component is compatible with Creator 4.0 and Creator 4.4, and was tested using CY8KIT-059 PSoC5LP Prototyping Kit and CY8KIT-044 PSoC4M Pioneer Kit. Demo projects are provided.

Attached archive contains component library, component datasheet and several demo projects for PSoC4 and PSoC5. Please read installation instructions in the readme.pdf.

Credits:
     Bob Marlowe (Cypress, ret.)

Figure 1. PSoC4 SCB UART basic project schematic using SerialRx. The Component receives messages from the Terminal and turns RGB LED on/off. Both SCB UART and SerialRx are configured for internal interrupt mode.

Figure 2. Terminal window showing command messages and PSoC4 responses. Recognized commands ('R_ON') are executed with confirmation echo sent back ('>R_ON'). Unrecognized commands ('foo') are ignored and an error status is reported ('!foo').

Id like to share this project, made a custom component, at the moment it is only enabled for PSoC4 but it can surely work with any other with minor changes( on PSoC 6).

the Communincation to the WS2812

no hardware blocks used

Github Repo:

PSoC_Neopixel 

The evaluation board, CYBT-343026-EVAL, is not recognized even when inserted into a computer. There seems to be no driver software.

The board contains a USB Serial dual channel bridge controller (CY7C65215-32LTXI).

If you know how to install and enable the driver, please let me know.

Overview

Simple example to demonstrate a Master SPI configuration where the data movement is done with DMA channels (One for Master Transmit and the other Master Receive).

This project is using a standard ADS configuration and iLLD's. However the configuration of the QSP1, DMA channels 3 and 4 along with the ports are implemented in code as bare metal.

Description

In this code example, QSPI1 is configured as a master SPI. DMA channel 3 is used to transmit the data packet whereas DMA channel 4 is used to receive the data packet (SPI is use in full duplex mode. In this example the MTSR pin it externally connected to the MRST pin as there is not a real SPI slave device). The code directly accesses the registers for the QSPI and DMA. It doesn't use the iLLD's for these peripherals.

Clocks

* The system clock (PLL) is configured to run at 300MHz.
* The system peripheral bus is configured to run at 100MHz.
* The QSPI clock is fSOURCE2 configured to run at 200MHz.

Peripherals

* QSPI1
* DMA

Details to the Demo
The QSPI is operated in "Short Data Continuous Mode" When using this mode the transfer requires that you write two BACON entries. The first write is to begin the data exchange and ensure the LAST=0 at the start of the data transfer (it can also be used to remove any delay between the data on the bus). The other BACON write is used to close the data transfer before the last data value is written (i.e. LAST=1). In this example the DMA transmit interrupt is used to to write the last BACON and data value to complete the data exchange. Therefore the DMA transfer count for the TX is always one less than the receive DMA transfer count.

The SPI data exchange is initialized  by writing the BACON word to the BACONENTRY register. This will cause the Tx DMA to send its data until the transmit count is zero. The receive DMA is also triggered by data being received from the QSPI. When both DMA counts go to zero interrupts are raised for the CPU.

The demo assumes you have data buffers of "8-bits" in size that are aligned on word boundaries. Where you have the choice to transfer the data using the DMA with either 8-bit, 16-bit or 32-bit width transfers. The QSPI and DMA will handle the choice from the below define "QSPI_DL" define. Additionally the QSPI will handle the Endianess of the bytes in both directions.

#define DMA_CH_SIZE_INT8 0
#define DMA_CH_SIZE_INT16 1
#define DMA_CH_SIZE_INT32 2

/*change this for the size of the DMA transfer, the endianess is handled by the QSPI */
#define QSPI_DL DMA_CH_SIZE_INT8

To RUN

When connected to a debugger you can set the variable "test=1" to kick off the SPI data exchange.

Scope plots

Example of one data exchange on the Master QSPI

* (channel 1, white) is P11.6 QSPI1 Master Clock Output
* (channel 2, tan) is P11.9 QSPI1 Master Transmit Output
* (channel 3, red) is P11.3 QSPI1 Master Receive Input B
* (channel 4, brown) is P10.5 QSPI1 Slave Select Output 9 (ECON1)

#define QSPI_DL DMA_CH_SIZE_INT8

#define QSPI_DL DMA_CH_SIZE_INT32

Hi,

Is there way to update the "Firmware Revision String" field in the GATT Device Information service at runtime? I can set the value using bt-configurator,  but the actual firmware revision is set as part of our build pipeline so manually editing the value is not an option.

There's the `Cy_BLE_GATTS_WriteAttributeValueLocal()` function that looks promising, but I can seem to find the right attribute handle to use.

This code example can be used for interfacing of XENSIV^TM Photoacoustic Spectroscopy (PAS) CO2 sensor with PSoC6 via I2C using available PSoC6 library. The document then explains the extension of the implementation to a CO2 traffic light.

Introduction

The document describes the procedure to interface XENSIV™ PAS CO2 sensor with PSoC6 evaluation board. The basic implementation covers the interfacing the sensor with PSoC6 and the CO2 levels measured is printed in the serial terminal. In this article based on the measured CO2 levels, three LED’s of different colors (green, orange/yellow and red) are individually turned on.

Hardware

The hardware required for the implementation are

1. PSoC™ 6 Wi-Fi Bluetooth® pioneer kit
2. XENSIV™ PAS CO2 mini-evaluation board or XENSIV^TM PAS CO2 Shield2Go board

Figure 1. (a) XENSIV™ PAS CO2 Mini Evaluation Board (b) XENSIV™ PAS CO2 Shield2Go board

The setup using PAS CO2 mini evaluation board can be understood from the figure shown below.

 Figure 2. Wiring connection for interfacing XENSIV^TM PAS CO2 mini-evaluation board with PSoC™ 6 Wi-Fi Bluetooth® pioneer kit via I2C

The 12 V required for the sensor operation needs to be supplied externally. Please also keep the ground common in all the connections to ensure proper functionality.

PAS CO2 Shield2Go board can be used instead of the mini-evaluation board. The Shield2Go board can be interfaced with the PSoC™ 6 Wi-Fi Bluetooth® pioneer kit as shown in the figure below. Here the advantage is that there is no need for providing 12 V externally.

Figure 3. Wiring connection for interfacing XENSIVTM PAS CO2 Shield2Go board with PSoC™ 6 Wi-Fi Bluetooth® pioneer kit, via I2C

Once the hardware setup is ready, using any of the above options, please proceed to the software setup mentioned in the next section.

Software Setup

Steps required for the software implementation are listed below

Step 1: Please follow the steps from https://github.com/Infineon/sensor-xensiv-pasco2 to have the initial software setup in Modus Toolbox

Step 2: Include the following code for defining the GPIO pins for controlling red, yellow/orange and green LEDs. The calculated CO2 ppm values needs to be compared and used to determine the states of LED’s. For that purpose, a comparator loop can be added as shown below.

#include "cyhal.h"
#include "cybsp.h"
#include "cy_retarget_io.h"
#include "xensiv_pasco2_mtb.h"

/*******************************************************************************
* Macros
*******************************************************************************/
#define PIN_XENSIV_PASCO2_I2C_SDA   	CYBSP_I2C_SDA
#define PIN_XENSIV_PASCO2_I2C_SCL   	CYBSP_I2C_SCL

#if defined(USE_CYSBSYSDEV_KIT_01_WINGBOARD)
/* Output pin for sensor PSEL line */
#define PIN_XENSIV_PASCO2_PSEL   		P5_3
/* Output pin for PAS CO2 Wing Board power switch */
#define PIN_XENSIV_PASCO2_POWER_SWITCH  P10_5
#endif

#define I2C_MASTER_FREQUENCY        	(100000U)

/* Wait time for sensor ready (milliseconds) */
#define WAIT_SENSOR_RDY_MS          	(2000)

/* The CO2 concentration value acquired by the sensor depends on the external atmospheric pressure.
   To compensate for this effect, pressure values can be acquired from a pressure sensor such as an
   Infineon XENSIV™ DPS3xx. (https://github.com/Infineon/sensor-xensiv-dps3xx) */
#define DEFAULT_PRESSURE_REF_HPA        (0x3F7)     /* Default atmospheric pressure to compensate for (hPa) */
/*Defining GPIO pins for LEDs*/
#define PIN_R           P9_1
#define PIN_Y           P9_4
#define PIN_G           P9_7

 /***********************************/

/*******************************************************************************
* Global Variables
*******************************************************************************/
static cyhal_i2c_t cyhal_i2c;
static xensiv_pasco2_t xensiv_pasco2;

int main(void)
{
	/*Initializing GPIO pins for LEDs*/
	cyhal_gpio_init(PIN_R, CYHAL_GPIO_DIR_OUTPUT,CYHAL_GPIO_DRIVE_STRONG, false);
	cyhal_gpio_init(PIN_Y, CYHAL_GPIO_DIR_OUTPUT,CYHAL_GPIO_DRIVE_STRONG, false);
	cyhal_gpio_init(PIN_G, CYHAL_GPIO_DIR_OUTPUT,CYHAL_GPIO_DRIVE_STRONG, false);

	cy_rslt_t result = CY_RSLT_SUCCESS;

    /* Initialize the device and board peripherals */
    result = cybsp_init();
    CY_ASSERT(result == CY_RSLT_SUCCESS);

    __enable_irq();

    /* Initialize retarget-io to use the debug UART port. */
    result = cy_retarget_io_init(CYBSP_DEBUG_UART_TX, CYBSP_DEBUG_UART_RX, CY_RETARGET_IO_BAUDRATE);
    CY_ASSERT(result == CY_RSLT_SUCCESS);

    printf("XENSIV PAS CO2 Example\r\n");

    /* Initialize I2C */
    cyhal_i2c_cfg_t i2c_master_config = {CYHAL_I2C_MODE_MASTER,
                                         0,
                                         I2C_MASTER_FREQUENCY};

    result = cyhal_i2c_init(&cyhal_i2c, PIN_XENSIV_PASCO2_I2C_SDA, PIN_XENSIV_PASCO2_I2C_SCL, NULL);
    CY_ASSERT(result == CY_RSLT_SUCCESS);

    result = cyhal_i2c_configure(&cyhal_i2c, &i2c_master_config);
    CY_ASSERT(result == CY_RSLT_SUCCESS);

#if defined(USE_CYSBSYSDEV_KIT_01_WINGBOARD)
    /* Initialize and enable PAS CO2 Wing Board I2C channel communication*/
    result = cyhal_gpio_init(PIN_XENSIV_PASCO2_PSEL, CYHAL_GPIO_DIR_OUTPUT, CYHAL_GPIO_DRIVE_STRONG, false);
    CY_ASSERT(result == CY_RSLT_SUCCESS);

    /* Initialize and enable PAS CO2 Wing Board power switch */
    result = cyhal_gpio_init(PIN_XENSIV_PASCO2_POWER_SWITCH, CYHAL_GPIO_DIR_OUTPUT, CYHAL_GPIO_DRIVE_STRONG, true);
    CY_ASSERT(result == CY_RSLT_SUCCESS);
#endif

    cyhal_system_delay_ms(WAIT_SENSOR_RDY_MS);

    /* Initialize PAS CO2 sensor with default parameter values */
    result = xensiv_pasco2_mtb_init_i2c(&xensiv_pasco2, &cyhal_i2c);
    if (result != CY_RSLT_SUCCESS)
    {
        printf("PAS CO2 device initialization error");
        CY_ASSERT(0);
    }

#if defined(USE_CYSBSYSDEV_KIT_01_WINGBOARD)
    /* Configure PAS CO2 Wing board interrupt to enable 12V boost converter in wingboard */
    xensiv_pasco2_interrupt_config_t int_config =
    {
        .b.int_func = XENSIV_PASCO2_INTERRUPT_FUNCTION_NONE,
        .b.int_typ = (uint32_t)XENSIV_PASCO2_INTERRUPT_TYPE_LOW_ACTIVE
    };

    result = xensiv_pasco2_set_interrupt_config(&xensiv_pasco2, int_config);
    if (result != CY_RSLT_SUCCESS)
    {
        printf("PAS CO2 interrupt configuration error");
        CY_ASSERT(0);
    }
#endif

    uint16_t ppm;
    /*Defining CO2 ppm levels for safe and warning*/
    uint16_t co2ppmsafe = 800;
    uint16_t co2ppmwarn = 1100;

    for (;;)
    {
        result = xensiv_pasco2_mtb_read(&xensiv_pasco2, DEFAULT_PRESSURE_REF_HPA, &ppm);
        if (result == CY_RSLT_SUCCESS)
        {
            printf("CO2 %d ppm.\r\n", ppm);


        if(ppm<=co2ppmsafe)
                {
                    cyhal_gpio_write(PIN_G,true);
                    cyhal_gpio_write(PIN_Y,0);
                    cyhal_gpio_write(PIN_R,0);
                }
        else if(ppm>co2ppmsafe && ppm<=co2ppmwarn)
                {
                    cyhal_gpio_write(PIN_G,0);
                    cyhal_gpio_write(PIN_Y,true);
                    cyhal_gpio_write(PIN_R,0);
                }
        else if (ppm>co2ppmwarn)
                {
                    cyhal_gpio_write(PIN_G,0);
                    cyhal_gpio_write(PIN_Y,0);
                    cyhal_gpio_write(PIN_R,true);
                }

        }
        cyhal_system_delay_ms(10);
    }
}

Step 3: The output can be seen in the terminal as shown in Figure 4.

 Figure 4. CO2 ppm levels being printed in the serial terminal

The LED’s will be turned on/off based on the CO2 ppm values measured as seen in Figure 5.

 Figure 5. LEDs showing the status of CO2 ppm levels, (a) safe state, (b) warning state and (c) danger state

Green LED can show that the environment is safe. Orange/Yellow LED can show a warning state and can be used to initiate some preventive measures. The preventive measures can be as simple as controlling the air conditioning unit or opening the windows. The Red LED can indicate a worst working environment and should be followed by strict actions like vacating the room. A better understanding of effects of CO2 levels on human comfort levels can be understood from Figure 6. 

Figure 6. Human comfort levels based on CO2 ppm levels

Working condition is very comfortable for CO2 levels below 800 ppm. Beyond this level the conditions start deteriorating and working condition becomes difficult as CO2 levels reaches 1200 ppm. It is not recommended to continue working with CO2 levels more than 1200 ppm and is considered danger. Continuing working in these conditions can cause headache and sleepiness initially. Further higher levels of CO2 is harmful for human life and is extremely dangerous.

References

1. XENSIV™ PAS CO2 sensor datasheet 
2. Quick-start guide for XENSIV^TM PAS CO2 Shield2Go

A new version of the component (v.1.0) is provided below

Provided below is custom component (SerialPlot v0.0) for interfacing with real-time plotting software SerialPlot.

Hackaday.io: SerialPlot - Realtime Plotting Software     

The component implements interface to the real-time charting software SerialPlot. Using this component, PSoC data can be easily visualized on personal computer (Linux, Mac & Windows). Component doesn’t consume hardware resources, performing all operations by CPU, which is useful for systems with little resources, such as PSoC4. Multiple instances of the component can run simultaneously in the project.

Component features:

     Data types: int8, int16, int32, uint8, uint16, uint32, float

     Up to 8 channel output

The component was tested using CY8KIT-059 PSoC5 prototyping kit and CY8KIT-042 PSoC4 Pioneer Kit. Demo projects are provided.

Attached archive contains component library, component datasheet and demo projects for PSoC5 and PSoC4. Please read installation instructions in the readme.txt.

The component provided as-is, no liabilities. It is free to use and modify.

/odissey1

P.S. Demo projects use optional annotation components (which are also provided here in Support_libs.zip):

PSoC Annotation Library: PSoC Annotation Library v1.0

KIT-042 annotation stub: KIT-042: annotation component for CY8CKIT-042 Pioneer Kit  

Download SerialPlot: Hackaday.io: SerialPlot - Realtime Plotting Software                       

Figure 1. SerialPlot demo project schematic.

Figure 2. Project data output to SerialPlot graphic software.