PSoC™ 5, 3 & 1 Forum Discussions

With the arrival od the festive season comes a cool application on PSoC by Mark!

Below is the post from the PSoC Insiders Blog.

If you have used microcontrollers as long as I have, you have most likely bit-banged a serial protocol a couple of times.  For those of you new to microcontrollers, bit-banging is when you write 1s and 0s to a GPIO port to simulate hardware you controller doesn't have.  It is almost always a pain, it takes excessive CPU cycles and is even worse if you are on the receiving end, like an I2C slave.  If anyone ever asks you to bit-bang an I2C slave, just say NO!  Just trust me on this one!

Anyway, it is impossible for your microcontroller to always have every serial interface that may come along.  For example, I read about a string of 50 Christmas lights that had red, green, and blue LEDs in each bulb and here comes the best part, each bulb is addressable.  Yes, you can control each individual bulb for color and intensity, four bits for each color (red, green, and blue) and 8 bits for intensity.  Of course the string of lights came with its own controller that could generate 12 different patterns, but I wanted to create my own patterns.  With a little Google searching I found that someone had already hacked the asynchronous protocol and bit-banged an IO port to control the lights with some microcontroller.  Nobody had actually created hardware to make this easier or less CPU intensive, you know why? Because nobody else used a PSoC3 or PSoC5 with their powerful UDBs!  Yes a PSoC3/5 can bit bang with the best of them, but why bother when you have extremely flexible hardware, plus bit banging is so 90's. 

The protocol was a 26-bit packet with one start and three stop bits. Each data bit was divided into three 10uS periods.  The first period is always low, the second period was low if the data was a 1 and high if the data bit was a 0 .  The last period is always high.  See images below for bit and packet formats.

The packet format is pretty straight forward with the address, brightness level and three colors packed into 26 bits.  See figure below.

I had a choice, be lazy and use a 32-bit wide shifter or use a single 8-bit wide shifter with a slightly more complicated state machine. The 32-bit wide implementation would be easier but would be a bit wasteful in hardware.  The 8-bit wide implementation would take a bit longer, but much more efficient. I choose to go with the 8-bit wide design.  One other nice feature in the UDBs, is that you can create two 4 byte FIFOs for data flowing into or out of an interface.  This turned out to be perfect since it took 4 bytes to transfer the full 26-bit packet.

The string of lights is 50 bulbs long and if you want to update all the bulbs at one time, it would take 200 bytes (50 bulbs * 4 bytes per packet). Since you don t want the processor to just sit and wait for an interface to move data, DMA is the perfect solution. This way I was able to update the entire string using DMA with almost no CPU overhead!  Where the other guys are wasting their CPU cycles toggling bits, the CPU in the PSoC could concentrate on generating cool interactive patterns, converting DMX commands to the light string format, or any other task.  What is even better, I could implement 8 of these interfaces in a single PSoC3 or PSoC5 at the same time.  

Making this interface into a PSoC Creator component, provides a way to setup all the hardware and DMA with a single start command as with all Creator components.  More APIs are added to generate cool lighting patters. 

Just think of the possibilities interfacing a string of lights to anything that can be measured with a PSoC!

Here are a few other images of the actual box the string came in, the string that I modified, my interface board, and a close up view of one of the bulbs.

I tried to use CY8CKIT-003 as a programmer for  chips CY8C3866AXI-040, installed in my device.
I did the following:
1. I made the switch for Pin XRES   from CY8C3866AXI-040 installed on the CY8CKIT-003:
      Normal connection or connection with Vssd (to set this chip in a high impedance state).

2.Pins SWDIO(P1_0), SWDC(P1_1), SWV(P1_3) , Vssd and Vddd brought out through a connector for programming CY8C3866AXI-040 installed in my device.

When I use CY8CKIT-003 as a programmer, I set the jumper between XRES and Vssd and connect connector to my device for programming the chip CY8C3866AXI-040 .
Chip CY8C3866AXI-040 is connected as in Figure 6-4. PSoC Power System (Page 29) PSoC ® 3:      CY8C38 Family Data Sheet.pdf

All VddX in xxx.cydwr --> Voltage Configuration is set at 5,5V

I have the following problems:

1. The chip is  detected and  programmed only at Vddd = Vdda = Vdiox = 3.3Volt.
2. The program is executed, but USBUART operates in 3,3 V while the file main.c I have USBUART_1_Start (0, USBUART_1_5V_OPERATION);

