(1) Stability. It seems to me that this version is much less stable than the previous Designer that I have used for a few years (4.2). Irritatingly often it seems to lose connection with the pod (or the ICECube -it's hard to tell where the problem is), requiring one to restart the program or plug the ice in and out to get it going again. Worse, it hangs up completely quite often (with an hourglass that never goes away - for example when the Reset icon is clicked - see below). Another manifestation is when stepping, the execution point is shown as being at the beginning of a source file (not a valid code line) and the program just hangs.
(2) Reset. Version4 (in particular 4.2 that I used) had the property that when one is debugging a program, if you click the Reset icon, the program simply resets back to the start; then you can do normal debugging again, without having to relead the program. This is something that one does a *lot* while debugging with an ICE. In particular it allows one to debug what happens when the target is powered on or reset. (NB The program may have written something in Flash!)
Very annoyingly, 5.1 does not seem work like this. It requires you to reload the program! Doing this once or twice is a minor irritant - doing it dozens of time in a hard day's debugging is enough to drive you to drink (: I suppose this may be just one of the ways that the program reveals its instability rather than the intended behaviour. If this *is* the intended behaviour (surely it can't be) - it would be impossible to debug resets.
In summary - (1) and (2) render 5.1 almost unusable in my view.
3. Shared files. When one is working with multiple projects that share some of their headers and code (e.g. in my projects the inter-processor communication data structures and code is common to a number of projects), what one does *not* want to do is have multiple copies of ostensibly identical source files - you want to literally use the same files in all the projects. With version 4 I could do this, as follows.
(a) By having a line like this in local.mk "INCLUDE_PATH:=$(INCLUDE_PATH);../../../myIncludeDir".
Then by having source files containing lines like this: #include "sharedSrcFolder/sharedThing.c", where sharedSrcFolder is in myIncludeDir, one is using the shared code files. And, of course, header files can also be shared.
(b) The files included in this fashion are listed in the project explorer in the External Headers folder, making it possible to set breakpoints in included code files.
Now the bad news: version 5.1 supports (a) but *not* (b). This is a serious handicap.
Of course, some or all of the above might be related to my particular setup. I am working on a brand new Windows 7 Pro (x64) machine with lots of RAM and fast processor.
I am very interested to find out if other users have had similar experiences; and, if there is (a) any substance to my problems, then (b) is there any likelihood that Cypress will do anything about it?
1.Processes that make up the PSoC Designer. (a) The main process, PSoC Designer.exe about 152 MB in size. (b) The PSoCProgrammerCOM.exe, (c) CMX.exe, one for each project within the workspace (between 42MB - 65MB each) - in my case that makes 7 CMX processes; total memory about 500MB.
2. When PSoCDesigner is running normally (i.e. it still appears to be functioning) and it is terminated (by clicking on X in top RH corner), three of the CMX processes do *not* terminate.
3. When the reset icon is clicked and the program hangs (hourglass when cursor is over the toolbar or the menu bar), and the program is terminated, four of the CMX processes do not terminate.
4. Sometimes when I shut down the computer, I get a dialog asking me something like "Do you want to save Untitlled?"; I believe this is emanating from one of the zombie CMX processes.
It doesn't look like a very well-behaved program to me.