Unterschied zwischen PSoC vs. normalem uC

Manuel Stein schrieb:
> Was ich herausgefunden habe -> -noramle uC haben nicht die Möglichkeit
> eines Delta Sigma ADCs

Da es µC mit Delta-Sigma-ADC gibt (z.B. den MSP430F2013), ist auch das 
nicht das entscheidende Merkmal.

Der entscheidende Unterschied ist die konfigurierbare analoge 
Signalaufbereitung. Die ist bei µCs sonst nur recht rudimentär 
ausgeprägt.

https://en.wikipedia.org/wiki/PSoC

Mit dem PSoC lassen sich sehr gut weite Schaltungsteile und sinnvolle 
Peripherie (OpAmps) in das IC integrieren. Die externe Beschaltung wird 
einfach weniger und die Schaltung kompakter.

Eine Stärke der PSoC5 sind zum Beispiel auch deren analoger und 
digitaler Interconnect: Du kannst, bis auf die Stromversorgung und die 
Hardware-OpAmps, jede Funktion auf jeden Pin legen. Natürlich gibt es 
auch da Grenzen, aber da muss man das Ding schon sehr gut ausnutzen, 
dass das zum Tragen kommt.

Die digitalen Filterblöcke sparen Dir mitunter einen gesonderten DSP auf 
der Platine.

Viele Grüße!

Sven

Geh mal auf http://www.cypress.com/cdc.
Dort findest Du jede Menge Infos zu den verschiedenen PSoCs. Es gibt 
PSoC1 und PSoC3 (8 Bit) sowie PSoC4 und PSoC5LP (32 Bit). PSoC1 würde 
ich aber als veraltet betrachten.
Vom PSoC4 gibt es das CY8CKIT-049-42XX für ca. 4 Euro. Das enthält neben 
dem PSoC4 noch einen PSoC5, der eine USB-Verbindung zu einem PC 
herstellt, über die programmert (aber nicht debugged) werden kann. Das 
Ding hat (aus dem Gedächtnis) 26 I/Os, mit denen man schon eine Menge 
anstellen kann.
Auf der Website gibt es auch Hunderte Beispiele für Projekte, die schon 
realisiert worden sind.

Ich habe schon viele Projekte mit PSoCs realisiert. Das Schöne ist, dass 
man fast keine andere Elektronik braucht, außer ein bißchen Vogelfutter.

Man kann in der Entwicklungsumgebung festlegen, welche analogen und 
digitalen Funktionen der PSoC haben soll, z.B. wie viele UARTs, und vor 
allem welche Pins diese Funktionen belegen sollen. Man kann sich quasi 
einen maßgeschneiderten Prozessor zusammensetzen.

Es gibt natürlich Grenzen. So kann z.B. nicht jede Funktion auf jeden 
Pin gelegt werden, und die Anzahl der A/D-Wandler ist auch begrenzt.

Am besten ist es, man lädt sich die Entwicklungsumgebung herunter (PSoC 
Creator) und registriert den Keil-Compiler einmal (kostenlos).
Dann konfiguriert man sich die Hardware, indem man die benötigten Module 
per Drag-And-Drop auf die entsprechende Seite zieht (ADC, DAC, Timer, 
Counter, Interrupts, MUX, OpAmp ...). Dabei muss man auch IO-Pins 
anlegen. Auf einer anderen Seite weist man dann den IO-Pins 
physikalische Pins zu. Dann übersetzen lassen. Dann weiß man, ob diese 
Konfiguration so geht.

Ich arbeite immer parallel mit Eagle und PSoC Creator. So kann ich das 
Layout einfach halten und bin gleichzeitig sicher, dass der PSoC kann, 
was ich will.

Die größeren PSoC5 arbeiten mit bis zu 80MHz und haben bis zu 256MB 
Flash und 64MB RAM. Es gibt verschiedene Gehäusebauformen, die TQFP100 
lassen sich noch recht gut von Hand löten.

Günter N. schrieb:
> Die größeren PSoC5 arbeiten mit bis zu 80MHz und haben bis zu 256MB
> Flash und 64MB RAM. Es gibt verschiedene Gehäusebauformen, die TQFP100
> lassen sich noch recht gut von Hand löten.

Korrektur: 256 kByte Flash und 64 kByte RAM. Es lässt sich aber externer 
RAM anbinden, sofern man dies wünscht.

Interessant sind zum Beispiel auch fertige Bausteine für 
Quadraturdecoder, Entprellung, Display-Ansteuerung HD44780, I2C, SPI, 
UART usw. - Man muss nicht mehr jedes Register einzeln einstellen (kann 
man aber). Die APIs sind ausgereift und die Code-Erzeugung durch den 
PSoC Creator funktioniert gut.

Obwohl der Creator hier und da auch so seine Macken hat, gibt es 
wahrlich schlechtere IDEs.

Bei größeren Projekten freut man sich, dass man sich auf das wesentliche 
konzentrieren kann und nicht noch den ganzen I/O-Kram mit Timern, 
Interrupts, FIFOs usw. zu Fuß erledigen muss. Zudem ist das Clocking 
über die interne PLL sehr gut zu konfigurieren.

