PSoC™ 5, 3 & 1

I have uploaded a new Digital Comparator component (DCmp) that is almost as fast (1/2 BUS_CLK frequency) as the Infineon version but uses significantly less PSoC resources.  It also can perform SIGNED comparisons!

DCmp-V2-0-component-Upgrade-to-DCmp-with-optional-HW-inputs 

Here's a quick look at some of the features compared to the Infineon component.

Check it out.

I suggest this thread be used to share ideas how to use this component in creative ways.

Hi All, we are a start-up with a renewable product and have designed around the above chip. Unfortunately with all the supply upheaval we can't find any of these chips for our first production run. If anybody can help or knows where we can get 20 or even 10No. I would be very grateful. Thanks, Kieran

The motor should be run up and down 1000 times and on each run
the limit switch must open and close again. Depending on the test result, a red or green LED should be switched on.
The following task has to be implemented.

1.If end position LOW - motor drive down till end position HIGH
2.If even after 12s the endposition it is still low, the red LED should be turned on followed by end.
3.If the end position within 12s is high, the motor should run 1000 times.

I have already implemented two output pins for the motor up and down positions, one for end position, one for green led and one for red led.

Please guide me how can i proceed with this task. I have never worked with Psoc, this is first time. I highly value any suggestions you provide me.

The motor assembly includes a limit switch that operates in both the top and bottom positions

also switches in the lower end position (closed in the end positions, during the

Motor drive open).

The first task:

The motor should be run up and down 1000 times and on each run the limit switch must open and close again. Depending on the test result, a red or green LED should be switched on.

I have already defined my macros

#define LOW 

#define HIGH 

#define LED_GREEN_ON LedGreen_Write(HIGH);

#define LED_GREEN_OFF LedGreen_Write(LOW);

#define LED_RED_ON LedRed_Write(HIGH)

#define LED_RED_OFF LedRed_Write(LOW);

#define MOTOR_UP {MotorDown_Write(LOW);\

MotorUp_Write(HIGH);}

#define MOTOR_DOWN {MotorUp_Write(LOW);\

MotorDown_Write(HIGH);}

#define MOTOR_STOP {MotorUp_Write(LOW);\

MotorDown_Write(LOW);}

#define READ_END_POS EndPosition_Read()

Please help me in approaching this problem. I have to use psoc creator.

Buenas noches, quisiera tener una asesoria respecto al uso del IDAC en Psoc 5LP. Estoy revisando la documentación para usarlo como fuente de corriente para usarlo para medir temperatura de una PT100. Segun esta en la documentación, cuando se usa la salida de corriente en el rango de 0-2048 uA, solo pueden usarse 4 salidas, que dejo adjuntas. Mi pregunta es, ¿puedo utilizar algun otro pin como salida del IDAC para usarlo con la PT100? y tambien, ¿puedo crear más de un bloque de IDAC dentro del proyecto para usarlo con varias PT100 al tiempo?

Gracias

I have successfully created a joystick button HID device using a PSoC 1.  It actually emulates 2 joysticks for a total of 56 buttons, which I use to interface with a pinball machine to read switch inputs from the playfield.  I'm using this connected via USB to a Windows PC.

It has one problem - I have to toggle an input before Windows reads any of the button values.  For example, in a normal pinball machine the balls are already pressing down on certain switches when you turn on the machine, plus some switches are normally closed and they open on triggering.  So at power on, out of 56 joystick buttons there might already be 5-10 buttons that are being pressed.

The problem is evident in the Windows configure USB gamepads tool, which let's you observe the current button states.  When I first open it up, it shows no buttons as being pressed.  I press any button at all, and this somehow wakes up the readout, and now I see all the various buttons registering presses.  But it gets worse - after a while of no use the button readouts seem to go to sleep again.  This is a problem in any typical robotic type implementation, where you need to read button presses at startup before you start making movements, otherwise something could be damaged.

I've seen a similar sleepy behavior in consumer programmable HID devices.  In fact, this was one of the reasons I decided to create my own HID solution, as a commercial developer said they were too busy to fix this issue.

I'm at a loss as to how to fix this.  Originally in my code I only sent the button readout if something changed.  I modified this to send a button state every 100 cycles regardless, thinking this would solve the issue, but it had no effect.

My actual code is longer to address all 56 buttons.  The shortened version below shows the exact same logic for the first 8 buttons - the omitted code is redundant.

