PSoC™ 5, 3 & 1

det(output)はclockのrising エッジでリセットされる仕様ですが、ｄ(input)のエッヂとclockのrisingタイミングが同じ、あるいは非常に近いタイミングの場合、det信号は出力されますか？必ずｄ(input)のエッヂを検出してdet(output)を出力する方法を教えて下さい。よろしくお願いします。

det(output) is reset on the rising edge of clock.When the edge of d(input) and the rising timing of clock are the same or very close,Is there a det signal output?Please tell me how to detect the edges of d(input) without fail and output det(output).

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); 
      }
	
   }
}
   
   

Hi, to get control over the amplitude of a clocksignal, RodolfoGL suggested a slim solution (https://community.infineon.com/t5/PSoC-5-3-1/control-ampltude-of-a-clock-signal/m-p/341627#M46852). Thanks Rodolf. (Its also described in AN60580 (page 15)).   

The problem is that I can't get below ~0.5V amplitude. Can someone please explain to me why?

Hi,

I am trying to calibrate PSoC5 IDAC8 and going through Registes_TRM  documentation.

Q1: What is the function of the PSoC5 IDAC8 trim registers,  FLSHID_CUST_TABLES_DAC0_M1,   ...  _M8 (total 32 registers)  

and what is the meaning of the Modes M1 - M8?

Q2: Is that correct that VDAC8 comes factory-calibrated to produce 1.02V and 4.08V ranges, while IDAC8 is not calibrated to produce 255uA? (I see ~20% overshoot).

There was an error running port acquire: Can not acquire SWD device!

My board was working. After configuring in a  new PC the mini programmer is not detecting the PSOC3 BOARD.

The board is running with old programe.

The following MIDI project is a simpler version of the 'MIDI Piano' project. What I need at the moment is blinking an LED when the host sends any MIDI Sysex message. However, when I plug the board into the host PC, I get the following error message: 

When I comment out the MIDI identity reply part (as in the MIDI Piano project), I don't have this problem however the host PC does not recognise the MIDI device. What am I missing?

#include "project.h"
#include <stdlib.h>
#include <stdio.h>
#include <USBMIDI1_midi.h>
#define BlinkLED(); {Pin_LED_Write(1); CyDelayUs(3); Pin_LED_Write(0);} // blink LED indicator


//===========================================
// Global variables
//===========================================
char buff[32];//output UART buffer

#define DEVICE                  (0u)
#define MIDI_MSG_SIZE           (4u)


// Identity Reply message 
const uint8 CYCODE MIDI_IDENTITY_REPLY[] = {
    0xF0u,          // SysEx 
    0x7Eu,          // Non-real time 
    0x7Fu,          // ID of target device (7F - "All Call") 
    0x06u,          // Sub-ID#1 - General Information 
    0x02u,          // Sub-ID#2 - Identity Reply 
    0x7Du,          // Manufacturer's ID: 7D - Educational Use 
    0xB4u, 0x04u,   // Family code 
    0x32u, 0xD2u,   // Model number 
    0x01u, 0x00u, 0x00u, 0x00u, // Version number 
    //0xF7          //End of SysEx automatically appended 
};
 
//extern volatile uint8 USB_MIDI1_InqFlags; // Need for Identity Reply message



void Init()
{
    CyGlobalIntEnable;

   // USBMIDI_1_Start(DEVICE, USB_DWR_VDDD_OPERATION);  // Start USBFS device 0 with VDDD operation
    USBMIDI1_Start(DEVICE, USBMIDI1_DWR_POWER_OPERATION);
    CyDelay(20);

}


//==============================================================================
// Function Name: main
//==============================================================================
// Summary:
//       1. Starts the USBFS device and waits for enumaration.
//==============================================================================
int main()
{

    Init();

    while(1u) // forever
    {
        /* Host can send double SET_INTERFACE request */
        if(0u != USBMIDI1_IsConfigurationChanged())
        {
            if(0u != USBMIDI1_GetConfiguration())   // Initialize IN endpoints when device configured
            {
                USBMIDI1_Init(); // Enable output endpoint
            }
        }        
        
        // Service USB MIDI when device is configured
        if(0u != USBMIDI1_GetConfiguration())    
        {
            // Call this API from UART RX ISR for Auto DMA mode
            #if(!USB_EP_MANAGEMENT_DMA_AUTO) 
                USBMIDI1_MIDI_IN_Service();
            #endif
            
            // In Manual EP Memory Management mode OUT_EP_Service() 
            //  may have to be called from main foreground or from OUT EP ISR
            #if(!USBMIDI1_EP_MANAGEMENT_DMA_AUTO) 
                USBMIDI1_MIDI_OUT_Service();
            #endif
            
   //          Sending Identity Reply Universal System Exclusive message back to computer 
            if(0u != (USBMIDI1_MIDI1_InqFlags & USBMIDI1_INQ_IDENTITY_REQ_FLAG))
            {
                USBMIDI1_PutUsbMidiIn(sizeof(MIDI_IDENTITY_REPLY), (uint8 *)MIDI_IDENTITY_REPLY, USBMIDI1_MIDI_CABLE_00);
                USBMIDI1_MIDI1_InqFlags &= ~USBMIDI1_INQ_IDENTITY_REQ_FLAG;
            }
        }
        
        
    }
}

//void USBMIDI1_callbackLocalMidiEvent(uint8 cable, uint8 *midiMsg) CYREENTRANT
//{
//    BlinkLED();
//    cable = cable; // to avoid a warning message (var not used..)  
//    *midiMsg = *midiMsg;
//}  


//==============================================================================
// Function Name: USB_MIDI1_ProcessUsbOut_EntryCallback
//==============================================================================
// Summary:  Turn the LED_OutA on at the beginning of the function
// USB_MIDI1_ProcessUsbOut() when data comes to be put in the UART1 out
// buffer.
//
// To enable interrupts set USB_(MIDI descriptor)_(External Mode) = True  
//==============================================================================

//void USB_MIDI1_ProcessUsbOut_EntryCallback(void)
//{
//    BlinkLED();
//
//}


//==============================================================================
// Function Name: USB_MIDI1_ProcessUsbOut_ExitCallback
//==============================================================================
// Summary:  Turn the LED_OutA off at the end of the function  
// USB_MIDI1_ProcessUsbOut() when data is put in the UART1 out-buffer.
//
// To enable interrupts set USB_(MIDI descriptor)_(External Mode) = True
//==============================================================================
/*
void USB_MIDI1_ProcessUsbOut_ExitCallback(void)
{
    //LED_OutA_Write(0);
}
*/

/* [] END OF FILE */

Any help would be appreciated. 

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

hello, I am using psoc 5lp cy8ckit-059 prototyping kit and I want to build a project that uses ADC delsig that can read the input and send it to uart. I want to print the data without using delay because I want it to print every data in a serial monitor but if I run the code, it will crash my serial monitor (see my project attachment). Is there any methods that can let me get all the data and print it without delay? The attachment is my testing for the project with a certain setting on my adc delsig for the project requirement.