Jul 23, 2014
Micrium's µC/Probe Graphical Live Watch V3.3 released last week with support for PSoC 4 and PSoC 5LP. µC/Probe is a Windows data visulation tool that lets you graphically interact with embedded target processors and map memory values to a set of virtual controls and indicators. It's a simple drag and drop interface. The µC/Probe works with the Cypress MiniProg3, Cypress's PSoC on-board kit programmers, and Segger's J-Link probe and you can add a variety of dials, controls, and indicators.
Using µC/Probe's Graphical display you can view the live values of variables on the target using graphical gauges, meters, bargraphs, graphs, plots, numeric indicators and bitmaps. You can also change the value of these variables in the µC/Probe interface.
Rating: (5/5) by 1 user
Jul 16, 2014
A number of people have commented to me recently that PSoC applications appear to use more SRAM than they expect. There is a very simple reason for this and it is easily changed. In an attempt to make application development really easy for new users, PSoC Creator allocates large amounts of SRAM to the stack and heap. This prevents people from getting frustrated with memory overflow problems while they are learning about PSoC and PSoC Creator. Of course, if you do not need that amount of SRAM to be allocated that way, it is trivially simple to change the values in PSoC Creator and rebuild the application.
For example, a new PSoC 4 application, targeting the top-of-the-line CY8C4245AXI-483 part, allocates 1024 bytes to the stack and 256 bytes to the heap. That is over 31% of the total RAM available in the device!
What are these memory spaces for? The heap is used by certain run-time library functions, most notably sprintf(), and also by applications that grab chunks of memory using malloc() and its related APIs. If you are not using dynamic memory allocation then this heap is just wasted space and you can remove it. In the System tab of the resources editor just change the heap size to zero bytes.
The stack is, of course, used for function calling. When a function is called the stack is used for the return address, to pass arguments to the called function, and for return values. The amount of stack you need depends upon how deeply nested your application is and the number (and type) of parameters are passed at each level. Just like the heap, the stack size is set in the System tab of the resources file.
There are two complimentary ways of determining the right amount of stack usage for an application. The first method is to review your source code. Determine the functions that use a lot of stack space and the where the deepest nesting occurs. From that point you can calculate the maximum stack usage. Use the compiler listing files to get the stack usage data for each function. I would always recommend adding a little extra to your computed maximum so that you have space to add a little code to the application without having to change the stack size. Let s face it, this is math , and the less we have to do it the better!
The second method is more empirical use the debugger to monitor the memory used. First you fill the stack with unusual data . A silly number like 0xFEEDBEEF works well because it sticks out visually and the chance of your application writing a lot of that number on the stack is low. Then you simply run the application and check the Memory window to see how much of the stack has not been over-written. It is important to exercise the application thoroughly, of course, to make sure all the paths have been followed and the maximum stack usage has occurred.
An alternative to this method is to place a read/write (access) breakpoint at the bottom of the stack and see if it is ever reached. If it is then you need more stack space. If not, simply move it up until it does hit and you have your peak usage.
Lastly, some third-party tools and IDEs offer built-in stack-checking functions, which can be especially useful when you are using a real-time operating system (RTOS). In those environments, each task typically has its own dedicated stack and you want to be sure to optimize each one to minimize waste.
Rating: (5/5) by 1 user
Jul 10, 2014
In embedded systems it is often true to say that "every byte counts". When your application runs solely from on-chip memory you have two very hard limits (flash ROM and SRAM) on the amount of memory you can use in your application. Modern compilers do an excellent job of optimizing code and data space, often getting very close to hand-crafted assembler in terms of memory-efficiency.
Watch out though because, by default, PSoC Creator does not optimize your code!
This is because of an inherent side-effect of compiler optimizations - they make the application harder to debug. The obvious example of this is when the code you are stepping through in the debugger has been modified by the tail merging optimization, which replaces multiple sequences of identical instructions with a single sequence. When you step the code it can jump about to really strange places in your source code, because the code you think you are debugging isn't where you think it is! But, as I said before, optimizations are really important and so, to avoid total madness, we need a way to turn optimizations on when we need them and off when we're designing and debugging.
PSoC Creator makes it really easy to do this by offering build configurations. There are two of them - Debug and Release - and they are complete sets of build options for a project. By default, a new project uses the Debug configuration which enables debugging and turns off all but the "safest" optimizations. With this configuration you can use the debugger to perfect your code before swapping to the Release configuration and simply re-building the source code.
The Release configuration turns on optimizations and disables debugging. Try it now and see your flash and SRAM usage drop! By default this configuration optimizes for space but you can quickly switch to speed optimization by simply editing the Build settings (look for Optimization in the Compiler section).
Switching configurations is really simple. There is a pull-down in PSoC Creator's main button panel and all you need to do is make your choice and build. It will only re-compile the source code - the hardware design does not change after all - and so experimenting with the options can be very fast indeed. If you are on the edge of your memory budget, or have a very tight window of time to complete a task, I strongly recommend using build configurations to help you make a careful, informed evaluation of compiler optimizations for your application.
Rating: (4/5) by 1 user
Jun 04, 2014
I just learned from the guys over at Schmartboard that they've selected the PSoC 5LP version of their Schmartboard for their monthly special. It's currently on sale for $30 (normally $35) for the month of June. So if you've been interested in picking up a Schmartboard or a have been wanting to see what capabilities the PSoC 5LP will give you over a PSoC 4, this could be a great deal.
The boards have a boot loaded PSoC 5LP and don't require a programmer. You'll need to use the coupon code CYPRESS to get the $5 off at checkout.
Find out more at www.schmartboard.com.
Design the way you think with PSoC Creator.
Rating: Be the first to rate
May 29, 2014
Thank you for taking the time to go through the PSoC Creator 101 video series. Lesson 8 is the final lesson in this first series of videos. We hope that these lessons have been a help to those learning to use PSoC for the first time. This lesson will guide you to other tools, documents, and resources available for your PSoC designs.
All the PSoC Creator 101 lessons are available at www.cypress.com/creator101. If you have any questions or challenges along the way, please let us know in the PSoC Creator 101 Training forum. If you'd like to request any topics for a future training or recommend any changes to our format, I've opened a feedback thread on our forum.
PSoC Creator 101 Lessons:
Rating: (5/5) by 1 user
1 to 5 of 126 Results | Next >
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.