Page 1 of 2

PSoC based possibilities

Posted: Wed Jun 11, 2008 11:04 am
by jharvey
I'm a big fan of PSoC's, they offer many features not found on other chips for a low cost. I recently found this article about using it as a tach and thought I should post it here

http://www.psocdeveloper.com/docs/appno ... n2301.html

Take notice of how few parts it requires. Also note that there is a lot of expansion room left in the PSoC.

Re: PSoC based possibilities

Posted: Wed Jun 11, 2008 4:46 pm
by toalan
I work with PSOC on a daily basis.

As a general platform they are not good, by most typical metrics they totally suck:
-banked memory,
-3MIPS @ 24mhz,
-power hungry.

Also:
-it has poor documentation,
-small user base. psocdeveloper.com is the main forum about psoc and this forum has more activity on it than that,
-no onboard ICE. You need to purchase a special debug version of the uC for debugging,
-debugger + special chip costs $400 USD,
-no GCC, up until about 4 months ago the only C compiler was ImageCraft C and that was total garbage but it was cheap @ $100. Now there is Hitech C, which is very good but it costs $1k.
-I have ran into a few bugs with the development software and the uC.

The biggest thing that rubs me the wrong way is that those uCs look like they have lots of flash space. I use the Cy824894 and it has 16k of flash, 16k looked great and I though I would never get close to using it all, but once you configure all the analog and digital blocks I had only about 9k left. Immagecraft C compiler could not optimize for sh*t so basically I ran out of flash space. I use Hitech C compiler and that saved the project.

The next biggest concern was user community, I prefer AVR just because of the huge user community at http://www.avrfreaks.net, I can ask a question go to the bathroom, come back, and I have several answers. On psocdeveloper.com there is very little activity. PSOC is much more complex than a typical 8 bit uC, so it makes user community all that more important.

For smaller projects where space and cost are key, PSOC is probably the best choice. No one else has those programmable analog and digital blocks, they offer so much flexibility, almost too much flexibility. The programmable blocks are so good that I am willing to put up with all the bad stuff I posted previously.

I hear that by the end of this year a new generation of PSOC uC will come out with an updated core, one version will have an ARM core. With that PSOC will dominate the market if they can get their act together WRT to documentation and refine the dev tools.

I regret using PSOC for my project as I would have had 10x less work if I had used AVR. The only saving grace is that I will have a jump start when the new generation of PSOC devices hit the market, but they were supposed to hit the market a year ago.

Re: PSoC based possibilities

Posted: Wed Jun 11, 2008 4:54 pm
by Fred
toalan wrote:this forum has more activity on it than that
WOW, this forum is all but dead except for me ;-)

Thanks for the information, it is interesting to learn about the different options for sure!

Fred.

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 10:55 am
by jharvey
toalan wrote:As a general platform they are not good, by most typical metrics they totally suck:
-banked memory,
-3MIPS @ 24mhz,
-power hungry.
To be honest with you it's been a little while since I've used my cube. I seem to recall the on-board clock goes up to like 50 to 60MHz. I also seem to recall it was around 8-10 MIPs. I haven't used the aftermarket compilers, I've been quite happy with PSoCDesigner's compiler. The asm compiler is free (as in low cost) and the C compiler was $150. To me it sounds like you were using it as a high end DSP more then a dedicated task processor. PSoC's aren't good for processor heavy tasks. They are good for things like a tach signal,
but probably not good for tach, fuel, spark, and other all at once with a single chip. They offer hardware to do filters, signal generation, and basic digital IO where other processors do it in software. So often a task that requires many MIP's, has a reduced MIP requirement because of the hardware. Personally I like the hardware approach, because you can connect a scope to it and see what's going on.

For the VR circuit in MS, it uses and op-amp chip and MCU chip. The PSoC can do it in one chip while adding more features. I see lots of overhead left in the above noted reference design. Picture using one of the left over analog blocks to have an on-board scope. I've seen this done in FPGA's where you can't get a scope in the chip, they often make a scope in the design, so that you can look at what's happening. The extra resources in the PSoC design could allow for a similar scope option.

I'd agree that the documentation could use some work. I usually felt like the information I needed was there, but it was a bit hard to drag it out of the documentation.

I'd also agree they don't really focus on the typical matrix. They aim for thinking outside the box, and try to keep things flexible. Flexibility can be a curse or a blessing. For example with an AVR, an on-board scope simply isn't an option, but with a PSoC it's more complicated to get the basic design, so it's harder to start with.

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 11:17 am
by jharvey
Here's a reference design that could likely be modified for a knock sensor

http://www.psocdeveloper.com/docs/appno ... n2186.html

