It looks like a very nice board.  Pity that those of us who run Linux can't play.

It seems so bizarre to me that a company whose main product is semiconductor devices (not software) deliberately reduces its customer base by playing favorites on operating systems.  It's just sheer blinkeredness and incompetence to not write development software in a portable manner so that people can use their chips regardless of which operating system they happen to use.

Vandana, if you're in contact with Cypress, you might like to pass this comment along to them.

Morgaine.

It wasn't done out of spite for other operating systems or anything so diabolical : )  We want to go cross platform, We know its important, but we have man-decades (maybe even man-centuries) of effort in our existing tools, built on a windows platform.  Is it perfect?  Of course not.  Its going to take a lot of work to redo the tools to make them cross platform like they should be.

I guess I just want you to know, we do hear you, and we are working to address it.  Or at least, I hear you : )

Michael Kellett wrote:

 

I note your response - your tone is such that I shall not respond.

Content is much more important than tone, and unfortunately the content of your message was very detrimental to the request for Linux compatibility being made in this thread.  It showed total lack of understanding and support for computer users whose sole operating system is Linux.  Your "it's not that expensive to buy a Windows license" was insensitive at best.

Since you were not able to put yourself in their shoes, deciding not to respond is clearly for the best, since any defence of your earlier advice would not help them at all.

Morgaine.

Chris Keeser wrote:

 

It wasn't done out of spite for other operating systems or anything so diabolical : )  We want to go cross platform, We know its important, but we have man-decades (maybe even man-centuries) of effort in our existing tools, built on a Windows platform.  Is it perfect?  Of course not.  Its going to take a lot of work to redo the tools to make them cross platform like they should be.

 

I guess I just want you to know, we do hear you, and we are working to address it.  Or at least, I hear you : )

I would like to start by saying that I really like the PSoC4/5 silicon capabilities, especially the Digital System.  I've been looking forward to playing with this architecture since it was first announced in 2009.  More on this later.

