PSoC™ Creator & Designer Forum Discussions
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.
Show LessHi,
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.
Show LessI 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.
http://www.cypress.com/go/psoccreator
Those of you who already have PSoC Creator installed will be notified by the Cypress Update Manager to update any moment now. Please update your software - we've improved a bunch of features and added a SAR ADC (12bit resolution and 1Msps) for PSoC 5 devices.
-- yfs Show Less
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.
Show LessI'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?
Show LessDear 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!
Show LessHI,
We are working on PSOC5 project and would like to make a release build of the project. however, it seems there is no way to change the build setting configuration to release. it is always in "debug(active)".
We modified the configuration setting to "release" and press OK, but when we re-open the build setting, it is still debug(active).
Would there be other setting we need to change?
Thanks
Show LessFirmware engineers are always looking for ways to write more efficient code. Often this means executing functions as fast as possible. One way to improve the execution time of your code when developing for PSoC5 is to place your code into RAM.
Placing code in RAM using GCC
Gcc supports the use of the __attribute__ keyword which allows you to apply special attributes to your code. There are many attributes you can apply; the one we are interested in is section .
The section attribute places code in a specific memory section as defined in the cm3gcc.ld file. RAM is defined as the .data section. So, for example, if you wanted to place a function in RAM the code for the function prototype would look like this:
void foo (void) __attribute__ ((section(".data")));
This method can be used for variables as well.
Interrupt Example
A great use of this feature is to place interrupt handlers in RAM for faster execution time. If you define your own ISRs you can do this by placing __attribute__ ((section .data ))) after the ISR prototype like a normal function declaration.
If you are using the Cypress generated ISR code you can add a declaration statement to the section of code at the top of the .c file which is provided for the user to include modules and declare variables.
Here is an example:
// place interrupt in SRAM to improve speed
externCY_ISR_PROTO(isr_1_Interrupt) __attribute__ ((section(".data")));
for an isr named isr_1.
Linker Warning
When you place code into the .data section you will get the following warning:
Warning: ignoring changed section attributes for .data
This is because the .data section does not, by default, expect to have code attributes associated with it. In this case you can ignore the warning, because you intend to add attributes to the .data section. Even though the warning indicates that the linker is ignoring your attribute, it will still place your code in RAM. You can verify this in the map file by checking which section your code has been placed in.
To clear this warning you would need to modify the cm3gcc.ld file. The best approach would be to add a custom section located in RAM for you code. However, since this is Creator generated source code, changes you make to this file will be overwritten when generating the project APIs.
RAM vs Flash execution
The following table provides some sample data taken to show the code execution speed from flash vs RAM. There is about a 30 % improvement in execution time when executing out of RAM vs flash. This data was taken by toggling a pin in an ISR with a varying amount of code, measured in bytes. The Cortex M3 was running at 24 MHz. There was no difference in the time it took to get into the interrupt.
Code Size (bytes) | Flash Execution Time | RAM Execution Time | % Difference |
400 | 9.8 usec | 7 usec | - 29 % |
800 | 19.4 usec | 13.4 usec | - 31 % |
1600 | 38.4 usec | 26.8 usec | - 30 % |
3200 | 76.8 usec | 53.4 usec | - 30 % |