Anbei ein Beispiel wie schnell man 4 Taster mittels Debounce-Komponenten 
entprellt und dann in entsprechende ISRs überführt.

Meiner Meinung nach ist der PSoC in vielen Anwendungsfällen einem STM32 
mit gleicher Geschwindigkeit überlegen und die Entwicklungszeit wird 
deutlich verkürzt. - Bei höheren Taktraten haben die STM32 die Nase 
vorn.

Viele Grüße!

Sven

Du hast natürlich Recht, 256kB Flash und 64MB RAM.
Man kann einen Teil des Flash auch als EEPROM einrichten, um Parameter 
dauerhaft zu speichern.
Wenn man mit sich ständig ändernden Werten zu tun hat und den letzten 
Messwert auch über ein Ausschalten hinaus erhalten will, ist es günstig, 
ein FRAM (gibt es jetzt auch von Cypress) mit einzubauen. Die sind 
(anders als EEPROMS) extrem schnell zu beschreiben und haben praktisch 
keine Lebensdauerbegrenzung.

Ich hab sowohl mit PSoC1 und PSoC5 gearbeitet. Einerseits ist man 
teilweise recht schnell weil es die API gibt, aber immer wieder ist 
genau das das Problem. Bei speziellen Problemen muss man erst mal 
herausfinden was die API da überhaupt macht und wie sich der Block im 
Kern überhaupt verhält. Wann wird z.B. ein Interrupt zurückgesetzt? Bei 
einem normalen µC schaut man ins Datenblatt und weiß bescheid, beim PSoC 
sind solche Infos sehr schwer zu finden (wenn überhaupt). Je komplexer 
die Aufgabe wird, desto mehr häufen sich diese Probleme.
Und dann noch die Beschränkung der Blöcke bzw. das man schlecht planen 
kann ob alles rein passt. Beim letzten Projekt mit PSoC5 sind z.B. die 
Clock-Quellen "ausgegangen", es waren also nicht mehr möglich. Das ist 
dann sehr ärgerlich.
Sie sind schon sehr interessant, aber ob ich das weiter empfehlen 
würde.. Ich weiß nicht. Bei "normalen" µC hab ich mich noch nicht so oft 
geärgert :)

DIE ANWENDUNG, die nur mit dem PSoC realisierbar ist und nicht oder nur 
schwer mit anderen Micros,  gibt es meiner Meinung nach nicht. Genauso 
wie es DIE ANWENDUNG fuer Atmel, AD, MSP, STM32, NXP Controller nicht 
gibt. Man kann fast immer alles mit allen machen, es kommt immer drauf 
an, letzten Endes auch auf persoenliche Vorlieben.
Der groesste Vorteil ist vielleicht der, dass viele Komponenten bereits 
auf dem Chip vorhanden sind und flexibel konfiguriert werden koennen, 
was den Platzbedarf auf der Platine reduziert.
Was vielleicht noch nicht genannt wurde, der PSoC, zumindest der 5lp, 
kann sich auch aus seinem integrierten Boostkonverter versorgen. Der 
akzeptiert ab 0.5V, fuer Versorgung aus Solarzellen z.Bsp.. Sind aber 
noch externe Komponenten notwendig, spart aber auch Platinenplatz.

Manuel Stein schrieb:

> @Sven L. - Da ich nicht so eingebettet bin im Bereich Elektronik, was
> für Beispiel-Schaltungen könnte ich denn in den PSoC-uC verlagern?

Direkte Beispiele kann ich Dir keine nennen, da diese Firmengeheimnisse 
sind, aber es gibt ein paar Szenarien:

Die internen Opamps können intern sowie auch extern beschaltet werden. 
Üblicherweise realisiert man damit zum Beispiel Mess- bzw. 
Intrumentenverstärker, um die Auflösung des wirklich guten ADCs auch gut 
ausnutzen zu können. Oder man benutzt die Opamps in Kombination mit 
FPGA-Schmitt-Triggern zur Signalformung bei jeglichen 
Empfangsschaltungen etc.

Des weiteren bietet es sich an jegliche Formen von Logikgattern, die man 
extern einsetzen würde, in den FPGA-Teil zu setzen. Das können einfache 
Dinge wie Negatoren oder einzelne Gatter sein, aber auch komplexere 
Dinge wie zum Beispiel ein Hardware-Zähler. Es wäre zum Beispiel möglich 
mit den entsprechenden Flipflops einen Hardware-Zähler im FPGA zu 
implementieren, mit welchem man einen Frequenzzähler umsetzen kann.

Ein Beispiel, was ich schon gesehen habe: Ein I/Q-Demodulator mit 
digitalen Filterblöcken und kompletter A/D- und D/A-Wandlung alles ohne 
externe Beschaltung. In Software ist da noch gar nichts passiert, 
sondern rein in Hardware.