Regarding the immediate topic at hand, I appreciate the difficulty of porting a Windows application to GNU/Linux if it wasn't designed for portability from the beginning.  The Linux kernel is complex, but it's well-engineered and maintained by people who are committed to having it work reliably.  However, the GUI level is kind of all over the place and varies between distros.  From what I can tell, there really isn't a GUI standard so if you want portability you use X Windows (X11) and hope that the particular distro does a good job of implementing it or provide a reliable adaptation layer for whatever it's using for graphics.  For example, my XXICC software (see my link if you're interested) works fine on Raspberry Pi under Debian "Squeeze", but Ubuntu 11.10 misbehaves drawing diagonal lines and arcs.  Xilinx deals with the GNU/LINUX distro problem by only supporting Fedora (the last time I looked) so if you run it on anything else you'll be relying on community support.

My XXICC runs on both Windows and X11, and it's challenging.  I solve the problem using an intermediate layer called G-SWIM (GalaxC Simplified Windows Manager).  This is a use of David Wheeler's: "All problems in computer science can be solved by another level of indirection".  My application programs call G-SWIM for graphics, which in turn calls the underlying windows manager (Windows or X11 for now).

It was quite challenging to get copy/paste working well on both Windows and X11, because they do it in quite different ways.  And I never could figure out how to print directly from a GNU/Linux program, so I just generate a PDF and require the user to print it using "lpr" or an PDF reader.  This is OK for work-in-progress software like XXICC, but you'd like something more seamless for a final product.

Plus, if you need to access custom hardware such as a device programmer, you'll get to explore the netherworld of device drivers.

Getting back to PSoC4 and PSoC5, I first heard about PSoC5 at a Xilinx/Avnet XFEST in October 2009 and thought it was a cute chip from the marketing flyer.  Then I heard TJ Rogers talk about it at ARM Techcon later that month, and I was very excited by the chip's capabilities, especially the Digital System.  Reading the TRM got me even more excited, especially since it seemed on a first reading that everything was accessible through documented registers and that after asking cranky questions for decades I'd finally have something I've always wanted: a programmable logic device I could program myself rather than being forced to use the vendor's software and EULA.

Well, I found out a few months later that PSoC5 isn't all documented: while you have full control of the programming of Universal Digital Blocks and other blocks, the documentation won't tell you how to connect to them.  This was quite discouraging and I felt like Alice in Wonderland when she looked through the tiny doorway at "loveliest garden you ever saw" but was too large to fit through.  Every six months or so I review the TRMs chez Cypress and I'm still locked out.  Now maybe this is all documented somewhere in an app note or hard-to-find wiki (please, please, please point me there!), but from what I can tell I'm locked out and the only way to use PSoC4/5 is PSoC Creator.  In that case PSoC4/5 gives me no advantage over Xilinx FPGAs.

Now back to GNU/Linux.  When Chris says "it's going to be a lot of work to redo the tools to make them cross platform", there's a really obvious solution:  Release the documentation for PSoC routing, and the Open Source Software world will do the work for you.  Intel doesn't have to write their own compilers -- others happily do it for them.  ARM doesn't either.  Neither does MIPS or PowerPC.  Xilinx and Altera have chosen to write all their own software, and IMO that's prevented them from being the next Intel or ARM.

Hi Chris,

No need to appologize for being windows only.

When you build tools you look at your market potential While there may be 2-3 million loyal Linux/Unix users there are  300-500300-500 million Windows users

So the logical choice is to build your tools with the most potential return on investment.

The issues surronding Linux and Windows is an old and revered one.  When I did a study about 20 years ago, the data showed that the transition in the world from Linux/Unix to Windows was progressing at a rate where Windows would dominate.  Mostly due to cost, but also ease of use.  Yes I know ease of use is a personal assessment.  But cost was also the reason why the Apple PC did not flourish.  Quality is essential, but cost dominates the purchase decisions.

As for the PSoc board, it is another tool for the embedded community to exploit.  I suspect that an ARM version of Linux could be adapted for it if someone really feels it needs to be done.

For most embedded work, you can also go to ARM assembly code.

The real challenge I see is learning how to exploit the raw capability of the device.  From what I see, the tool provided can do that.

On a personal note, I would like everyone to refrain from airing their fanatical views every time a new device comes out.

The post is about Psoc, not Linux, Unix or Windows.  Please stay on topic.

Thanks

DAB

You don't need to necessarily rewrite all the tools to be cross-platform (though than would be really nice). Make at least sure they play nicely with Wine. That way we can _run_ them under Linux, even though they are not integrated as I we would wish.

(With the latest version of Crossover, the installer for 2.2SP1 now at least starts, but will crash when showing the license. But at least it seems to get better with each version...)

its built heavily on the .NET framework, so sadly, it probably would take a rewrite to make it work well with wine.  I haven't checked to see how well it works with mono, might be worth a shot.

Chris Keeser schrieb:

 

its built heavily on the .NET framework, so sadly, it probably would take a rewrite to make it work well with wine.  I haven't checked to see how well it works with mono, might be worth a shot.

I can install .NET under Crossover, so that should not be the issue (in fact, the installer checks that in its first stage, and is happy with what it finds...).

(Actually, I just did some further experiments and now the installer seems to be running. I will report what happens...)

yeah, definitely let us know how it goes!

The installer hangs when "caching" the installation files (I don't know what its trying to do there, everything is local...). I will look into it this this evening, amybe the Crossover logfile is helpful to see what is going wrong.

John Beetem wrote:

 

From what I can tell, there really isn't a GUI standard so if you want portability you use X Windows (X11) and hope that the particular distro does a good job of implementing it or provide a reliable adaptation layer for whatever it's using for graphics.

As usual, it's not quite so simple. There are two widely adopted toolkits, GTK & Qt, and the interesting part is that if you write with either of those as the target rather than any native (X11 or ms windows) then there are implementations of both toolkits that run on top of X11, Windows, OSX and possibly more. So from a UI perspective you can develop it once. You do obviously need to be aware of all the odd stuff like case insensitive filenames on windows and not code your app to make life difficult for those sorts of things.

  And I never could figure out how to print directly from a GNU/Linux program, so I just generate a PDF and require the user to print it using "lpr" or an PDF reader.  This is OK for work-in-progress software like XXICC, but you'd like something more seamless for a final product.

Using one of the toolkits helps here as they have already abstracted a lot of the detail for you into a reasonable print dialog that you can use to send your print job without needing to know the detail of how the backend printing system works on that OS.

Plus, if you need to access custom hardware such as a device programmer, you'll get to explore the netherworld of device drivers.

These days, when most devices are USB anyway, it's probably a good idea to build the programmer to use one of the standard CDC classes. If that's possible to do, you likely don't even need to worry about a driver as all OS's will have them already.

Release the documentation for PSoC routing, and the Open Source Software world will do the work for you.  Intel doesn't have to write their own compilers -- others happily do it for them.  ARM doesn't either.  Neither does MIPS or PowerPC.  Xilinx and Altera have chosen to write all their own software, and IMO that's prevented them from being the next Intel or ARM.

One good example is the Atmel AVR stuff that's supported by GCC.

Some companies work with the community and that can be hugely beneficial, other try to work outside it or even actively against it. The results are predictable, people who work with the community get carried along with it and often can even find someone else will keep the code up to date with changes, the ones that work against it find their code frequently broken or get boxed into only one distro.

Opening the documentation on how to use the device is usually the best policy, it generates goodwill, and that might make all the difference.

DAB wrote:

 

Hi Chris,

 

No need to appologize for being windows only.

When you build tools you look at your market potential While there may be 2-3 million loyal Linux/Unix users there are  300-500300-500 million Windows users

The number of users of an OS is almost irrelevant if your target audience is using something else. Historically Apple did well in the DTP area for those reasons. Market potential is much more than the simple number you state.

Ultimately if the PSoC is an interesting enough device then people will use whatever tools are available, if not they'll take the path of least resistance and pick an equivalent that doesn't require an additional OS and probably PC to go with it just to run a single tool.

DAB wrote:

 

Hi Chris,

 

No need to appologize for being windows only.

When you build tools you look at your market potential While there may be 2-3 million loyal Linux/Unix users there are  300-500300-500 million Windows users

The number of users of an OS is almost irrelevant if your target audience is using something else. Historically Apple did well in the DTP area for those reasons. Market potential is much more than the simple number you state.

Ultimately if the PSoC is an interesting enough device then people will use whatever tools are available, if not they'll take the path of least resistance and pick an equivalent that doesn't require an additional OS and probably PC to go with it just to run a single tool.