With a couple adjustments, it could be changed to detect the signature of engine knock instead of glass a glass break signature.

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 3:25 pm
by ababkin
Hi, very interesting discussion here

I've been researching various types of ICs recently but never read anything about the PSoC. I appreciate you 'guys in-the-know' giving us a short breakdown on them, this really gives a quick picture for us - people who know nothing about this technology.

Can anyone tell me (before i start researching those things in more depth) what parallels are there (if any) between these devices and programmable logic (i.e FPGA/CPLD), i suspect there are some, vs ordinary uCs, as someone mentioned flexibility and DSP functions in the earlier posts

In regards to tach task, don't forget that the tach-decoder and fuel/spark-scheduler have to be coupled time-wise, as perfectly as possible (to avoid delays, especially if delays are variable). So, IMO, it's best to do those two tasks on one chip, and preferably on a chip that has as close to zero-time response to hw interrupts/signals as possible.

EDIT: sorry for my impatience, i was able to find most answers to my questions here: http://en.wikipedia.org/wiki/PSoC

Thanks
Alex

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 4:54 pm
by toalan
It is really hard to compare PSOC to anything else; other uCs, FPGA, CPLD.

The primary strengths of PSOC is the programmable analog blocks. Each block has something like a switch capacitor and amplifier. You can use only 1 block to make something simple like a 6 bit DAC or a single pole filter, or your can chain several of them to make something more complex; Instrumentation amplifier, ADC. There also is alot of flexibility due to built in multiplexers and ability to route signal internally from one pin/block to another pin/block.

Same deal with the programmable digital block, each digital block has a timer and comparator, and you can use them to make stuff like; PWM, counters, UART, etc....

For advanced users you can work with the components of the programmable blocks directly and make you own custom peripherals.

PSOC offers an extra axis of freedom, laying out the blocks is similar to laying out pcb, and it can take alot of time to make good use of all its resources.

PSOC also has some cool things like a built in switch mode pump, that is great for battery powered devices but not very useful for automotive applications. I am not sure you would really want to make a battery device based on PSOC as I find the power consumption to be very high for an 8bit micro. You will find alot of paradoxes like that when you play around with PSOC.

It all sounds a bit complex, and it does take alot of timer to get used to. The stuff that cypress does is really as cutting edge as you can get in the low end microcontroller market. The programmable blocks are 5 years ahead of its time, but everything else is 5 years behind, a new core that is supposed to be released the end of this year should address many of its shortcomings.

Regards,

Alan To

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 5:01 pm
by toalan
To be honest with you it's been a little while since I've used my cube. I seem to recall the on-board clock goes up to like 50 to 60MHz. I also seem to recall it was around 8-10 MIPs.
I believe that the core itself is limited to 24mhz, and there is an internal clock that that can go upto 48mhz, but the 48mhz can only be used by the digital blocks. I also believe that it is about 6-8mhz per MIP, so 24mhz would be 3-4 MIPs.

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 5:36 pm
by jharvey
ababkin wrote: Can anyone tell me (before i start researching those things in more depth) what parallels are there (if any) between these devices and programmable logic (i.e FPGA/CPLD), i suspect there are some, vs ordinary uCs, as someone mentioned flexibility and DSP functions in the earlier posts
Sounds like you already learned there aren't any real comparisons. The on-board MCU is a DSP because it has a MAC and uses Harvard architecture, but there really isn't a comparison against any other thing out there. The best approach is to download PSoCDesigner (it's free as in low cost) and play with it some. They did a nice job in making the general flow work well.

About the timing, the big thing there is to keep delays consistent. That shouldn't be a big deal with a PSoC. There are times when the timing trigger is critical, like for spark, and there are times when it's bit less critical, like with fuel. If you had a PSoC that sent out the timing on a buss of some sort, then you could pick it up via multiple other circuits. If you had a spark output module, you could route the timing signal to several spark outputs modules, for multiple cyl's.

I think a PSoC could be used very well for controlling say spark output, or fuel output, or tach input quite well. As for a head unit, it could likely work, but perhaps a different chip would go well there. Rabbit or Arduino perhap? Any how I'm trying to focus on PSoC possiblities here.

Re: PSoC based possibilities

Posted: Thu Jun 12, 2008 5:40 pm
by jharvey
toalan wrote:I also believe that it is about 6-8mhz per MIP, so 24mhz would be 3-4 MIPs.
The tech ref notes this

The CPU core, called the M8C, is a powerful processor with
speeds up to 24 MHz. The M8C is a four MIPS 8-bit Harvard
architecture microprocessor. Within the CPU core are
the SROM and Flash memory components that provide
flexible programming. The smallest PSoC devices have a
slightly different analog configuration.

So 4 MIPS max.