I've been able to import the project ok. The problem was that I was using the default directory for the project in Eclipse and I had to choose the PSoC Creator project folder.
Now I can edit my code but I can't compile. If I choose the Builder Type as Internal Builder as mentioned in the Eclipse import instructions document from Cypress it won't compile at all, when I hit build it does nothing.
Just in case that it might interest someone:
I have tested PSoC Creator 2.2 SP1 on a Mac laptop, using VMware Fusion and running it in a WinXP SP3 virtual machine.
It works just fine, project build is almost as fast as on a real PC.
So that sounds like an issue with disk or memory access issues. One way that can happen is if your machine does not have the extensions (or they are not enabled) to let your VM use your RAM efficiently. The other possibility is if the VM or real machine has too little RAM and is using the hard drive paging file. Unfortunately, the VM controls are typically in the BIOS, so you have to reboot to check or change them.
I've already turned on everything that could help the VM in the BIOS. The RAM I've tested for the VM are 3gb and 4gb in a 8gb machine. I've shared to the VM from 1 to 4 of the 8 cores in the machine (1 to 8 threads) and I always get a not so decent performance. I can spend 2 or 3 minutes to fully build a project in the VM when the same project in Windows only takes about 15 seconds.
Using autocompletion it just makes imposible to even type in Creator so I have to disable. And everytime I copy or cut some code Creator freezes for 30 seconds or so or forever and I have to kill it.
Anyway if I find a solution I will post it here.
It is the code editor specifically where you're seeing problems correct? Is clipboard sharing between the host and guest on? If so, and the clipboard polling mechanism is implemented poorly, that might be a cause. And your project is on the VM's main hard drive correct? (If not that might be another cause) Finally, what VM host software are you using?
It's possible to do *most* of your PSoC5 builds outside of Windows. Using PSoC Creator has been a source of frustration in my experience... It crashes frequently, doesn't support C++, and fails to flash my hardware every other attempt. I.e., if I try to flash twice in a row, it won't recognize the target the second time.
I only use the TopDesign and design-wide resources portions of the IDE, along with the Generate Application command under Parallels now. Everything else happens on OS X (compiling, linking and debugging). I'm using a Segger J-Link debug probe, to talk to the hardware (a CY8CKIT-050).
Here's a Makefile and some example build output (pardon the compiler warnings):
"Cypress has made the conscious choice to spend tens of millions of dollars to bring this tool to the Linux community"! "Unfortunately these systems do not translate easily to a textual representation"!
Folks, after 30 years in programming, mostly cross-platform, I can say that such absurd statements means they got the software design broken or hired really inexperienced programmers.
The second statement is particularly ridiculous, as it implies that "logical connectivitiy" and "physical placement" cannot be explained among humans in a discussion! :-D Fortunately, this is very far from true.
Too bad I just bought a few prototyping kits on the basis of Cypress reputation, I should have checked first. Never again I'll buy any Cypress product.
Sorry to see you go. From a windows perspective continued evolution
of the tool and its capabilties seem good. And of course the better mix
of HW and Analog then other solutions still excellent. Not a solution for
everyone, there is always some capability we want that a specifc part
series does not have, but as you know perfection is found nowhere in
any class of processors.
I've successfully written bash wappers for all the tools except the fitter, which blows up on Wine. I installed on Windows 7 and copied over to Linux, but the ONLY reason that box is ever used is for the PSOC Creator.
It's a little odd - using Keil for most of it, but then using a cross-complied gcc for other bits, then throw some cypress bits in there at the end. Feels like duck tape and bailing wire holding the engine on to the wagon.
I echo the many others here that you provide at the very least VHDL tools and the fitter that can be run under Linux. I've done cross-platform GUI support, and the trouble Cypress is experiencing is in the choice of GUI tool kit.
Developers foolishly bought into a Microsoft platform and are now feeling the pain of doing so.
I've written GUIs in GTK+, and with the SAME code was able to compile for both Linux and Windows all on Linux. The difference being only in the invocation of make:
Besides GTK+, here are many excellent cross-platform GUI toolkits like Qt or vxWindows, or..., there is no reason to be confined to a Windows platform, especially since many high end tools run on some flavor of Unix - and there are good reasons for this decision.
Please give us a Linux tool.
I really approve the previous post.
I was so excited discovering the Cypress PSoC and imagine all the possibilities for us... and so disappointed when I discovered I can't program them in our only linux computers... Give us Linux tools !
All attendees of the 2015 Open Hardware Summit a week ago received the PSOC-5LP Dev Kit -059 (it's only $10 to buy, surely a loss-leader) and this has re-awakened my interest in PSOC. The Cortex M3 (with, e.g., hardware divide vs the PSOC4 M0) and decent amount of memory, I am hoping, will let us use it as the main micro in projects. Plus we can use the analog instead of separate, expensive ADC and DAC, plus PGAs, etc. That is my intent anyway. Now I have a learning curve to climb. and I hope there is a 125C temp version of PSOC5 now or soon. I'm a longtime Windows user, because, back in the dark ages before Linux, when it was Mac, then PC, (OK I ignore the Apple II but bear with me) the PC was the only open hardware system: IBM published all the hardware specs (yes, I still have a set) so that you could make your own plug-in boards for science and engineering. What a concept! So many companies did just that, and it gave the PC a huge jump in those communities. (Apple would not allow adding your own hardware to the Mac.) To this day there is not a package equal to Altium Designer for the Mac. Or Linux. I don't say that is good or bad, it just is the way the market developed. There are many other engineering tools which are only available on Windows. So like it or not for many engineering purposes we have been stuck using Windows for a long time, and it looks like that will be the case in the future at least for a while. I am finally learning Linux for embedded purposes and now have a few dual-boot machines, running Ubuntu 14.04 with various desktops. I'm not a religious fanboy of either MS or Linux, they both have strengths and weaknesses, IMO. The reality is that if you are in hardware engineering and want the widest array of current tools at hand, you must have a Windows PC. It's a cost of doing business, and it is not my biggest headache (that would be accounting and taxes). So what is my point? 1) Be patient and understanding with vendors that have used Windows for years because it had the lion's share of engineering users. 2) Desktop Linux is continuing to gain user base and there is more support for it every day. It already seems to own a huge share of the server and embedded OS base. If this trend continues there will be more tool support "soon". 3) You should always pick the best tool for the job. If Cypress PSOC is a great solution, maybe the best solution, for your task, then use it and live with the tools needed to do so. Otherwise you risk throwing the baby out with the bath water. If you are a SW developer and need to test your code on all platforms, you will need a Windows machine anyway for that. So it doesn't seem like it should be a deal-breaker for me. I am not trying to annoy anyone, just throw some oil on the waters. OK, enough metaphors. I need to get back to finding and installing the PSOC tools, which is how I got to this forum.
bboyes, welcome in the fascinating world of PSoCs!
Yes, the PSoC5 is a device with a lot of capabilities. Am I telling you a secret when I point you to the fact that in a PSoC5 are as an extra 24 programmable ALUs with 2 FIFOs each? Telling you to have the opportunity to use HDL (VeriLog) to define your own hardware components? Fascination does not end early... ;-)
It seems it would be straightforward to port the fitter application to both OSX and Linux as statically linked executables. It performs nothing more complex than file I/O. No GUI, no hardware interfacing... Give us the ability to run the fitter and give us the binary format for the schematic pages and we'll take care of the community support. You get to keep your secret sauce (the fitter) and you satisfy everyone's needs.
Of course there is one very big caveat with all of what I've said: once you have given us a binary fitter for OSX and Linux... RELEASE UPDATES AT THE SAME TIME AS YOUR WINDOWS UPDATES. There will be nothing more frustrating than letting the fitter rot. And really... it's no additional time to generate three command line executables as it is to generate one. Good program design would make this a trivial task.
So how about it? Give us the file formats for what the fitter needs and a binary fitter. We'll take it from there.
I use Windows 7 in a VM on Macintosh 10.9. (Can't stand OSX 10.10 User Interface. Apple's hardware designer should never design software interfaces. In my opinion he has no idea of the nuances required to create an interface for pain free/ irritation free hours of usage.)
I generally have no problems, except on the new boards released from Cypress (The $10 boards). Their debugger stub board hangs under a windows VM, so I break it off and resort to a miniprog3. I have not tried in about 6 months, to that may have changed.
My assumption is Microsoft's visual studio is the core of PSOC Creator, based on experiences with other IDE's. I would like to throw my two cents in.
Google purchased the rights to the IntelliJ platform and produced Android Studio. (To be honest, I don't really like Java. But, I have several Android apps out there. I heavily use JNI, for speed and utility. Even so, Java is turning into a compiled platform, so it is improving. )
The android studio is an excellent platform. It does what it should. There are bugs in it, but they can be worked around. Eclipse has gone down the toilet, and was unusable the last time I tried something with its last iteration.
If an agreement could be worked with IntelliJ, I believe a decent platform for Cypress could be created. However, it would not be cheap to create, and I expect would take one to two years for the first unit out on Windows. About 6 months for Mac, and another 6 months for Linux, assuming the core tool source code is owned/licensed to Cypress.
An alternative to IntelliJ would be Qt. It has an LGPL (or separate Enterprise proprietary) License which could bridge the open/closed source gap. It has come a long way, and I consider it ready for prime time. That was not the case a year ago.
No platform is free to create. No platform is cheap to maintain. However, even inside Microsoft, .Net is losing some traction. I would suggest moving away from that platform in a scheduled, orderly manner, into cross platform.
Finally, I am so against the disaster called Windows 8/ Windows 10, that I am now officially refusing to use that platform, except at gunpoint, or for a tremendous amount of money. Microsoft is moving to a Data Mining Platform and will serve advertisements onto your machine at its earliest opportunity.
AFAIK, Microsoft has never publicly stated they will not share your data. Their agreements now allow data sharing and remote management of your platform.
So, from my point of view, the sooner an IDE can move to the status of *not* being OS centered, the better for me. I'm looking 5 years down the road and I don't like what I see. I will have to grit my teeth and continue with Mac or grit my teeth and to go Linux. Or, someone will pay me an obscene amount of money to deal with Windows. Everything has a price.