Cypress PSOC programmers please comment.

Hello.
Myapp is for a PSC motor controller (speed and direction) there are many 
app notes for various chips eg Microchip AN967 gives decent details, 
code and so on. I am used to 8051 and with the given data from Microchip 
appnote AN967 would be able to impliment a similar control system.

I went to my chip vendor who suggested instead of staying with the 8051 
family to try Cypress PSOC because he said it was so easy to use as to 
almost make the programmer redundant. However, in reality it seems that 
when one has unusual requirements there may be a similar workload as 
would be the case if I stuck with my tried and trusty 8051 variants 
(inlude Atmel Mega).


I am wondering if the learning curve for a newbie to create such a 
driver for PSOC would take me longer to implement than for the likes of 
familiar 8051 or AVR in C.

If anyone here has been using the PSOC system, and has previous 
experience with other micros I'd be particularly interested in your 
comments as to the development curve for new addons, and comments in 
general.
Kind regards,
Alistair.

Alistair George wrote:
> Hello.
> Myapp is for a PSC motor controller (speed and direction) there are many 
> app notes for various chips eg Microchip AN967 gives decent details, 
> code and so on. I am used to 8051 and with the given data from Microchip 
> appnote AN967 would be able to impliment a similar control system.
> 
> I went to my chip vendor who suggested instead of staying with the 8051 
> family to try Cypress PSOC because he said it was so easy to use as to 
> almost make the programmer redundant. However, in reality it seems that 
> when one has unusual requirements there may be a similar workload as 
> would be the case if I stuck with my tried and trusty 8051 variants 
> (inlude Atmel Mega).
> 
> 
> I am wondering if the learning curve for a newbie to create such a 
> driver for PSOC would take me longer to implement than for the likes of 
> familiar 8051 or AVR in C.
> 
> If anyone here has been using the PSOC system, and has previous 
> experience with other micros I'd be particularly interested in your 
> comments as to the development curve for new addons, and comments in 
> general.
> Kind regards,
> Alistair.

My PSOC Experience is over a year old, so It may have improved.
The analog components are poor.  they work, but are not hi precision.
The temperature range is lower that the PIC.  The power consumption is 
quite high with the analog components on.  The pin configure-ability is 
limited.  You can not put any pin anywhere.  The tools are good.  You 
need them the number on configuration registers is huge.  The learning 
curve is not too bad for the tools.  The digital blocks worked very 
well.  I liked them. The core does not have bit instructions, you have 
to mask. The compiler is $145  It is a great $145 compiler.
It is not a good $1000 compiler.  The code is large.  The interrupt 
handling is poor, you may have to do them in asm.  The Tool box has a 
lot of pre-done code modules you can just click to include.
There was no bootloader, or room for one (in my app).  It programs SPI 
like the PIC.
The limitations are glossed over in the docs.  I had to trip over them.
Like the temperature sensor is useless.  The chip draws enough current 
to rise 10-20C  So you temperature is within that range.

I was disappointed with the chip.
There is a good web site for it www.psocdeveloper.com

The chip is a good choice for many things.  Their marketing pushes it to 
hard.  It is not the 8-bitter to replace all others.

Thanks Neil. A lot of hype from the company as you say. I have been 
playing around with the IDE today. So far it makes little sense.
Al.

Alistair George wrote:
> Hello.
> Myapp is for a PSC motor controller (speed and direction) there are many
> app notes for various chips eg Microchip AN967 gives decent details,
> code and so on. I am used to 8051 and with the given data from Microchip
> appnote AN967 would be able to impliment a similar control system.
>
> I went to my chip vendor who suggested instead of staying with the 8051
> family to try Cypress PSOC because he said it was so easy to use as to
> almost make the programmer redundant. However, in reality it seems that
> when one has unusual requirements there may be a similar workload as
> would be the case if I stuck with my tried and trusty 8051 variants
> (inlude Atmel Mega).
>
>
> I am wondering if the learning curve for a newbie to create such a
> driver for PSOC would take me longer to implement than for the likes of
> familiar 8051 or AVR in C.
>
> If anyone here has been using the PSOC system, and has previous
> experience with other micros I'd be particularly interested in your
> comments as to the development curve for new addons, and comments in
> general.


I helped a student with a simple project using a PSOC a couple of years
ago when I was visiting a friend's lab. It went quite well but I feel
that a conventional MCU like an AVR or a PIC would be just about as
easy to use, and a lot better for most applications.

Leon

Alistair,

I have worked with many micros from way back starting in 1976. It seems to
me that people's opinions are highly coloured by which micros they first
used and the subsequent paths and experience. I came to the PIC 16XXX
family relatively recently and I regard them as a throwback to the 8748,
only worse in some ways. Now I don't mean to start a flame thread since
there is a sizable cadre of PIC users who swear by its capabilities. It is
rare to find a micro that is so perfect for a task that no other micro will
do. And if it is the case, what happens on the next project?

