I've recently been working on a simple PSOC (www.cypress.com/psoc) project using the CY8C64315 USB chip and can't help but compare it to the popular Arduino platform since it is pretty similar to the AVR 328P. These are my observations:
Feature Comparison
Cypress/PSOC 9, Arduino/AVR 5
Initially I chose PSOC because it has some great features packed into a tiny 16 pin QFN part at a cheap price. In particular it provides a full-speed USB device with very few external components -- not even a crystal! It runs at 24Mhz instead of the AVR's 20mhz and contains SPI, I2C, a bunch of IOs and so forth.
One issue is that it does not contain a serial UART (but other, bigger PSOC parts do), but I'm hoping to do a soft-serial implementation.
Perhaps its kind of silly but I didn't want my USB controller to be larger, more expensive, and have more pins than an embedded CPU itself (but when you get right down to it, it is in fact on par or more powerful than the 328p)! So the tiny part size combined with good features was the clincher for me.
Documentation
Cypress/PSOC 3, Arduino/AVR 10
The Cypress Application Note search tool is totally impossible to use. And their community site www.psocdeveloper.com is better but not "alive" like the Arduino or even avrfreaks. Its too tightly coupled with Cypress I think.
And none of this stuff comes up in google searches.
Note to Cypress -- you are NOT a SEARCH company! Just post all your App Notes in HTML form on a public site and let Google do the job. It will do it much better and you'll save some money.
One wild/good thing; I posted an issue bringing the chip up and actually got an essentially unsolicited telephone call from a real human being engineer the next day to help me (but had already figured it out). So that can make up for a lot of doc issues, but of course its pretty expensive for Cypress...
Hardware Design
Cypress 2, AVR 10
2. Application Schematic? It seems that Cypress didn't bother to put one in the datasheet. In fact I had to glean portions of the full "typical application schematic" from a bunch of "Application Notes" -- USB from here, ISSP from there. And of course those schematics were not necessarily for the chip variant I chose so there was lots of uncertainty in this process.
In contrast the Arduino project and all its variants are open hardware, so there are lots of circuit examples to choose from.
PSOC Designer vs Arduino IDE
Cypress 5, Arduno 5
PSOC is supposed to be some reconfigurable hardware "magic" that requires a fancy windows-only IDE. Not in my chip. Everything is just registers AFAIK. But still you can use a GUI to configure things and then it generates the code to write these registers for you. Now, this might seem cool, but actually it just gets in the way. It gives Cypress and excuse to not supply an API like the Arduino's "pinMode" and not to supply good docs. So what if you want to CHANGE the behavior of a pin while your program runs -- you've got to delve into the registers...
The rest of the IDE is everything you'd expect from a programmer's IDE. Good job Cypress! You are just as good as the free Eclipse :-).
However I do have one or 2 beefs. It:
1. Only runs on windows *sigh*
2. Pops up an irritiating "Programming" dialog box. This should be done in a small side-docked pane so the programmer can continue to WORK while the chip gets programmed...
Build Toolchain
Cypress/PSOC 5, Arduino/AVR 5
G++, GCC???
For some reason, instead of adding a gcc backend for the PSOC CPU, Cypress decided to go with some commercial C compiler. So no C++.
The result is a bit more like "Kiel" C then gcc and in particular has irritatingly difficult tranlation between a string stored in "flash" vs one in "ram". In fact, you have to define 2 functions one to handle "__flash" strings and one to handle normal "char *". *sigh*
But of course Arduino has this strange thing called "processing" with is actually C++ with some "try to help me but actually get in the way" thrown in so really average marks on both.
How to "Blink" (Basic programs/sketches)
Cypress/PSOC 7, Arduino/AVR 10
Its pretty INSANELY hard to figure out how to do simple things like configure a digital input (you use the GUI to graphically set the pin as CPU open-drain, then in code write the bit HIGH). Also standard C functions like "printf" are there but don't work... better that they not be there if they don't work.
Yet at the same time, it can be very EASY to do an entire USB HID device. So it just depends on how many Cypress libraries you can use.
Software Layers
Cypress/PSOC 9, Arduino/AVR 9
Ok, I've got to give cred to Cypress for being the 1st hardware company (AFAIK) to realise that we don't want to program at the register level. Yes, the GUI has "user modules" and you just pull them into your project to get massive functionality like a USB endpoint.
One nasty issue the use of lots of assembly??!!? All the Cypress libraries AFAIK are written in assembly. This makes reading the code hard :-). And also you can't ignore it; installing things like interrupt handlers requires you to get down in there and call out to your C. And this is NOT easy; to make the C compiler correctly save state, you have to basically trick the CPU into calling your C routine as if it was an interrupt even though you are already IN an interrupt. There's an entire App Note about how to do it :-(.
The advantage is probably smaller code sizes. But the cost is essentially that if you need to modify the library or add a feature, you have to either rewrite the whole thing yourself in C, or learn PSOC assembly which of course ties you and your work inseparably to this processor.
Summary:
Its a neat little device with lots of potential. Great hardware, great software/support philosophy but not so good implementation. But its a pretty steep learning curve...
Now, Arduino/AVR generally relies on the community to provide great programming libraries, examples, tutorials and general help. And we do.
Cypress seems to be doing all/most of the work on its own. It seems to be caught attempting to implement a modern philosophy with a traditional unidirectional information-flow structure.
So while I give cred to Cypress for the tremendous effort I'm amazed at its total disregard for the open source movement -- in compilers, in IDE, in software libraries.
And I'm surprised at its inability to truly capitalize on internet resources and community.
Hey, so thought I'd comment on a bit of this....
ReplyDeleteThe CY7C64315 isn't really a PSOC, it's basically a USB peripheral chip that uses the same core... so you don't get the crazy cool (but often painful to get used to configuring) analog / general purpose digital blocks on it. The core of the chip, the M8C, is awful (Cypress knows this, as is evidenced by the new lines of 8051 & Cortex-M3 based chips coming out... though the move from engineering samples to production has been reeeeally slow). This is why the assembly language and lack of free compilers... the chips are accumulator based (instead of having a good number of general purpose registers), and require tons of bank-switching; doing a GCC port for the chips would be a nightmare, due to the way the compiler is put together (this is also the reason there's not a functional GCC port for 8-bit PICs, despite them having been around since the ice age). The commercial compilers have put a lot of work into making reasonable C compilers that are aimed at accumulator based CPUs... though the assembly's still going to be a lot more efficient in almost all cases.
Despite the high clock speeds, the Cypress M8C based parts are really not super fast, due to taking many clocks to execute instructions, the constant bank switching, and assorted other quirks of the chips. And the learning curve is pretty steep. But for the right jobs, they're a bargain... and the PSOC parts are super win in many analog designs & some special digital ones (like, the hardware PWMs running @ 48mhz on super affordable chips).
Thanks for your comment! That's really interesting that gcc is essentially exclusively for general purpose register CPUs -- I had not realised that.
ReplyDeleteBut I did figure that the 64315 was probably a degenerate PSOC with no reconfigurability. What is quite interesting though is how this reconfigurable hardware philosophy (and maybe the terrible M8C architecture) probably encouraged/caused Cypress to provide higher level software abstractions (which is a great thing). [I think this is the case because these software libraries are presented in the GUI just like the hardware ones; you pull in "software-only" libraries and map them to pins, etc in the exact same way you pull in real "reconfigurable" library options].
At the same time overuse of this philosophy makes it hard to do simple stuff like dynamically change the pin behavior (from "input" to "output" for example).
However the fact remains that "programming" the reconfigurable hardware is a "soft" operation -- I mean you use ISSP to send a bit stream into the chip. Therefore there is no reason why the M8C core itself couldn't be the source of this bitstream (just like it can progam its own flash to change its own code). This memory might not look much like traditional "registers" but in the broadest sense it is somewhere between registers and flash -- that is, special well-known bits of memory that when written change the behavior of the chip. There is no reason that the M8C core couldn't change those bits.
And this makes me wonder whether they tried to cast it into a traditional "register" model or whether they purposely did not do so due to the hype around the fusion of programmable logic & microprocessors. What I am trying to say is that from my albeit limited experience, it looks like even with bigger PSOC parts you are still just connecting major functional blocks -- you do not actually have arbitrary FPGA or CPLD style logic gates to use to connect these major functional blocks like you do with FPSLIC. I certainly don't seem able to write verilog code in the IDE. Please correct me if I'm wrong!
Oh, totally, it's done with registers. There's a bunch of different virtual peripherals that independent folks have released, too... it's just that unless you're pretty serious about getting into the innards it's a pretty big pain to do. They have application notes on the different analog & digital blocks to help starting off through. And IIRC there's even "general purpose" peripherals that you can assign to blocks with the GUI interface to give simplified functions for playing with the low-level analog / digital blocks. And the virtual peripherals are designed so that you can load/unload them at run time; that's part of the whole magic of the chips (they give examples such as a soda machine which turns into a 300-baud modem at night to upload collected data, and then turns back into a soda machine afterwards). Of course, the drawback is that your pins can't be hooked up to any hardware which will interfere with the alternate functions.
ReplyDeleteThe new 8051 & ARM Cortex based chips, btw, *do* have small PLDs, programmable in Verilog: http://www.cypress.com/?rID=40330
Hi,
ReplyDeleteOne point that stands out (at least to me) is the fact that companies like Cypress (and TI and others) love to have Linux as a free giveaway with their dev boards, but do not support a Linux based dev system; no native tools of any kind and no intent to provide them.
These people seem to be the worst kind of parasite, taking all the work of others to sell dev boards, but not bothering to support those who choose to use something other than Microsoft products.
Personally I will never buy anything for a company that does not support the open source community properly.
Some will say that Atmel do not do a native Linux IDE. At the moment this is true for the smaller 8 bit micros. But in the future this will change as they become supported in the same way Atmel currently support their 16/32 bits devices.
The other major difference, hinted at very strongly in your posting, is that Atmel want to work with the open source community; they get it!
Atmel (like every other chip maker) is in the business of selling chips (or their designs under license), not writing software, selling dev systems or building search engines. It seems a large number of the chip design houses seem to think that charging a large amount of money for an entry level dev kit is the way to go. Wrong! You only have to look at the success of the small Atmel dev boards (the Dragon, The butterfly and others) to see what a difference they have made.
Lets face it Atmel came late to the game. Microchip, TI, Cypress and others were all here before Atmel. I think it says it all when you look at Atmels market share compared to the others today. And that from a late comer. They have the market they do because they get it; the others do not.
Yes. I hope posts like these will wake Cypress up. Their hardware is great. Their open source philosophy sucks.
ReplyDeleteThey feared that someone would steal their code and run it on a competitor's chip. So they locked their developers into the Cypress mansion (custom libs/ toolchains) where its pretty hard to run 3rd party stuff.
But they will soon discover that they locked themselves in too! Its pretty hard to run FOSS on their chip... as FOSS implementations of typical embedded problems become prevalent (thank you Arduino) this becomes a terrible liability.
So the developers are smashing the windows and jumping out. But Cypress will be stuck razing the entire mansion, at great cost.
You make a key mistake: It is called a 'programmable system on chip', NOT 'run a bunch of retargetable c code on a chip without needing to know anything about hardware or electronics engineering'.
ReplyDeleteThis is crucial mistake that a lot of people make when dealing with small microcontrollers. Too often the stance or idea is 'we'll develop some code in c++ , yank it through GCC (aka :the 'Great Crap Compiler' ) and spit it in a 20 cents chip and our work is done. We'll go for venture capital funding and become the next dot-something billionaires.
Sorry if i sound ascerbic but this is the reality of the thing. GCC is a great compiler if you want low cost. But, as someone wrote, it is made for register based processing cores... Most 8 bit machines are accumulator based. It's like trying to fit a wrench on a pig ... The other problem with GCC is that it is a one-for-all compiler. They heavily rely on a runtime engine to 'emulate' the 'missing' instructions. On small systems that is a catastrophical failure. That is why purpose built compilers like Keil/IAR and others are still around. The quality of the produced output is much better (faster and denser) than GCC will ever be able to do. Simply because somebody that actually understands the core wrote the compiler as opposed to 'somebody who has a mindest on how a cpu 'should work' and then kludges in a translation layer to adapt for the 'imperfections against his 'ideal cpu'.
Now, as to the FOSS bandwagon. Cypress ( and others ) are in it to sell chips. OF course they are going to tie you to their platform. In an ideal world we would write code once , and it would run on any cpu without modification. That way we could rage a pricewar and the cheapest garagebox in india or vietnam would win the market with their below market priced parts. If everything would be free we wouldn't need money .. right ? We could go back to a bartering economy. I'll give you 5 fishes for this 55 inch tv.
I also don't get these whole endless windows vs 'open source' wars. If you are developing an embedded system the computer / debugger / ide / compiler / programmer are TOOLS , just like your screwdriver and soldering iron. You need a screwdriver ? you buy one, you need a soldering iron ? you buy one. You need a compiler ? you buy a computer and licence to the compiler and run it. They are TOOLS. I have two computers set up. One runs linux the other one Windows. no problem . just like i have phillips and flat tip screwdrivers. And if i ever need to develop anything for OsX i'll get a Mac too , ( just like i will have to buy torx screwdrivers ).
Honestly , i cant't understand this 'if it don't run on xyz i refuse to use it and i will whine about it ' attitude.
Anyway. just my 2 cents.
You make a key mistake: It is called a 'programmable system on chip', NOT 'run a bunch of retargetable c code on a chip without needing to know anything about hardware or electronics engineering'.
ReplyDeleteThis is crucial mistake that a lot of people make when dealing with small microcontrollers. Too often the stance or idea is 'we'll develop some code in c++ , yank it through GCC (aka :the 'Great Crap Compiler' ) and spit it in a 20 cents chip and our work is done. We'll go for venture capital funding and become the next dot-something billionaires.
Sorry if i sound ascerbic but this is the reality of the thing. GCC is a great compiler if you want low cost. But, as someone wrote, it is made for register based processing cores... Most 8 bit machines are accumulator based. It's like trying to fit a wrench on a pig ... The other problem with GCC is that it is a one-for-all compiler. They heavily rely on a runtime engine to 'emulate' the 'missing' instructions. On small systems that is a catastrophical failure. That is why purpose built compilers like Keil/IAR and others are still around. The quality of the produced output is much better (faster and denser) than GCC will ever be able to do. Simply because somebody that actually understands the core wrote the compiler as opposed to 'somebody who has a mindest on how a cpu 'should work' and then kludges in a translation layer to adapt for the 'imperfections against his 'ideal cpu'.
Now, as to the FOSS bandwagon. Cypress ( and others ) are in it to sell chips. OF course they are going to tie you to their platform. In an ideal world we would write code once , and it would run on any cpu without modification. That way we could rage a pricewar and the cheapest garagebox in india or vietnam would win the market with their below market priced parts. If everything would be free we wouldn't need money .. right ? We could go back to a bartering economy. I'll give you 5 fishes for this 55 inch tv.
I also don't get these whole endless windows vs 'open source' wars. If you are developing an embedded system the computer / debugger / ide / compiler / programmer are TOOLS , just like your screwdriver and soldering iron. You need a screwdriver ? you buy one, you need a soldering iron ? you buy one. You need a compiler ? you buy a computer and licence to the compiler and run it. They are TOOLS. I have two computers set up. One runs linux the other one Windows. no problem . just like i have phillips and flat tip screwdrivers. And if i ever need to develop anything for OsX i'll get a Mac too , ( just like i will have to buy torx screwdrivers ).
Honestly , i cant't understand this 'if it don't run on xyz i refuse to use it and i will whine about it ' attitude.
Anyway. just my 2 cents.
Other posters have commented on the difficulty of getting gcc to work with an accumulator based processor. This is and interesting fact that I did not know when I wrote this, but it makes sense now that you guys point it out. Thanks for the insight.
ReplyDeleteWRT to your comment about "run a bunch of retargetable c code on a chip not needing to know anything about hardware or electronics", the situation is really the opposite. I have done it enough times that it is no longer interesting or exciting to write time-insensitive code in assembly or to dig through someone else's poor assembly implementation in an attempt to fix their bugs.
Its not the cost of the compiler that I don't like as much as the lack of language features. Yes one *can* write relatively efficient C++ code if you don't "new" like a java programmer (and other things)!
And the cost of the chip (and the difference between it and the ATMEGA -- about 50c), means that it is much harder to justify the significant additional development expense required to write code for it.
WRT tying me to their platform... that's an 80's strategy. Nowadays there is no better way to make me run than to attempt to lock me in. After all, its a simple $3 chip. I can replace it in the schematic and layout in less than a day.
As you said, they are in it to sell chips. So just sell CHIPS! Write software to hide and help me with any ugly and nasty hardware tricks :-). For example, Cypress (if you are reading this), calling a C function from an assembly interrupt handler.
Its not like Cypress is providing cool and unique software... they are playing catchup. I can get everything they provide via FOSS. Their implementations ought to be the best-in-class FOSS with a simple portability layer to their register set. Not a complete reimplementation in assembly!
The PSOC hardware blocks ARE very cool. But if it means I have to (re)write all kinds of code in Cypress assembly, I think I'll pass.
I am a freshman in college, and I recently received a PSoC 5 "FirstTouch Starter Kit". I've used the Arduino before and I will say, the learning curve for this processor and accompanying IDE is TREMENDOUS! I really want to start getting it working doing some simple serial communication and PWM readings but I am just stumped!! :(
ReplyDeleteYes its pretty tough. I don't have the CY8C, I have the CY7C so probably can't help that much as its a different CPU core. But one thing I noticed in the PSOC 5 firsttouch description is that it claims "Programmable PLD-based logic". This means that you may have to do some FPGA-style programming as well as normal von-neumann machine C programming to get your device to work.
ReplyDeletePerhaps a simpler chip to get you started... what are you trying to do?
No - Just because the PSoC 3 and 5 have "Programmable PLD based logic" does not make life more difficult - You dont need to do FPGA type programming unless you want to go outside the pre-defined "components" and create your own.
ReplyDeletePWMs and Serial communication components are all there - just drop them in using PSoC Creator, wire them up, build the project and you will have all the interfacing API's written for you in C, named as you named the components.. Its all there, its like building your own MCU having the internal blocks you need .. want 6 PWM's, an ADC, and serial communications, just pick the UMs you want, drop them in - you can even link these with logic primitives now...
Dont get bogged down by the heavier stuff, thats the trick! I started with PSoC 1 about 10 years ago, and became a CYPros - The new family is far easier to use.. But the advanced stuff (moving into component creation and the FPGA stuff etc, can be really heavy - but I still think easier than some FPGAs, and PSoC Creator is, IMO, superb - as is the free C compiler)
FJM.