What I'm most confused about is how triggering a GPIO input somehow wakes this up.  I don't see how that does anything that my Counter1 variable isn't also doing by forcing a data transmission.  Is my code getting hung-up on one of those while statements?  Does triggering a input somehow force an interrupt that resets my code execution?

I've looked through the USBFS datasheet, and a few things piqued my interest. USBFS_Force talks about remote wake-up functionality.  USBFS_UpdateHIDTimer talks about resetting an expired HID timer.  And the USB_TOGGLE parameter option on the USBFS_LoadInEP sounds like it could prevent packet loss.  But I fear I'm grasping at straws.

Any help would be greatly appreciated!!!

Paul

//----------------------------------------------------------------------------
// C main line
//----------------------------------------------------------------------------

#include <m8c.h>        // part specific constants and macros
#include "PSoCAPI.h"    // PSoC API definitions for all User Modules

BYTE GP1Buttons[1];

BYTE Data1ChangeFlag;
int Counter1 = 0;

struct { BYTE Report_ID; BYTE Buttons[1]; } GamePad1Report;

#define GAMEPAD1_RPT_LENGTH (sizeof(GamePad1Report))

void main(void)
{   OSC_CR0 |= 0x20;  //Sets the No Buzz bit in the OSC_CR0 register to keep the bandgap enabled during sleep, improving resume from sleep/wake-up performance
	
	// Enable global interrupts
    M8C_EnableGInt;
	
	GamePad1Report.Report_ID = 1;

	// Start USB and wait till enumeration complete	
	USBFS_Start(0, USB_5V_OPERATION);
	while(!USBFS_bGetConfiguration());
   
	USBFS_LoadInEP(1, (char*)&GamePad1Report, GAMEPAD1_RPT_LENGTH, USB_NO_TOGGLE); 
	
	// Enable Pull down resistors on All Ports
	PRT0DR = 0;
	PRT1DR = 0;
	PRT2DR = 0;
	PRT3DR = 0;
	PRT4DR = 0;
	PRT5DR = 0;
	PRT7DR = 0;
   
   while(1)
   {  ++Counter1;
	
	 /*BitShift the PSoC Port Bits to map them to Chameleon IO Gamepad Button Groups*/

	//	Buttons[0] = PRT4DR & 0XAA | ((PRT3DR & 0XAA) << 1);
		GP1Buttons[0] = (
		((PRT4DR & 0X80) >> 7) | // 10000000 > 00000001
		((PRT4DR & 0X20) >> 4) | // 00100000 > 00000010
		((PRT4DR & 0X08) >> 1) | // 00001000 > 00000100
		((PRT4DR & 0X02) << 2) | // 00000010 > 00001000
		((PRT3DR & 0X80) >> 3) | // 10000000 > 00010000
		((PRT3DR & 0X20)     ) | // 00100000 > 00100000
		((PRT3DR & 0X08) << 3) | // 00001000 > 01000000
		((PRT3DR & 0X02) << 6)); // 00000010 > 10000000

	//Check if any buttons have changed
      if(   (GP1Buttons[0] != GamePad1Report.Buttons[0])
		 || (GP1Buttons[1] != GamePad1Report.Buttons[1])
         || (GP1Buttons[2] != GamePad1Report.Buttons[2])
         || (GP1Buttons[3] != GamePad1Report.Buttons[3]) ) Data1ChangeFlag = 1;
	
      if((Data1ChangeFlag) || (Counter1 > 99)) {
         Data1ChangeFlag = 0;
		 Counter1 = 0;
		 GamePad1Report.Buttons[0] = GP1Buttons[0];

         while(!USBFS_bGetEPAckState(1));
         USBFS_LoadInEP(1, (char*)&GamePad1Report, GAMEPAD1_RPT_LENGTH, USB_TOGGLE); 
      }
	
   }
}
   
   

We use your CY8C3446LTI-085. We recently received a batch of these parts, with the same major part number as just stated, that will not flash. Looking for guidance as to why.

Good parts stamped as follows:
CY8C3446LTI-085
1401 A 04
CYP 601225
TWN

Bad batch stamped as follows:
CY8C3446LTI-085
1430 A 04
CYP 648315
PHI

Hello,

I want to use the LSB of the datapath value after ALU has finished as input for the next datapath instruction. So I connected the routed shift output to one of the instruction inputs. I got a warning about combinational loop / unintended latch and I assume that it's caused by this approach. Any ideas how I can get rid of this? I thought this approach wouldn't create a latch because the datapath is clocked.

Regards