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
I also tried to get PSoC creator working under Linux. unfortunately, it's not possible. So I tried to port some tools of the suite (https://github.com/clementleger/cypress_linux_tools). The current tools allow to build the software part of applications under Linux (no fitter, no hardware design, etc) for the CY8CKIT-049 and to upload them. Some tools have not been reversed (cyelftool).
Additionnal board support can be added in Makefile.cypress with a few lines (providing they use the same format as other board). Feel free to try it, fork it and contribute if needed.
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.
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 :D
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.
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,
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.
Had just confirmed PSoC tools work in Win10 when it broke badly.
Have now ditched Windows 10 for home use, all development tools will be Linux based from now on.
Been googling this subject, Cypress on Linux requests go back a long time.
Just tried installing under Wine in Mate 18, looks like the installer cannot do it.
Have downloaded the Creator iso version and unzipped it and will try installing each bit manually.
I don't expect good news after everyone else has tried.
Cypress guys, you really need to look at converting to Linux or making is easy to run in Wine etc.
Windows 10 is not looking like a good OS especially for my Work Enterprise OS.
Options - a Docker or VM , Windows + Cypress ISO?
I've had to abandon Windows as well and would love to try Cypress for some potential products. However the lack of development platform choice is simply a non-starter. There was a time when I would have dual booted, or temporarily changed platforms, to use development tools, but no longer. Windows 10 is simply an insult to our collective intelligence, privacy, and security. I'll check in from time to time and if Cypress ever supports Linux I'll be happy to try their parts.
We're a startup, because of which we would prefer to keep the cost low for prototyping, which include all tools for development as well. All of use linux as our daily driver. We've chosen Nordic for our Bluetooth requirements for the hardware simply because of all the linux and gcc goodness they provide. Would consider Cypress only if there is a linux version.
Hopinh to see a linux software stack soon.
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.
Any leads on how to use Miniprog3 for pure flashing purposes under Linux (no VM)
Even better, a way to use a PSoC 5LP as the programmer for a virgin psoc, streaming the binary via usb -> psoc 5 -> target device. Pref with some basic example code in C or Python to talk to the "swd-bridge"
I just started looking at PSoC (5), and was surprised over the range of possibilities this architecture provide and see several possible use cases.
If anyone at Cypress follows this thread, I think you should consider that a significant amount of engineers in the asic/fpga community is cli/Linux based, and would be discouraged to evaluate PSoC due to Microsoft centric tool chains. As the complexity and capacity of PSoC increases and approaches a point where it becomes a viable alternative to traditional asic/fpga + analog designs, you'd probably find several new potential markets. Cross platform (and cli) development tools would surely ease the step for many engineers.
anyone used Open OCD to "swd" the psoc's? I wonder if it's stable and how it supports things like read-back protection etc.
I wouldn't mind using the miniprogs as long as there were a linux based cmd-line tool to run them