Software Forum Discussions

I've got a PSOC -050 kit for development and the target is a 68-pin CY8C5466LTI-063.

Is there an easy way to have one set of source code and generate code for both chips without switching back and forth in one project between the development chip and the target chip.  The pinout has to change as well as the presence of the character LCD on the development board.

I'd rather not fork the software and support two versions. 

While compiling the code, I pressed the cancel build button, but the build did not stop as seen the build bottun still greyed out abd the cancel still activated. And then I tried to exit from/close the Creator and got following error messages.
 
prj.M0071: Unable to cancel an ongoing build for an unknown reason. Contact Customer Support for technical support on this issue.

The application could not cancel an ongoing build, so the cancel request will be ignored. You can try again or wait until the build is complete.
 

I had to kill the Creator from task manager to restart the Creator.

Hi,

Anybody knows where I can download the PSoC Creator 2 software? I am unable to find the download link in the Cypress website. I can only find the link for the component pack.

Hi,

Anybody knows where I can download the PSoC Creator 2 software? I am unable to find the download link in the Cypress website. I can only find the link for the component pack.

I feel like I missed the first day of class when some basic idea was taught that makes the world make sense.  I just spent an entire day troubleshooting my UART code.  When my project initializes the UART connection, it starts with no parity, then sends the +ICF command to change the modem's UART to an ODD parity.  Then my UART quickly reconfigures to ODD parity and off we go, saving the world and whatnot.  However, I was loosing all communications as soon as I told the modem to switch to ODD parity.  It turned out to be a problem with how I was reconfiguring my UART to ODD parity.  Here's how I was trying to do it:

UART_WriteControlRegister( (UART_ReadControlRegister() & ~UART_CNTRL_PARITY_TYPE_MASK) | UART__B_UART__ODD_REVB );

It never occurred to me that I might need to modify the ODD_REVB constant to set the correct bits.  Finally, I noticed with debugging that the wrong bits were being set by this command so I looked up the #define for these constants in the header file.  Here are the #defines:

/* Control Register definitions */

...

#define UART_CTRL_PARITY_TYPE0_SHIFT            (0x03u) /* Defines the type of parity implemented */

#define UART_CTRL_PARITY_TYPE1_SHIFT            (0x04u) /* Defines the type of parity implemented */

...

#define UART_CTRL_PARITY_TYPE_MASK              (0x03u << UART_CTRL_PARITY_TYPE0_SHIFT)

...

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

* Enumerated Types and Parameters*

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

...

#define UART__B_UART__NONE_REVB 0

#define UART__B_UART__EVEN_REVB 1

#define UART__B_UART__ODD_REVB 2

#define UART__B_UART__MARK_SPACE_REVB 3

...

As you can see, the parity constant values are relative to the mask, whereas I expected them to be shifted to the correct position in the byte.  So, after making the change below, everything works a whole lot better:

UART_WriteControlRegister( (UART_ReadControlRegister() & ~UART_CTRL_PARITY_TYPE_MASK) | (UART__B_UART__ODD_REVB << UART_CTRL_PARITY_TYPE0_SHIFT) );

I am not a classically trained programmer.  When I define constants for addressing bits in a bitfield, I will "pre-shift" them in the #define.  Is it more standard practice to do it the way this UART API is written?  Hopefully, this will help anyone else who missed the first day of class to save themselves a concussion from beating their heads on their keyboards like I did.

 This is a great app note.  I used a lot of the tips in here to free up a lot of space in my project.  Another technique that was not mentioned in the app note that I found in the Keil documentation is using the "small" and "compact" Keil keywords at the end of function declarations and definitions.  This instructs the compiler more clearly how you want it to handle arguments and returned values in memory.

I tried one of the techniques that ended up using more space than before I changed the code.  I have a global array of structs.  The array is stored in pdata memory and I was passing a pointer of a struct array element to a function and using the -> operator to access the struct members.  Since it is a global struct, I thought I would change the function argument to simply the uint8 index of the array element I wanted to work with and then access the members of the struct directly with the index.  After making the changes, and replacing probably two dozen -> operators, the code size was about 40 bytes larger.  I'm not really saying that the app note is wrong.  It may have been simply accessing of the array with the index.  In any case, it's food for thought.

I'm using Component Author Guide for creating my components, but I'm new to C.
I'm using VoltageDisplay.cywrk and creat  my first element (Simple moving average filter), and will use it as a model for others.
I want to ask questions:

- My  RunMean.cylib has an error that I did not see?
- What has been done irrationally?
- Is there a library of components created by other users?

RunMean.cylib element within the attached project.
thank you
 

 I have noticed that Keil includes the full (not the small, not the compact, but the large) library of floating point routines when you use printf/sprinf even if the float type parameter is never used.  Is there a relatively clean and simple way to prevent the fp routines from being loaded?

Dear all:

I am very happy to see cypress provide us the source code for the free software (PSoC creator and designer)! but i am very confused about the source code!

And if i can use the Sharp Zip Lib under the VS2010 environment, or i can transfer the c# source code to .lib file by using VS2010, after that i can use the PSoC creator's API lib in VS2010!

Attached website:http: //www.cypress.com/?rID=38310

Thanks for you kindly reply!