Exactly the same chip in CY8CKIT-003 is programmed with both voltage Vdd (5 and 3.3) and operates at 5V USBUART.

If someone was doing this, tell me what I did wrong.

I used to experience this project: ECG_PGA.ZIP    http://mylab.wmsite.ru/ftpgetfile.php?id=59
Changes in the board CY8CKIT-003 are shown in the picture attached below.

Hi There,

I'm just starting evaluation of PSoC5 with the Development Kit CY8CKIT-050.

I opened the ADC_DAC sample application that displays an 8bit pot position on the LCD. I now would like to communicate this value in binary over RS232 to a terminal application. So I grabbed a UART and dropped it on my sheet, I configured baudrate, stopbit and parity and added UART_Start(); and then UART_PutString("Hello World!\r\n"); after that. However, when I reset my dev kit, nothing appears in the terminal.

On the schematic design, the rx and tx pins were automatically wired up to Rx_1 and Tx_1 which I assume are the Rx and Tx that are routed to the 9pin d-sub connector .

Any hints would be appreciated, Thank you!

Ron

dear all,

i have psoc5 first touch kit

when i power up the kit, psoc chip is getting started to heat up

i don't know what i have done wrong and this happend, but i was working with  DI and DO which were having 5 v max. may be i have interchanged DI/ DO accidently. is this the reson of heating? i don't see any burning in kit. i am still able to download program and run it. but i fear if time elpses with power on, something will happen to chip

 what shoul i do??

Warm Regards

I have some probably obvious questions to ask here, I just want to verify before I invest too much more in this.

I'm new to microcontroller development and slightly new to electronics (I assembled a heathkit TV once as a kid... woop-de-doo).

I've purchased a CY8C29466 and I want to know how to program it (and use it), or where I can find some samples specifically related to it.

I have 8 years experience in writing multiphysics software in C++, as well as a few recent user mode HID drivers (gamepads, joysticks, etc...), so the programming aspects don't scare me.

I understand I need a programming board (e.g. the CY8CKIT-001 in the store, but I'm not sure).

If I were to buy the aforementioned kit, do I just push the chip into the middle of the prototyping board without anything else?

When I'm done programming it, what paraphernalia must I attach aside from a power supply?

I ask because I want to fit the thing in a 15mm^2 x 5mm box along with a bluetooth radio and I don't want to have to mount it on a massive PCB (as I think was suggested in the kit video).

The purpose I have in mind is controlling the speed of a small motor with my phone for the heck of it, but doing so in the most compact way possible. Eventually I was thinking of jamming all of it into a 1:87 scale model semi truck, since it actually has the room to fit the two components sans the power supply.

Thanks in advance.

I found a way to crash the bootloader when using the I2C interface.  In fact, this should affect any bootloader.  The CYBTLDR_COMMAND_DATA command does not restrict the user from appending data past the dataBuffer boundary.  This will cause unexpected behavior.  In the case of my I2C bootloader, I2C NAKs data from all further transfers, preventing it from performing any command.  Although this can be considered an user error, but the result is a complete failure, which is unacceptable for a bootloader.

Original code:

case CYBTLDR_COMMAND_DATA:

                    /* We have part of a block of data. */

                    ackCode = CYRET_SUCCESS;

                    memcpy(&dataBuffer[dataOffset], &packetBuffer[CYBTLDR_DATA_ADDR], pktSize);

                    dataOffset += pktSize;

                    break;

New code:

case CYBTLDR_COMMAND_DATA:

                    /* We have part of a block of data. */

                    ackCode = CYRET_SUCCESS;

                    if ( (dataOffset + pktSize) < SIZEOF_COMMAND_BUFFER )

                    {

                        memcpy(&dataBuffer[dataOffset], &packetBuffer[CYBTLDR_DATA_ADDR], pktSize);

                        dataOffset += pktSize;

                    }

                    else

                    {

                        ackCode = CYRET_ERR_LENGTH;

                    }

                    break;

Hello,
I wanted to put the application in AN60590 PSoC 5, the ARM compiler does not recognize the function log
multiply_factor = (Q_BY_K AdcResolution *) / (IDEALITY_FACTOR * (log (CurrentRatio)));
while log (20) or log (20.12) works
This does not in PSoC Creator 1 and 2
If you have the solution!
thank you