Each micro has its advantages and disadvantages. If you are concerned
about the capabilty of any 8 bit micro in terms of execution speed etc.
then you should be looking at 16 bits or better anyway. The PSoC micro is
a middle of the road micro- no great shakes,  but my applications are not
cutting edge in terms of speed. But the PSoC is more than a micro. Aside
from the CPU it has an array of analog and digital blocks which you
configure to realize the I/O configuration that you need. Unlike an 8051
where you get a fixed number of timers and UARTs, here you get to make the
choice within the limitations of the device. If you need 3 UARTS well you
can do it. You can also allocate I/O pins: I once used a single UART to
communicate with 4 external devices in turn by changing the I/O pins
dynamically. The blocks are somewhat like an FPGA and can be modified
dynamically so that you can change the configuration on the fly. Let's say
you are working with a half duplex serial port, and you have maxed out the
resources. A UART takes two logic blocks, (Tx and Rx) but on the PSoC you
can use a single logic block as a  TX to send the message and then
reconfigure to an Rx for the response.

Yes there are limitations on the analog circuitry. Keep in mind it is a
$3-4 device with both digital, analog and the reconfigurabilty running on
the same piece of silicon. Just because you can configure a 14 bit A/D,
doesn't mean you get even close to an external part made exclusively to
convert perfectly.

But the whole package comes together well. As an 8051 programmer, I don't
think you will have any trouble making the transition, and both Cypress 
and the users on PSoCDeveloper.com (of whom I am one) are extremely
helpful. Some of the time I may sound like an apologist, but what I would
like to convey is this. I remember the good old days where there was a new
peripheral to consider almost every week- I remember the 8255, the 8251 the
Zilog PIO, memory mapped I/O versus I/O mapped I/O; it was an exciting time
where you could use your ingenuity. The PSoC re-captures that.

-Aubrey 

"Alistair George" <noname@xtra.co.nz> wrote in message
news:44b82f8d$1@news.orcon.net.nz...
> I went to my chip vendor who suggested instead of staying with the 8051
> family to try Cypress PSOC because he said it was so easy to use as to
> almost make the programmer redundant. However, in reality it seems that
> when one has unusual requirements there may be a similar workload as
> would be the case if I stuck with my tried and trusty 8051 variants
> (inlude Atmel Mega).
>
>
> I am wondering if the learning curve for a newbie to create such a
> driver for PSOC would take me longer to implement than for the likes of
> familiar 8051 or AVR in C.
>
> If anyone here has been using the PSOC system, and has previous
> experience with other micros I'd be particularly interested in your
> comments as to the development curve for new addons, and comments in
> general.

    The PSoC is a 8051 core, more or less.  They've added a bunch of
configuration and paging registers to fit in all the things the chips can
do.  For the price, they are good chips; I like them a lot to replace
low-precision op-amps, comparators, etc.  I've uses them as a slave display
driver by putting a UART and a timer in, and used them as active filters by
plugging in a 4-pole LPF with some gain on other occasions.
    They are very low cost in quantity; most projects I've used them in end
up with the chip in die form, no external crystal.  My stuff is normally
room temperature, so that's not an issue.  The wide supply voltage is a plus
(2.7-5.5V), making it easy and cheap to do battery-powered devices.
    The architecture is limited, being based on the 8051.  Their tools are
reliable, but quirky.  Expect to spend some time figuring out how to really
use them.
    Cypress does have some PSoC-family parts that do USB, and 2.4GHz radio.
They have announced plans for improved parts with ARM-based cores and
higher-precision analog later this year.

-Travis

Aubrey and Travis thanks for your comments. Aubrey I already joined the 
PSOCDeveloper forum and see you are very active there.
Downloaded the flash video and thats sold me on the flexibility of the 
beast(s).
I'd love a low-cost emulator (the cypress one comes out at $US600) but 
for me thats a big investment.

But its a no-brainer to build a specific task one as per Cypress appnote 
an2323.pdf

Otherwise, Aubrey et all, if any know of a redundant ICE somewhere 
please lets know!
Alistair.
PS I found one already sold Cypress ICe on Ebay; sold for $US36!

>PS I found one already sold Cypress ICe on Ebay; sold for $US36!
>
Be careful of the ones on e-bay. If they are the older variety and may not
support all the new devices. An ICE 4000 is OK for a normal 8 bit
application, provided you don't need expanded memory and some of the more
specialised devices. I guess $40 would be fine in this regard. Check the
Cypress web site for compatibilty. It also operates on the parallel port
of the PC, so you need a PC that will support it. Even then some people
had problems with some of the parallel ports and versions of Windows if I
remember correctly. 

The current emulators are called ICE-Cubes.

-Aubrey

Alistair

I forgot to mention that if you buy an ICE cube, the C compiler is
included in the price. (in case this fact helps in your financial
calculations)

-Aubrey

Alistair George wrote:
> Thanks Neil. A lot of hype from the company as you say. I have been 
> playing around with the IDE today. So far it makes little sense.
> Al.

Select and place the blocks.  Connect the cross bars.
Configure the clocks.  Then configure the pins.
The environment should make a skeleton program.