Man muss natürlich die Grenzen des Designs kennen, aber die Auslegung 
des PSoCs ermöglicht es den Controller an vielfältige 
Anwendungsszenarien anzupassen, ohne auf einen anderen Typen 
auszuweichen. Was ich mit 10 verschiedenen dsPICs oder STMs oder SAMs 
machen kann, dafür reicht vermutlich ein einziger PSoC5LP, wobei es von 
diesem auch zig Versionen gibt (zusätzliche on-board Hardware wie zum 
Beispiel CAN-Transceiver oder ähnliches).

Weiter oben hat jemand den internen Boost-Converter genannt: Es ist in 
der Tat so, dass man nur die Speicherdrossel und die Diode extern 
braucht und schon kann man das Ding ab 0,5 V selbst versorgen.

Das Ding ist für kostenoptimierte Designs in hohen Stückzahlen gemacht, 
denn man kann i.d.R. 1-2 externe ICs und das dazugehörige Hühnerfutter 
wegoptimieren. Aber auch bei geringen Stückzahlen spart der Controller 
bei vielen Standardanwendungen enorm Entwicklungszeit gegenüber den 
Konkurrenzprodukten. Leider sind die PSoC5LP recht teuer mit ungefähr 
$10 bei 1k Abnahme.

Just my 2ct....

Sven

Sven L. schrieb:
> Anbei ein Beispiel wie schnell man 4 Taster mittels Debounce-Komponenten
> entprellt und dann in entsprechende ISRs überführt.

Das Bild zeigt ja schon, dass sich die Programmierung etwas von der 
konventionellen C-Entwicklung unterscheidet.
Der PSoC Creator stellt grafische Werkzeuge zur Verfügung, die die 
Verbindungen zwischen Analogen/Digitalen Komponenten generiert.
Der Vollständigkeit halber sei angemerkt, das die Debouncer Komponenten 
gleich 8 Tasten auf einmal debouncen kann (Sofern sie sich in einem 
PIN-Block befinden).

Jörg S. schrieb:
> Bei speziellen Problemen muss man erst mal
> herausfinden was die API da überhaupt macht und wie sich der Block im
> Kern überhaupt verhält.

Na ja, das sollte eigentlich für alle Plattformen gelten;-) Die 
Unterlagen von Cypress sind eigentlich sehr gut. (Wenn man dann mal die 
passenden gefunden hat) Die Datasheets zu den Komponenten sind in der 
IDE stets verfügbar und sauber gepflegt. Dafür könnte es für mein 
Geschmack ruhig etwas mehr Beispiele geben.

Mark W. schrieb:
> DIE ANWENDUNG, die nur mit dem PSoC realisierbar ist und nicht oder nur
> schwer mit anderen Micros,  gibt es meiner Meinung nach nicht.

Wohl war. Allerdings ist es schon so, dass die meisten (kleineren 
Projekte) ohne zusätzliche Hardware auskommen, weil halt ne Menge 
analoger/digitaler Standardkomponenten gleich mit im Chip drin sind.

Hallo Manuel,

in einem Projekt hatte ich z.B. einen analogen Sensor. Der Messwert 
wurde im PSoC über einen OpAmp mit einstellbarem Gain verstärkt, dann 
gefiltert und mit einem ADC digitalisiert. Weiter wurden 2 serielle 
Schnittstellen verwendet und eine EEPROM-Komponente. Mehrere Tasten zur 
Bedienung wurden auch direkt angeschlossen.

In einem anderen Projekt habe ich mit einem einzigen PSoC3 6 
UART-Schnittstellen in Hardware realisiert sowie einen DMS-Verstärker, 
hier allerdings mit zwei INA125 zusätzlich.

Ich sage nicht, dass das mit anderen Controllern nicht geht. Ich habe 
aber den Eindruck, dass die Konfigurierbarkeit der analogen und 
digitalen Hardware viele Möglichkeiten bietet.

Manuel Stein schrieb:
> Vielen Dank! Echt Super von Euch, für die sehr schnelle Antworten.
>
> @Mark W. - Könntest du mir bitte ein Beispiel nennen indem ich
> Komponenten spare?

Schau Dir mal das Voltmeter Beispiel von Cypress an und ueberlege wie 
man das mit einem uC loesen wuerde, um auf uV Aufloesung zu kommen. Der 
PSoC kann das mit nur auf dem Chip vorhandenen Komponenten.
Also generell wurde ich sagen, dass saemtliche Analogsensoren mit den 
eingebauten Komponenten gut auswertbar sind.
Alles was bei anderen uC noch an Analogfrontend extern dazu kommt, hat 
man bereits auf den Chip. Also Opamps, Filter, Analog Multiplexer(64 
Eingaenge), Comparatoren usw.

Letztendlich muss man das selbst ausprobieren und vergleichen. Du kannst 
eine Aufgabenstellung an 10 verschiedene Leute vergeben und realisieren 
lassen. Du wirst 10 verschiedene Loesungen, die bestenfalls alle den 
Anforderungen entsprechen, bekommen. :-)