PSoC™ 4 Forum Discussions

Dear All,

I am using CY8C4246AZI-S413 Controller for USB HID-Keypad. It's Working fine with Operating System "Windows".

Whenever I am trying to connect with Linux operating System It  is not showing compatibility and any indication also.

Please suggest any other option to make USB HID-Keypad compatible with Linux.

Warm Regards,

Sanket More,

India.

The SysTimer, tinyprintf and CapSense I was able to put in. 

How do I fix this?

Should I share the c-file?

Hello,

I want to enable C++ exceptions, so I added -fexceptions flag to CXXFLAGS in Makefile. When I run it with VERBOSE=1, I get the below output:

/Applications/ModusToolbox/tools_3.0/gcc/bin/arm-none-eabi-g++ -fexceptions -c -mcpu=cortex-m0plus --specs=nano.specs -Og  -mthumb -ffunction-sections -fdata-sections -ffat-lto-objects -g -Wall -pipe -fno-rtti -fno-exceptions -DCOMPONENT_APP_CY8CKIT_149 -DCOMPONENT_CAT2 -DCOMPONENT_CM0P -DCOMPONENT_CM0P_0 -DCOMPONENT_Debug etc.

which latter -fno-exceptions overrides my -fexceptions flag. I know I can create a custom config instead of DEBUG. However, it is quite a task to exclude one default C++ flag. So the question is: Is there a simple way to exclude the default flag?

Thanks in advance...

I'm getting my "feet wet " in UDBs and have found a couple of surprises.  The project is generating Manchester code at 1 Mb/s from a 24 MHz clock.  The clock is divided by 12 in a UDB (no problems) giving a 2 MHz enable for half bits, whch are loaded into another UDB (A0) from the FIFO, managed by a timer.

The first "surprise" is that the shift register changes the state of the shift out, even if it is set to NOP.  In fact, even if the ALU is also set to NOP.  One UDP step that did nothing but A0 = F0 changed the state of the shift out.  This doesn't seem reasonable.  Since the UDB was being clocked considerably faster than the output, I was initially trying to use A1 to do the bit counting, rather than a counter, but had to abandon the idea because it was corrupting the output state.  Likewise, I had to guard the loading (A0 = F0) state to make it align with the bit clock enable.

The second surprise concerned the use of the FIFO.  The project now works, so I know the UDB part is done  right.  But several early versions would only get the first byte, or sometimes the first two bytes from the FIFO.  The C code was writing 5 bytes.  By the time it wrote the fifth byte, the first had already been consumed, so overflow was not an issue.  But what I found was that if there was a short pause between writing the bytes, they didn't seem to get into the FIFO, as the empty line would go high and not come low again.  Some of my experiments involved slowing the process down, in case it was happening to fast for the FIFO.  That made matters worse.  Yet if I did an additional FIFO write a second later (human speed via RS-232) it worked just fine.  Another test was to request the FIFO full status.  It was never full, which ruled out that possibility.  I even had a version that waited until it was not full.  But the diagnostic print in it never fired.

There was a little calculation to do for each byte, and I was putting the results out the serial port as part of development testing.  I figured that would give the UDB a little more time to consume the bytes (it takes 4 us to consume each byte).  Ironically the only version that worked was when I eliminated all the waiting.  I precomputed all five bytes and then pushed them out in a for loop as fast the the CPU could do it.  Amazing it worked.  The starting sequence looked almost identical to before.  Empty would go low.  The first byte would be removed, empty would go high briefly (about 250 ns) and then go low when the second byte was placed in the FIFO.  But that is where the similarity ended.  With the slower paced writing, Empty would go high again after the second byte was read and never go low.  But with the maximized pacing, once the second byte was written, empty would not go high again until all five bytes were consumed.  Given the 250 ns mentioned above, and the 4 us usage, it doesn't seem likely that an underrun occurred, but even if it did, the system should have picked up again when the next byte was available.  If I sent more bytes a second later it would do that.

It seems as though there is a dead band where once data is written to the FIFO and then paused, it can't be started again for some significant period of time or it will end up in the missing bit bucket.

Anyone ever see anything like this?

Thanks,

Wilton

Hi, Support Team

Do we have 433MHz and 125Khz for Passive Entry and Passive Start solution.

if any suggestion, Please advise me.

Thanks,

Best regards,

Lawrence

HI，

We want to design a Touch module using PSoC4 MCU (Capsense).
The shape and length of the Touch sensor will vary based on the project requirements.

If we want to develop only one version of the software, we can adjust the parameters of the Touch module based on the project requirements through UART or SPI communication. Can you suggest which parameters need to be retained? Can we store these parameters in the MCU?

Hello community, I'm posting about a project with SMBus slave used in Psoc 4 microcontroller. However, I'm facing difficulties when trying to intervene in the interrupt of the SMBusSlave_INT.c file because the default response in the interrupt at TX_EMPTY line is not correct with the function sent from the master. I have tried to intervene in the SMBusSlave_ISR_EXIT_CALLBACK function, but it didn't solve the problem. Has anyone worked with SMBus Psoc 4 before and can help me, please? Thank you.

Hello.

I've been stuck in this for weeks now without finding the solution.

The toolbar that was there before disappered suddenly when I was working with my project. I tried to get it back and without knowing what I did I also lost the menubar. Now I can't do anything in the project.

I have tried to uninstall the program more than once now, but every time I reinstall the program it installs without a toolbar and menubar. What can I do?

I'm currently using win10 home edition.

I'm doing the initial development on a PSOC 4 design.  At present I have a small UDB test function.  I added a simple UART implementation to send "Hello World" and then echo characters.  But it never gets to any of this.

The first call in main() is cyfitter_cfg().  The next to last call in that is ClockSetup()  it ends with

(void)CyIntSetVector(8u, &CySysWdtIsr);
CyIntEnable(8u);
CY_SET_REG32((void *)(CYREG_WDT_CONFIG), 0x00000000u);

As ClockSetup() and cyfitter_cfg() unwind, execution starts over in cyfitter_cfg(), and the second time through, it ends up in the unhandled interrupt loop.

I presume it got there because there was not wdt interrupt handler.  But my real question is why did the tool chain initialize wd interrupts when I didn't ask for any?  Right now this is an experimental development project to familiarize myself with the hardware and tool chain and to build some UDP/PLD pieces that will go into the final project.  I don't need or want any WDT functionality at this point.  Maybe I'm missing something, but it is basically the code the tool chain generated except for the following, which I put in main()

int main(void)
{
cyfitter_cfg();
UART_1_Start();
UART_1_UartPutString("Hello World\n");
ShiftReg_1_Start();
ShiftReg_2_Start();
for(;;)
{
uint8 ch;

if ((ch = UART_1_UartGetChar())) {
UART_1_UartPutChar(ch);
}
}
}