PSoC™ 5, 3 & 1 Forum Discussions
Hi,
Yesterday I have updated PSoC Creator. When I load the project I have worked on, only cy_boot apears to be newer - from ver 2.2 to 2.21. I have updated it. I made some changes and since then there are only troubles with stuff, that worked before. I am not pasting any code here, because it is very long, but operators like:
char outputStr [3] [20];
float input [3];
...
sprintf (outputStr , "%.3f", input );
seemed to mess up the mem data.
I tryed:
sprintf (outputStr , "%.3f", 123.456);
and it was the same. Then I tryed:
char test [20];
...
sprintf (test, "%.3f", 123.456);
same story.
It is working fine with %d, but with %f is not. I debug it several times wondering what's wrong with the code, and I found nothing. Then I get the backed up project (before the update). I started it up, it asked for an update and I choose no. The project runs smooth. The very same project - I loaded it again, and it asked again for update (I didn't mark it previous time as up to date). I made update. I check explicitly what exactly is going to e updated. Compile it, run it - data was messy.
I spent almost a day chasing gosts. Can you please advise waht's going on.
Thanks,
Stoyan Karanfilov
Show LessHi,
I am preesntly using PSoC creator 2, and the chip CY8C5568AXI-060.
When I clicked the program button of the PSoC creator, a message box pop out (as per attached file).
Can anyone please advise how to proceed?
Show LessHello! I'm new to PSOC programming, but when I tried to upload the following code
#include <device.h>
Hey all,
For the senior design project at my university, my group was assigned a robot that would serve as a wandering information kiosk for the campus. I was placed in charge of sensor integration. The sonars that our group decided to use can output an analog voltage level that corresponds to detected range or a pulse whose width corresponds to the detected range. To get a handle on the PSoC 3 I created a quick proof of concept program that would take in the analog votlage level and convert it to a digital value. To test it out I breadboarded the PSoC 3 and hooked it up to a power supply so I could easily and precisely change the voltage. The problem is that no matter what I change the voltage level to, GetResult always returns a value that is approx 22,000 or 0x5850 in hex.
So far in my troubleshooting efforts I have assumed, from talking to friends on similar projects, that the ADC returns a value that is scaled so that the resolution matches the acceptable input voltage range IE 0-6.14 volt range divided by 2^16 (16 bits of resolution).
Attached is my simple project so far,
Show LessHi!
Need to update display of an LCD through per second interrupt stub of an RTC. KIndly help me with a small example project using RTC. Am unable to understand example given in the documentation.
thnx in advance.
Neha
Show Lesshi ,
can any body help me regarding programming a PSoC 3/5 device using Miniprog 3. specifically i have the following queries.
>The JTAG port pinout on the miniprog lists some 6 pin names what are the corresponding pin numbers/pins on the PSoC IC?
for example the pinout of a PSoC 5 IC given in this document http://www.cypress.com/?docID=31913
does not show the names except Vddio for VTARG as given in the 10 pin connector pinout in this page http://www.cypress.com/?docID=31913 .
>Is there any board supplied by cypress for PSoC3/5 similar to the MiniEval board for the PSoC 1 devices, so that i can connect the miniprog3 JTAG connector to that board to program any DIP packaged ICs?
Show LessHi,
Can anyone please help me how to transfer UART to USB interface using the PSoC5: I have TX,RX,RTS,CTS connected to the PSoC5 pins and I want to transfer them into USB interface like the FTDI chip. I looked in all the examples I can find in the Creator2.0 and still don't understand how to make this simple...
Thanks,
Michael H.
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 % |