I got introduced to the PSoC 5 chip by the freeSOC project on Kickstarter (and smARtDUINO, which is compatible with it). They are part of the Arduino community.
I've tried installing PSoC Creator with wine, with both Mono and Microsoft .NET. That didn't work. Then, I tried, and succeded in installing the separate .msi packages, but the program crashes at startup (I'll try to investigate those).
Now, some questions:
- Does the .exe installer do anything important other than running the .msi installers?
- How much does your code use native Win32 .dll's? Would it be possible to use only .NET APIs, so as to enable running the program on Mono on Linux or OSX?
- Have you considered open sourcing any parts of your PSoC software? I know you've at least used compilers et' al based on the GPL'd gcc compiler suite. Is there any really important IP that mandates keeping the no cost sofware proprietary?
I'm sure you know about the success of Arduino and friends. The reason those 8 bit AVR based chips have been much more popular among hobbyists than similar PICs, is the fact that Atmel released their IDE to users at no cost. That is what you have done. Now, what has enabled the multi platform and really easy to use Arduino IDE (and Unix like cmd tools), is the fact that the AVRs are well supported by open source tools like GCC (which Atmel contributes to) and AVRDude.
Now, the Cortex-M3 in PSoC 5 is already supported by GCC (which you use through Sourcery G++), but the programmer protocol and the CPLD hardware configuration have no such support in the open source world (there is an abandoned project from 2006 to create such tools). I urge you to consider the Open Source HardWare movement and the hobbyists using linux, OSX, Android, (and Windows) who are constantly inventing new ways to create and better themselves and the world around us. I know you and them would have much to gain from each other, if you welcome them by realeasing some (simple) portable open source tools to usefully use you hardware in non-Win32 environments, with or without GUIs. You could start by releasing a simple open source tool to upload pre compiled binaries to your hardware, which would be useful for user side firmware upgrades etc. Even just documenting the protocol would help, I'm sure some of the freeSOC board owners will start developing tools if given the chance. I' know I would like to buy a freeSOC board if I can use it without the hassle of installing Windows in a VM, I want the user of my hardware or code to have free and easy to use tools on the platform of their choosing.
Thanks, and sorry for this lengthy post. I hope this will be read by the right people 😉
This on an earlier post -
Can I run PSoC Designer on a Linux or UNIX based system or use a virtual machine with these systems?
Cypress does not test PSoC Designer using any Linux or UNIX based systems. PSoC Designer is not formally tested using virtual machine configurations with any Windows, Linux, or UNIX based OS, although Cypress has been notified by customers that they have successfully used virtual machine applications to run PSoC Designer on Linux and Mac OS systems.
For more information on the system requirements for PSoC Designer, see the PSoC Designer requirements page at:
Yes, well, installing and using Windows in a VM is cumbersome, and I'm not after any official support, just some pointers for helping myself and others, and general opinions on psoobily having some kind of support for non-windows environments.
It might even be easy to port the software to work on top of Mono, or maybe they make some deal with CodeWeavers (commercial developer of wine).
And by possbily open sourcing some or all of the IDE, some one else will surely port it and extend it in new directions etc. All in all, it would be a big win for everyone, with hopefully minimal effort on the part of Cypress.
Well I attempted to install the PSoC Creator.exe on Kubuntu with WINE and was told that the file was invalid. After reading this forum I decided I should install PSoC Creator.exe on my Windows 7 x64 machine and move on to development. Well, that all resulted in an invalid executable file (see image).
Cypress PSoC IDE developers please port the code to Mac and Debian Linux or open the source so that these communities can extend the capabilities of this great tool.
I'd like to play with the cypress PSoC too, but being forced
to use Windows is a showstopper to me.
There are just so many other great pieces of technology
around which have excellent free software / Linux support.
So for now I'd rather stick with my FPGAs and LPCs.
And, a bit off topic, but related:
Yesterday after many frustrated and wasted hours with trying
to use my FX2 FPGA connect board with Linux,
I finally decided to throw it into the box
and ordered an FTDI board.
I'm impressed by the extraordinary price and flexibility/performance of the psoc platform.
However, after finding out that on Linux there is no native support to at least program or configure the CPLD/routing on a psoc, my conclusion is that this quite excellent hardware is not worth my time.
Please note that I'm not looking for GUI-based programs, but would be thrilled to have some basic command line tools to VHDL-compile and/or upload a program to the psoc. Back to AVR.
For program loading there are bootloader solutions that you can
modify to get command line upload. I have personally not done it but
seems doable, like execute a script from a command line that
talks to BL.
http://www.cypress.com/?rID=50230 AN68272 UART Bootloader
http://www.cypress.com/?rID=57561 AN73503 USB Bootloader
http://www.cypress.com/?rID=41002 AN60317 I2C Bootloader
That might work *if* the chips can be bought with the bootloader preinstalled *and* if it would allow reprogramming the ARM code, the PLD configuration and the pinrouting.
The only thing missing then is a commandline open source VHDL compiler.
So I don't post very often, but I was asked to respond to this thread.
I'm a software developer who's been working on Creator since day one.
And by working I really mean living, breathing, dreaming about and spending a good portion of my free time thinking about Creator from both a design and a usability point of view. I also handle third level support for Creator.
To answer some questions here:
There are several layers to the installer, but at the most basic level it is installing the MSIs and checking for dependencies. It also runs some optimizations on .Net assemblies to target the specific machine it was installed on.
I won't go into percentages, but a majority of the Cypress code is .Net based. That said, last time I checked, a good portion of the UI just refuses to run under mono. Part of that is the third party framework Creator uses, which is unfortunate.
As for making Creator open source, there are issues with that. First and foremost, we have chip specific IP in our tools that would be at risk. Furthermore, Creator is a venture into a new way at developing microprocessor designs. One that companies like TI are now trying to copy. We have nearly a decade of real world time and on the order of centuries worth of man effort invested. While you can download and install the tool without it costing you a penny, Creator is not free. It is value we bring to you when you use a Cypress part and that is absolutely considered part of our IP. That all said, we do look at what we can give back on a regular basis, provided it would not affect the user experience of the tool. We have given out source code for specific tools in the past. For example, SuiteUSB shows how to generate a driver similar to what LibUSB does. (Generally this code is not under GPL, which means your hobby project can become a commercial product without causing you grief.)
As for the programming protocol, we support standards like JTAG and SWD. While the Miniprog3 doesn't support support Linux that doesn't mean you can't program from Linux. Additionally, we do support boot loading as someone else pointed out.
Linux and MacOS support is on our roadmap; however, there is a lot of work to get there. I'm not going to talk about when that might happen because there are far too many unknowns. Not only does this require a significant investment on the development side, it requires significant investment on the testing and support side. Every supported environment is tested and must be available for a support call. Each new flavor (OS type+version) of an OS added is a multiplier on the resources required. This is far more complex and involved then people realize when they ask for Linux support.
For Linux support to even be on our roadmap means Cypress has made the conscious choice to spend tens of millions of dollars to bring this tool to the Linux community. We've had more than a few internal discussions about how to enable people, including porting just the command line tools to Linux. The problem is the user experience suffers as does the capabilities of the tool. The best we can do today is to offer exporting to Eclipse.
Now, I understand this is probably a disappointing reply (I'd love to say that we have a release next week supporting Linux, but we can't and we don't). Also I've simplified and condensed a lot of internal discussion/history/response for length here. (Hard to believe, but yes this is the abridge version.) That said, if you can give the tool a chance, despite the dependence on a Microsoft OS, I think you'll find an outstanding tool and platform that makes solving your problem easy and enjoyable.
As a software engineer, I respect the cost of R&D and implementation - especially when it contains a human interface. On the other hand, having the Creator IDE on one O/S is, as you do appear to understand, highly inconvenient - if not a show-stopper, given the issues that you listed and the inconvenience and high cost of a M$ environment (my opinions but to each their own).
Suggestion: Do not port to Linux or MacOSX in the future. Port one more (hopefully, last) time to something like Java or Python (I don't really care which). Both of the above run reasonably efficiently everywhere and support GUIs. Your future multi-machine environment support will be reduced in scope and less costly.
All the best,
I would be delighted if the batch / command line tools run by the GUI were available on Linux or OS X even if the GUI was not ported. I don't want to use the GUI anyway.
Most of the work we do is firmware development, so we can generate the sources using the Windows tools and then develop and build our portion of the firmware on Linux / OS X. I'm still working on the ELF -> .cyacd generation but I think I'm pretty close on that.
I've used Windows since Windows 3.0. There have been a few times I've been aggravated by Windows (Vista and 😎 but Windows 10 takes the cake. The GUI is great but Windows updates have been absolutely destructive to my development work and continues to be so to the point that I've decided it is worthwhile to move all my dev work to Linux (if only I could!). As Microsoft shifts more to a closed model like Mac a lot of developers will be forced to go elsewhere and it will be interesting to see if Microsoft can remain dominent as IBM lost its dominence in the PC world when they tried to shift to a new hardware architecture that would require their customers to throw away their hardware investments. .
Of all the tools I've used in the past few years PSoC Creator has simply worked despite Microsofts feable and ill-fated efforts to make Windows secure. Cypress engineers are to be commended for the high quality they do. I only ran into one issue once and it was quickly resolved.
In moving to Linux I've discovered the downside of an open environment and that is products can be poorly documented. A lot of hours have been burned trying to get applications installed and working because documentation is often missing or poor. A lot of it written by experts who write for their peers and not someone new to the environment. The learning curve has been high but the trouble caused by Windows updates has not deterred me in my efforts to move away from Microsoft products. It is good to know that when Cypress moves PSoC Creator to Linux they will be applying the same high standards.
As indicated in earlier posts, CodeWeaver's crossover for mac and linux are a possibility. Now that Microsoft has frozen their API, it has a real chance. Crossover (aka wine) is getting *much* better.
I was able to install PSoC Creator. I was able to completely build a project. The schematic editor worked, but was terrible on layout graphics in terms of display. No drivers are available, so could not load to the PSOC and debug, but it is *so* close.
You can buy a lifetime license from CodeWeavers, and at that level ask them to concentrate on making certain programs work better. This still does not get us to the point where we can debug, but since Cypress uses gdb, there is a possibility. I don't have the round tuit right now, but it is closer than ever before. I suspect that Cypress could, with CodeWeaver's help, and a couple of modifications to existing code (note: not full rewrites!) an end user could design, compile, and debug on a mac. Today, with codeWeavers, you can mostly design the hardware*, completely write code, and fully compile on a mac (and maybe linux?) today. *with some ugly graphics and ignoring NET errors.
Only debug and some graphics are standing in the way, based on my experience from two months ago.
You can always build your own tool for programming (code loading) psocs. The programming specifications have been available for a long time.
PSOC5LP : http://www.cypress.com/?rID=72883
Cypress even makes available a HSSP example proyect you can edit to build your own progranner.
for the record Atmel didn't provide any tools. It was the open source comunity that build the tools that the guys from arduino copied/modified to build their IDE.
I think the Open Source/Linux kids nowadays have ground up spoiled. In the past, if there was a piece of hardware you wanted to use that didn't had opensource tools you would build the tools yourself. Now the kids just demand the tools to be available to them almost as ignoring the tools actually cost a lot to develop.
btw, you can use m8ctools (open source, has schematics for hardware programmer too ) in linux to program psoc1 chips since 2005 and also there is FXloader for EZUSB that has also been available for quite a while.
First, thanks for all the great work on PSoC Creator!
Maybe I can suggest an easier route for Linux support: try to get Creator run on Wine (or more specfically: on Codeweavers Crossover). It would allow to run Creator without any modifications. I already had some success installing and using Creator (3.0) on the latest version of Crossover (though I needed to run all MSI installers manually, the main installer would abort). But I cannot open / create any projects, so I'm at loss. Maybe there are some simple modifications on Creator making it run much better, maybe its also possible to support the Wine team.
I can live with having it not running perfectly (e.g. integrated programmer in the IDE - maybe it needs to run standalone, or a missing document manager). But since I'm in the process of switching over to Linux as my main OS, the hurdles to using Creator are getting bigger right now... (and running it in a VM means a big performance hit)
Just my 2 cents,
In my opinion, just having the necesary tools to be accesed from command line would be all is needed, at least for now. With the time some kind of GUI interface or Eclipse plugin would do the trick.
Using Wine or any other "Emulation" type of thing might work but it my hit perfomance almost as much as the VM approach. I'm trying to use the VM but is not worth it.
All of this could be release with no support.
We are looking at all options. That said, I was able to get further using standard wine then ever before. I can't say much more than that right now.
Actually you cannot use Creator without a GUI (you can build an existing project but that's it). The issue is logical connectivity and physical placement is done in the GUI. Unfortunately these systems do not translate easily to a textual representation, nor does instantiating the existing content. And instantiating content is part of what makes Creator/PSoC so easy and powerful to use.
I'm also concerned that your VM is acting so slow. Typically we've seen a loss of 5-10% of performance using a VM (barely perceivable). Have you checked the BIOS to make sure all VM optimizations are on (provided you're using a computer from the last 5+ years)? Additionally, Creator is mostly single threaded. That's because the placement/routing problem doesn't partition well for multiprocessor use. The processor and enough RAM are the two bottlenecks. If you have about a gig of ram free (true, physical ram) and a beefy processor, you're good to go. Also note, most multi-core CPUs will boost the speed if there's just one process on a single core. So having a quiet environment tends to make your build significantly faster as well. Most Linux distributions are like Windows 7, and very noisy. XP out of the box is fairly quiet.
One final thing to note, even if Creator ran under Wine today without any problems, you wouldn't be able to debug without using a third party debugger. Miniprog3/kit debugging is using special Windows drivers that have not been ported. Wine does not work for drivers so that needs to be addressed before talking about porting Creator.
Ok, too late reply, but it's just a couple of months I'm using the PSOC architecture.
The Miniprog does not techically need any kernel driver, I'd expect. The same functionality should be obtainable by implementing the protocol bulk/control transfers with, i.e. libusb.
Besides being portable, this would also have been much easier to develop from scratch and would be easier to maintain in the long run.
It would also open the way to integrate it into other IDEs, which maybe is not what you want.
Thank you Scott.
I have a year old machine. Is a samsung laptop with an i7, 8 GBs of RAM. The VM is a windows 7 with 3.5gb and 4 cores.
I've tried changing it to one core with no luck. It compiles at least 5 times slower than in a regular Windows 7 machine. And having autocompletion enable just makes it freeze for 3 to 5 seconds every time it tries to autocomplete.
Right now, the best way to work for me is to have the VM open with Creator with autocomplete, I compile once to get all the generate souces. Then I create a (Normal C Project, not PSoC's) project in Eclipse in Linux and import all generated files and my own files and work from there.
I've tried to create a project using the plugin you provide but once I try to create the project and get to the part where I choose the compilers prefix and location folder, I set the folder right but it doesn't let me finish, the button is disabled. I've downloaded the ARM gcc compiler for Linux.
I gues that I've I could get working the plugin and had the drivers for miniprog, I could work almost fine with just having to design using the VM for the hardware part.
I think is a shame that your software can't run in every platform. The pioneer kit or even better a PSoC 5 Eval board like the FreeSoC would be the next big thing in open hardware since is easier, faster and way more powerful to develop prototypes than Arduino.
Anyway, thanks for the support.
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! 😄 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.
Agreed. But, do not port multiple more times. Pick a new GUI-supported language environment that runs everywhere (E.g. Java, Python). I wouldn't get locked into Qt or GTK or Apple tools; stay at a higher level as much as possible ($$$!). Assume that the new PSoC tool can fork `gcc` on any platform as needed.
My 25 cents.
Knowing that I might pur some oil into the fire, I can't stop myself offering my opinions:
Being a hobbyist calling OSX machines my own I have played with some multiplatform IDEs as well pure windows IDEs.
Let me be straight:
I rather use a well designed single platform IDE in a VM than having trouble with a half thought multi platform version!
PSoC Creator, for me, is one of the easiest to use IDEs even though I had my troubles with keeping windows stable.
Cypress has decided to go for single platform and there for Windows.
Considering development costs it might have been a wise decision 😉
Sure I would love to get PSoC Creator as OSX and or Linux application. Any how before that I want to see Cypress keeping the silicon road map as well as their very good service.
All the Best
Sorry Frank, but
non-sense. I rather have multi-OS solution so I dont waste colossal time trying to keep and maintain a WINDOWS (which are getting worse btw see vista10 (aka win10)) just so I can program PSOC.
Meanwhile, the huge cost you mentioned could have been easily mitigated if you purely FOSS the darn PSOC creator which us a shitty .NET GUI and GNU GCC underneath 😄
You thin it is a competitive advantage for cypress that you keep closed-source!?? Go fetch a calendar, check which year it is. Anything worth is on github, everything else is simply forgotten.
Good luck with getting anyone less than 50years old on board with Cypress PSOC.
I'am fan too and frustrated by the utter bloatware enterprise closed source software is. PSOC Creator is no exception!
Cypress insiders please correct me if I'm wrong but looks like Cypress bought Visual Studio sources a few years ago and produced a load of addons (i.e. the Verilog GUI).
If I'm right it's not probably viable to open-source Creator and besides, who would step in to maintain and improve it?
Creating an IDE from scratch is hardly a simple and quick job, thus reinventing the wheel is the usual no-go. But choosing VS we're now stuck with unportable codebase and it will likely be impossible to get all the features VS has brought in during the years. Today VS is a really good IDE, Creator of course has lost some ground. Choosing Eclipse (like i.e. Atollic) would IMHO have been a wiser choice. I'm no fan of Java bloatware but the combination of features, extensibility and user base makes it an hands down winner on anything else I'm aware of.
Just idle chat, no fuel to the flames intended.