Hallo, ich hätte da mal eine Frage bzgl. der PSoCs von Cypress. Im Rahmen meines Studiums bin ich dabei, mich in Diese einzuarbeiten. Ich frage mich allerdings immernoch, wo die wirklichen Vorteile in der Industrie liegen? Wenn ich es richtig verstanden habe, ist in den PSoCs immer ein µC integriert, der wiederum mit einer Eingangs- und Ausgangslogik ähnlich der Logik bei CPLDs verbunden werden kann. Laut der Videos kann man den PSoC entweder in C programmieren, womit der integrierte µC "normal" beschrieben wird oder das Verhalten als Schaltplan mit verschiedenen Modulen in Hardware abbilden, wodurch der µC schlafen gelegt werden kann. Ist dies nun ein zusammenklickbarer CPLD/FPGA mit zusätzlichem µC für weitere Softwareaufgaben? Als Vorteile sehe ich die nahezu freie Belegung der Pins und den anscheinend einfachen Einstieg. Aber habt ihr schon Erfahrungen mit den PSoCs in der Industrie sammeln können? Wo liegen die Vorteile gegenüber einem STM oder ARM bzw. einer konkreten Lösung auf CPLD/FPGA-Basis? Für FPGAs kann man ja auch noch Softcores nutzen, die einem zusätzlich noch ermöglichen, alte abgekündigte Hardware weiterhin einzusetzen. In welchen Fällen macht es also Sinn zu einem PSoC von Cypress zu greifen? Hoffe, ihr könnt mir da vielleicht etwas erzählen. Viele Grüße
Hallo Max, obwohl ich als Rentner und Hobbybastler mit dem industriellen Einsatz der PSoC's nichts zu tun habe, möchte ich von meinen Erfahrungen berichten. Gegen die Beschäftigung mit PSoC's spricht: - Es gibt keine deutschsprachige Community, sondern nur Cypress und Psocdeveloper.com. - Es mangelt an deutschsprachiger Literatur. Die Bücher von Hardy Krüger spiegeln nicht den gegenwärtigen Stand wider, sondern PSoC1 und 3. - Die neueren PSoC's haben keine hobbyfreundlichen Gehäuse, sind also für Grobmotoriker schwer zu löten. Deshalb verwende ich bis jetzt nur vorgefertigte Baugruppen, z.B. CY8CKIT's oder Schmartboard- bzw. die FreeSoc Explorer Kits. Aber was spricht dafür? Besonders die PSoC5LP (und mit Einschränkungen PSoC3) haben besondere Fähigkeiten, die man sonst nicht findet: - digitale Filer, die unabhängig vom Hauptprozessor arbeiten, - die Möglichkeit, mit VERILOG eigene Baugruppen zu entwerfen, - viele vorgefertigte analoge und digitale Baugruppen, die man bequem am PC auswählen und verschalten kann. Für mein Hobby (Amateurfunk) sind sie auf der NF- Seite sehr gut geeignet, digitale Übertragungsverfahren ohne Zuhilfenahme eines PC zu ermöglichen. Auch als Zentrale für intelligente Messinstrumente sind sie gut zu gebrauchen. Ich sehe auch eine große Chance für die studentische Ausbildung, verschiedene Teilgebiete der Elektronik zu verknüpfen (Programmierung in C, Analogtechnik, Digitaltechnik, Interaktion von Hard- und Software, Kommunikation zwischen µC's). Nur Mut!!
:
Bearbeitet durch User
Die CY8CKIT-049 sind ja PSoC4 basiert, und gerade die haben keine Filter, oder? Zumindest in den Datasheets http://www.cypress.com/?docID=46324 habe ich nichts gefunden. Dabei wären die Platinchen in einem DIL Package und sind auch sehr günstig (<5€). Das neue CY8CKIT-059 PSoC ist PSo5 basiert, kommt in einem 2xDIL-26 "Package/Platine" und ist leider noch nicht lieferbar. Sollen 10$ kosten, sind dann wohl in D deulich unter 20€ zu haben. Siehe: http://www.cypress.com/?rid=108038. Dieses Kit könnte man (mit einem 2x16 LCD und PS2 Keyboard Anschluss) zu einem wirklich preisgünstigen CW/PSK31 En- und Decoder ausbauen. Zusammen mit einem einfachem Einband Superhet TRX (oder Direktmischempfänger) und evtl. einem der einfachen DDS AD9850 Ebay Platinchen kann so ein netter, preiswerter TRX entstehen. Der AD9850 kann CW und DDS Signale (bei geeigneter Programmierung) direkt erzeugen, aber wahrscheinlich nur einigermaßen sauber im 80m oder 40m Band, evtl. noch im 20m Band. Im 15m Band, das für DO-ler interessant wäre (habe selbst "nur" eine E-Lizenz, DO4KR) produzieren diese DDS Module wahrscheinlich zu viele Obertöne. Wäre interessant, ob dann noch (mit den Endstufen Tiefpässen oder auch zusätzlicher Filter) brauchbare CW oder PSK Signale rauskommen). Dazu noch eine 5W Endstufe, z.B. vom Funkamateur. Das PSoC steuert den DDS, kümmert sich um Ein- und Ausgabe und um die CW/PSK Erzeugung bzw. Decodierung. Das sollte der 80MHz Cortex-M3 normalerweise spielend schaffen, zumal wenn man die Filtergruppe von PSoC nutzt. Evtl. könnte man auch jene motivieren, die mit SMD auf Kriegsfuß stehen, da man ja fertige Platinen für SSD und PSoC nutzt. Wäre mal ein interessantes Projekt. Edit: Ich sehe gerade, dass du, Wolfgang, ja schon so ein AD9850 Modul mittels eines PSoC angesteuert hast: http://www.wkiefer.de/x28/Verdrahtung%20im%20Chip%20mittels%20Software.htm. Ist das eigentlich der letzte Software stand deines Deocders? Beitrag "Hard- und Software vereinfacht"
:
Bearbeitet durch User
Hallo Klaus, Klaus Rotter schrieb: > Ist das eigentlich der letzte Software stand deines Deocders? > Beitrag "Hard- und Software vereinfacht" ... natürlich nicht, denn ich bin ständig am Verbessern... Jetzt bin ich auf dieses Projekt gestoßen: http://www.nue-psk.com/ und versuche gerade, das Ganze auf einen PSoC5 (plus PSoC4 für die PS/2- Tastatur) zu portieren. Im Moment teste ich die Einbindung eines Grafik- LCD's 128 x 64 für die Anzeige des Spektrums. http://www.pollin.de/shop/dt/Mzg4ODc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_WAYTON_MG1206E_SYL_128x64.html
DH1AKF K. schrieb: > und versuche gerade, das Ganze auf einen PSoC5 (plus PSoC4 für die PS/2- > Tastatur) zu portieren. Brauchst du für die PS/2 Tastatur einen extra µC? Wieso das den?
... vielleicht, weil es die Ami's auch so machen..? Die nehmen allerdings einen DS-PIC33.
@Wolfgang Vielen Dank für die Infos. Aber habe ich das denn richtig verstanden, dass der Hardwareteil vom Compiler in einer HDL umgesetzt wird? Dass der analog-Part gerne von Amateurfunkern genutzt wird, habe ich schon öfters gelesen. Für rein digitale Anwendungen sehe ich einem "klassischen" µC aber kaum Vorteile oder übersehe ich da etwas? Sehe ich das richtig, dass die Hauptunterschiede der verschiedenen PSoCs die implementierten Cores sind (8051, M0 etc.)?
Hallo Max, > habe ich das denn richtig verstanden, dass der Hardwareteil vom Compiler in einer HDL umgesetzt wird?< Das ist nur bedingt richtig. Die Hardware- Bestandteile sind sozusagen vorgefertigt, und es wird bei Bedarf die zugehörigen Firmware eingebunden. Dein Anwendungsprogramm verwendet diese Firmware für Initialisierung, Parameterübergabe sowie die Kommunikation mit der Hardware. Man kann aber auch eigene Komponenten entwickeln: a) mit VERILOG b) aus Datapath- Komponenten c) aus Macrocells- Strukturen Genaueres hier: http://www.cypress.com/?docID=43232 Die letztgenannten Komponenten werden tatsächlich mit einem Compiler aus Deinen Vorgaben erzeugt. Ich habe anhand eines Vorbild- Programms in kurzer Zeit einen I/Q- Generator mit Verilog zum Laufen gebracht. (Das ist ein doppelter Rechteckgenerator mit 90 Grad Phasenverschiebung).
Hallo Wolfgang, das klingt wirklich spannend. Aus der von Dir verlinkten Application Note scheint es so, als wenn z.B. die Uart- und I2C-Komponenten (als Beispiel) dann Verilog-Code erzeugen und bereits in eine UDB eingebunden sind. Bei Nutzung wird die Firmware dafür geladen und der µC kann diese Funktion jetzt nutzen. Für die noch frei zur Verfügung stehenden UDBs kann ich mir aber auch alle möglichen eigene Komponenten überlegen? Theoretisch könnte ich in so eine UDB also USB-Pakete einlesen und in ein IP-Paket wandeln und einfach nur durchschleusen. Das ganze könnte dann direkt in Hardware geschehen und der µC schläft die ganze Zeit oder kann andere Dinge machen; korrekt? Kannst Du mir vielleicht noch ein Eval-Board empfehlen, mit dem ich dort einsteigen könnte? Da gibt es ja doch ein paar mehr. Viele Grüße
Oh, stimmt (fast), die nehmen einen extra µC, einen Freescale 68HC908. Ob das unbedingt nötig ist? Das PS/2 Timing ist doch eigentlich leicht. Clock geht auf einen GPIO, der bei Low einen Interrupt auslöst und dann wird in der ISR an einem zweiten GPIO (auf dem Data liegt) das Bit übernommen. Mittels ein LUT, passend für ein paar angesagte Tastaturlayouts (US, DE, GB, ...) wird dann der ASCII Code übergeben). Gut, der µC muss der Tastatur die Bereitschaft Scancodes zu empfangen mitteilen, dazu zieht er nach dem empfangen des Stopp-Bits, erstmal Clock auf Low. Wenn er wieder bereit ist, Daten zu empfangen, geht Clock wieder auf High.
Max schrieb: > Sehe ich das richtig, dass die Hauptunterschiede der verschiedenen PSoCs > die implementierten Cores sind (8051, M0 etc.)? Nicht ganz. Ich hatte mich vor Jahren mal mit den PSOC1 herumgeärgert, bis ich die Dinger dann wutentbrannt in die Ecke geschmissen habe. Man konnte bei denen nämlich NICHT so einfach seine eigene Logik darin unterbringen, sondern NUR das, was bereits in der Bibliothek des Herstellers war. Bei den PSOC4 und 5 soll der ganze wohl etwas besser aussehen. Aber ich bin über das allererste Ausprobieren des Psoc-Creators nicht hinaus gekommen. Grund: Beim Ausprobieren habe ich gemerkt, daß man mit separaten IC's letztlich dann doch wesentlich besser kommt als mit den PSOC's. Also ein zur Aufgabe passender µC, ein zur Aufgabe passendes CPLD und den Analogteil quasi auch diskret, also OpV's, ADC's, Komparatoren usw. Natürlich kann so ein PSOC von allem irgendwie ein bissel, aber eben nicht wirklich so gut wie die entsprechenden separaten Teile. Das Einzige, was da noch zählt, wären eben die Bemerkungen von Wolfgang "Die neueren PSoC's haben keine hobbyfreundlichen Gehäuse". Aber wenn man keinen Drahtigel erschaffen will, sondern ein richtiges Gerät, dann ist sowieso eine dafür passende LP angesagt. Über eventuelle Grobmotorik sollten wir uns hier nicht streiten, da ist zu allererst eine ordentliche Feinmechaniker-Lupenbrille angesagt und dann geht das plötzlich. Der Knackpunkt sind die Leiterplatten selber. Vom richtigen LP-Hersteller kosten sie ne Menge Geld und von der Größe her ist man entweder auf Hobbymaße (80x100 oder so) begrenzt oder auf mickrige Pinzahlen oder man muß sich mit hakeligen Bastel-CAD-Programmen herumärgern. Das sind die eigentlichen Problempunkte, die das Verwenden von PSOC's nahelegen. W.S.
Hallo Max, > Theoretisch könnte ich in so eine UDB also > USB-Pakete einlesen und in ein IP-Paket wandeln und einfach nur > durchschleusen. Das ganze könnte dann direkt in Hardware geschehen und > der µC schläft die ganze Zeit oder kann andere Dinge machen; korrekt? ... im Prinzip ja, aber die Ressourcen sind begrenzt. Ein Beispiel(PSoC5) I/Q- Generator, Ressourcenverwendung: Digital domain clock dividers : 3 : 5 : 8 : 37.50% Analog domain clock dividers : 0 : 4 : 4 : 0.00% Pins : 18 : 54 : 72 : 25.00% UDB Macrocells : 114 : 78 : 192 : 59.38% UDB Unique Pterms : 248 : 136 : 384 : 64.58% UDB Total Pterms : 255 : : : UDB Datapath Cells : 0 : 24 : 24 : 0.00% UDB Status Cells : 1 : 23 : 24 : 4.17% Status Registers : 1 UDB Control Cells : 6 : 18 : 24 : 25.00% Control Registers : 6 DMA Channels : 1 : 23 : 24 : 4.17% Interrupts : 1 : 31 : 32 : 3.13% DSM Fixed Blocks : 0 : 1 : 1 : 0.00% VIDAC Fixed Blocks : 0 : 4 : 4 : 0.00% SC Fixed Blocks : 0 : 4 : 4 : 0.00% Comparator Fixed Blocks : 0 : 4 : 4 : 0.00% Opamp Fixed Blocks : 0 : 4 : 4 : 0.00% CapSense Buffers : 0 : 2 : 2 : 0.00% CAN Fixed Blocks : 0 : 1 : 1 : 0.00% Decimator Fixed Blocks : 0 : 1 : 1 : 0.00% I2C Fixed Blocks : 0 : 1 : 1 : 0.00% Timer Fixed Blocks : 0 : 4 : 4 : 0.00% DFB Fixed Blocks : 0 : 1 : 1 : 0.00% USB Fixed Blocks : 0 : 1 : 1 : 0.00% LCD Fixed Blocks : 0 : 1 : 1 : 0.00% EMIF Fixed Blocks : 0 : 1 : 1 : 0.00% LPF Fixed Blocks : 0 : 2 : 2 : 0.00% In de 4. Spalte steht jeweils die verfügbare Anzahl. Klaus Rotter schrieb: > Mittels ein LUT, passend für ein paar angesagte > Tastaturlayouts (US, DE, GB, ...) wird dann der ASCII Code übergeben). Ja, aber es sind auch die Shift-, Alt- und Alt-Gr - Tasten zu behandeln. Außerdem die Make- und Break- Codes ... Ich habe halt erst einmal eine zusätzliche PSoC4- Baugruppe für 5 Euro vorgesehen, (die vielleicht auch für andere Zwecke nutzbar ist.) Empfehlung: auf dieses Teil warten: http://www.cypress.com/?rid=108038 Es enthält Programmer und Debugger. Grüße aus Elsterberg (Vogtland)!
:
Bearbeitet durch User
Angehängte Dateien:
-
PSoC_Kit.jpg
76 KB
Leider gibt es diese Kit's nicht mehr: CY8CKIT-014 (First touch starter kit) Daraus habe ich schon einiges gebaut, siehe Foto (der Baustein rechts). Sie enthalten ebenfalls einen Debugger, kosteten damals (vor 2 Jahren) 50 Dollar... Aber es gibt auch andere nette Sachen: STM32F429, Teensy 3.1, usw. Beide verfügen über einen USB Host, das hat PSoC5 noch nicht.
:
Bearbeitet durch User
Hallo Wolfgang, klar, es muss natürlich von der Größe her in die UDBs passen; war nur ein altes Projekt, das ich mal mit programmierbaren Logik umgesetzt habe und von der Theorie her dran denken musste. Also gleich mit einem PSoC5 anfangen und dafür das entsprechende Eval-Board raussuchen? @W.S. Auch Dir danke für deine Infos. Dann werde ich wohl die PSoCs1 wohl erstmal außen vor lassen und wirklich gleich einen größeren nehmen.
Max schrieb: > Also gleich mit einem PSoC5 anfangen und dafür das entsprechende > Eval-Board raussuchen? Ja, das ist auf jeden Fall zu empfehlen! Es gibt aber auch in D ein Kit, welches außer PSoC4 noch einen PSoC 5LP verbaut hat: http://www.voelkner.de/products/477756/Cypress-Semiconductor-PSoC-4-Pioneer-Kit-CY8CKIT-042.html?ref=43&products_model=W12082&gclid=CKaRjIv5ucQCFY_MtAodWxgArQ Es ist im Preis günstig und ermöglicht auch den Zugriff auf die PSoC5LP - Ressourcen, allerdings mit Einschränkungen. Die Einschränkungen: - Für PSoC5 kein Debugger, sondern ein Bootloader. - nur wenige PIN's herausgeführt
Das Board sieht super aus! Werde mir das wohl mal anschaffen um auch praktisch ein Gefühl dafür zu bekommen, was mit den PSoCs möglich ist. Bei dem Board scheint ja schon einiges vorhanden zu sein. Vielen Dank für deine Hilfe und Beratung! Werde wohl jetzt erstmal Erfahrung damit sammeln müssen. :)
Also ich beschäftige mich jetzt seit ein paar Monaten mit dem PSoC 4 CY8CKIT-049. Vorweg, ich bin immer noch begeistert. Mein Einstiegsprojekt war eine Anzeige für Digitale Messschieber, wo ich dachte, dass ich die interne Hardware gut einsetzen konnte. Bei der ersten Version für einen Messschieber ging das auch ganz gut auf. Die im KIT enthaltene USB-Schnittstelle zur Ein-/Ausgabe per PC. Interne Komparatoren zur Messschieberanpassung. PWM-Komponente, die einen Buzzer für akustische Warnung steuert. PWM-Komponente zur Encoder Steuerung. 24bit Schieberegister zur Verarbeitung des SYLVAC Messschieberprotokolles. LCD - Komponente für ein 20x4 Display. Ein paar interne Kardwarebausteine zur Ansteuerung eines 4x4 Keypads zur Grenzwerteingabe. Interner Hardwaredebouncer zur Entprellung diverser Taster. Alles im Baustein drin. Messschieber dran und der Softwareaufwand hält sich in Grenzen. Mit den Hardwareressorcen des PSoC 4 bin ich grad hingekommen. AAAber, Dann kam natürlich der Wunsch auf, das Ganze für 3 Messchieber zu erweitern. Und da war Schluss mit PSoC 4. Also hab ich zwangsweise damit begonnen Hardwareressourcen freizuschaufeln und nach und nach die meisten Funktionen in Software zu realisieren. Und da hat sich gezeigt, dass sich fast alle Funktionen auch problemlos (und häufig flexibler) in Software realisieren lassen. Das betraf bei mir z.B. Das 24bit SR, das macht ich jetzt per IRQ und Counter per SW. Encoder, Keypad ließen sich auch problemlos per SW benutzen. Die Eigangskomparatoren konnte ich auch weglassen. Die Messschieber hängen jetzt direkt dran. Geblieben ist eigentlich nur die LCD-Komponente und PWM zur Interwalltonerzeugung sowie ein paar kleinere Hartwareteile bei geschwindigkeitsrelevanter Funktion. Außerdem darf man nicht vergessen, dass eine Softwareimplementation sich sicher einfacher auf andere ARMse portieren läßt. Fazit: Mit den integrierten Hardwarebausteinen geht vieles mal eben schnell zu realisieren. Allerdings ist bei PSoC 4 schnell Schluss mit den Hardwareressourcen. So richtig Spaß macht das dann sicher erst ab PSoC 5.Dafür kostet so ein CY8CKIT-049 nur eben 4,- € und in meinem Projekt sind kaum weitere Bauteile nötig.
Bin gespannt wann das 5LP Kit zu bekommen ist. Bin total gespannt auf die Filter.
DH1AKF K. schrieb: > Empfehlung: auf dieses Teil warten: > > http://www.cypress.com/?rid=108038 > > Es enthält Programmer und Debugger. Und, jemand drauf gewartet und kann seine Erfahrungen zum Besten geben? Würde mich mal interessieren. :)
Möwe schrieb: > Und, jemand drauf gewartet und kann seine Erfahrungen zum Besten geben? Ich hab das Teil getrennt. Den Programmer/Debugger nehme ich zusätzlich zur Programmierung von CY8CKIT-049. Mein aktuelles Projekt kann den Platz für den Bootloader gut anderweitig gebrauchen. http://www.psoc-community.de/viewtopic.php?f=9&t=19 Ansonsten ist das Kit meiner Meinung nach sehr gut geeignet auch ambitionierte Hobbyprojekte zu realisieren. Ich portiere grad mein letztes Projekt. Bei dem Preis und der der Größe lässt es sich ja problemlos direkt in Geräten verwenden. Für das CY8CKIT hab ich eine Platine gebastelt, wo ich das Kit und ein LCD Modul direkt draufstecken kann. Für das CY8CKIT-059 will ich es genauso machen. Leider sind die mal wieder Out of Stock. Warte immer noch auf meine Lieferung.
Ich arbeite gerade an einem Projekt, welches 3 UARTs, 3 I2C-Master, eine Menge GPIOs für Taster usw., ADCs und DACs verwendet und genau dafür ist der PSoC5 ideal. Zeigt mir einen anderen Controller, bei dem man so schnell mehrere I2C Master umsetzen kann, ebenso wie mehrere UARTs und Dinge wie Tastenentprellung nicht zu Fuß erledigt werden müssen... Ab einem gewissen Komplexitätsgrad ist man froh, so einen modernen Controller zu haben... Grüße! Sven
Ich habe hier auch noch zwei PSOC4 Kits rumliegen, aber mehr als die Beispielprogramme habe ich noch nicht gemacht. Es gibt leider sehr wenig Informationen darüber im Internet. Gruß
Wie bitte? Gerade zum PSoC 4 Kit gibt es "100 projects in 100 days" http://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true Wenn man PSoC Creator installiert kommen ein Haufen Beispiel-Projekte mit, zu jeder Peripherie mindestens eines. Andreas
Angehängte Dateien:
-
PSOC-Testplatine_3.jpg
300 KB
Hallo Felix, ich gerade gerade ein Board für den CY8CKIT-059 (PSOC5) von Cypress fertigestellt. Die Platine kostet etwas mehr als der PSOC4 hat aber einen Programmer Debugger on Board. Wenn Interesse für den PSOC4 besteht könnte ich das Layout für den PSOC 4 Kit anpassen. Ab 10-20 Stück würde es sich lohnen die Platine fertigen zu lassen. Beispielprogramme habe ich auch schon einige, z.B. eine Messinterface Software. Viele Grüße Josef Bernhardt
Angehängte Dateien:
-
100_0825.JPG
230 KB
Hallo, ich habe das Board ein wenig überarbeitet, es hat jetzt vier Potis. Von den Platinen habe ich noch welche! Eine Leerplatine kostet 6 Euro + Porto. Gruß Josef Bernhardt
Mit dem ARM Kern sind die PSoC wirklich interessant. Besonders in Sensor-Applikationen kommt die Hardware-Konfiguration effektiv zum Einsatz. Tolle Dinger, aber kein SecondSecond Source. Der Controller muss also zur Lebensdauer vom Produkt passen. :-*
Mit dem "psoc designer" bin ich damals auch erst mal nicht zurechtgekommen, aber es war eigentlich recht einfach. Die Beispiele und Dokumentation zu den ADC, Clocksystem, Interrups usw. gibt es direkt im Programm, das ist schön, man kann sie sich aber auch als PDF auf einem anderen Bildschirm anschauen da sie direkt in einem Unterverzeichnis des PSoC-Designers liegen. Es gab aber auch einen Fehler in einem Datenblatt. Für mich schien es so als ob der Compiler recht ineffizient arbeitet und die AVR im Gegensatz dazu weniger voll waren bei gleichem Programmcode. Also in einen 8kbyte Atmega8 hatte ich mehr reinschreiben können als in den 8kbyte PSoC1. Das Forum ist aber eigentlich ganz nett, es schreiben dort vor allem Inder und man hat mir auch gut geholfen. Die Möglichkeit Funktionen auf fast beliebige Pins zu legen ist auch sehr begrenzt. Teilweise erreicht man nicht mehr die volle Geschwindigkeit, man kann die Leitungen im Chip auch nicht so frei verbinden. Da man die Leitungen auf der Platine eh so legt wie man will ist diese Funktion nicht wirklich nützlich. Nett, aber eben nicht so sinnvoll. Die Möglichkeiten den Takt einzustellen sind viel besser als bei den ATmega, bei den ATXmega ist man da schon weiter und hat sich den PCoC gut angenähert. Max schrieb: > Bei dem Board scheint ja schon einiges vorhanden zu sein. Was ist denn auf dem 27 Euro Board großartig drauf? Du siehst da einen Touche-Slider, den man eh nicht nutzen kann da er ungünstig liegt und viel zu klein ist. Wenn du mal genau hoch schaust ist dort sonst nichts sinnvolles drauf. Kauf dir lieber das set: www.mouser.de/ProductDetail/Cypress-Semiconductor/CY8CKIT-059/ Der Programmer dort kann zum debugen/programmieren von PSoC3,4,5 genutzt werden. Man kann sich mit einem Permanentmarker eine Platine mit "CapSense"-Flächen zeichnen und ätzen oder dir Bereiche ausfräsen, so dass man eine genügend große Fläche hat die man real nutzen kann. Der CY8C5888LTI-LP097 dort auf dem Board besitzt 256kByte Flash, 64kbyte (!) S-Ram und 2kbyte EEprom und kostet einzeln normalerweise 10 bis 12US$. Richtig billig sind diese Chips also nicht. Josef B. schrieb: > ich gerade gerade ein Board für den CY8CKIT-059 (PSOC5) von Cypress > fertigestellt. Das ist etwas übertrieben. Ich hätte dort einreihige Buchsen auf die PSOC5 Platine gelötet (von oben) und dann dort einreihige Stecker reingesteckt mit Flachband-Kabel dran und eine kleine Lochrasterplatine, dann ist man flexibler und man kann die LEDs oder die Tasten abstecken und etwas andere ranstecken. Bei http://dirtypcbs.com bekommt man 10 Stück 10x10cm Platinen für 25 Euro, das ist teilweise billiger als eine einzelne Platine bei einem "normalen" Anbieter.
B.A. schrieb: > Mit dem "psoc designer" bin ich damals auch erst mal nicht > zurechtgekommen, Vlt. Solltest du dir noch mal den PSoC Creator ansehen. Da hat sich einiges getan. Mit CY8CKIT-042 049 059 für 4 /10/10€ Kann man speziell als Bastler ne Menge anfangen. Ich setz die immer direkt in meine Schaltungen ein. Eine Adapterplatine im Ardiuno Layout währ (für mich) ganz nett. Ich hab noch einiges an Shiels rumliegen und für schnelles Prototyping fänd ich das ganz hilfreich. Reiner
Hallo zusammen, richtig interessant wird der ganze Spaß mit dem PSoC5 LP. Wir setzen den in einer Industrieanwendung ein und haben alle I/Os des TQFP100 belegt. Dazu gehören 3x I²C Master, 3x UART, ADC, DAC, und eine Menge digitale I/Os zum Steuern der restlichen Schaltung. Als der Kunde ein Redesign der Platine in Auftrag gab, weil er andere Steckverbinder und eine andere Anordnung der Stecker wollte, musste alle I/O-Leitungen an anderen Pins angeschlossen werden. Das war mit dem PSoC-Creator innerhalb einer Stunde erledigt und neu kompiliert. Mit irgendeinem anderen Prozessor wäre ich da 1000 Tode gestorben! :) Natürlich gibt es gewisse Constraints beim internen Routing, gerade bei den analogen Signalen, aber in der digitalen Domain hat man so ziemlich freie Hand und kann da wunderbar "Bäumchen versteck Dich" spielen. Man sollte ggf. darauf achten, dass wenn bestimmte Reset-Zustände (Hi-Z, Low, High) eines Pins gewünscht sind, diese aber auf dem ganzen Port wirksam werden. Dort muss man beim Schaltungsdesign die Pins ggf. günstig gruppieren, aber sonst ist es so ziemlich egal wo etwas angeschlossen wird. Im Vergleich mit dem STM32 hatte ich bei dem Projekt wesentlich mehr Zeit mich auf das wesentliche Dinge, nämlich die Programmlogik, zu konzentrieren, da solche Dinge wie UARTs, I2C-Master, interner EEPROM, ADC, DAC... einfach funktionieren und über eine stark abstrahierte Software-API mit simplen Funktionen zu bedienen sind. In diesem Zusammenhang finde ich die Datenblätter der einzelnen Funktionskomponenten geradezu genial! Wer dennoch die Hardware zu Fuß bedienen möchte, der kann das natürlich tun, aber die Software-APIs sind ausgereift und gut durchentwickelt. Leider sind die PSoC5 LP nicht gerade günstig, weshalb wir die leider nicht in jedem Projekt einsetzen können. Viele Grüße! Sven
Mein Hauptproblem mit den Dingern ist eigentlich, dass man das Pojekt ziemlich schlecht mit einem Versionsvverwaltungssystem benutzen kann. Wenn ich für bestimmmte Teile Header oder Sourcecocde generieren lasse, ändern sich so ziemlich alle Dateien, obwohl ich zB nur eine Zeile in einer Datei geändert habe. Wenn ich das dann einchecke, kann ich später quasi nie genau sehen welche Datei eine relevante Änderung hat, oder ob sich nur ein Datum geändert hat... Vielleicht gibt es ja eine Möglichkeit das zu verhinder, falls einer die kennt, wäre ich sehr interesiert. Ich bin leider gezwungen ein Projekt damit zu betreuen das nicht von mir kommt.
Ich benutze GIT als Versionsverwaltung und habe mit dem automatisch generierten Code keine Probleme. GIT erkennt, dass sich die Files nicht geändert haben und checkt wie gesagt nur die Änderungen ein. Nervig ist, dass sich die Workspace-Datei bei jedem Furz ändert und dass sich im Projekt angelegte Unterordner nicht als solche auf der Festplatte wiederfinden. Es werden einfach alle Quellcodedateien in ein Verzeichnis geworfen. Ansonsten funktioniert der PSoC-Creator recht gut und ich kann nur jeden ermutigen Bugs zu melden, wenn er welche findet. So stürzte der PSoC-Creator mit einer Exception ab, wenn man die Schriftart vom Editor ändern wollte. Ich habe es gemeldet und gut war es dann ein oder zwei Versionen später. Im großen und ganzen bin ich zufrieden und es gibt wahrlich viel schlechtere Entwicklungsumgebungen. Viele Grüße! Sven
X2 schrieb: > Wenn ich für bestimmmte Teile Header oder Sourcecocde generieren lasse, > ändern sich so ziemlich alle Dateien, obwohl ich zB nur eine Zeile in > einer Datei geändert habe. Falls du damit meinst, du änderst etwas an den automatisch kreierten HAL Dateien, dass solltest du tunlichst unterlassen. Es gibt zwar für ISRs die Möglichkeit, diese in einen gekennzeichneten Bereich einer solchen Datei zu schreiben, aber besser, du bringst diese in einer eigenen Datei unter und lässt die automatisch generierten unangetastet. Ansonsten hat Sven schon alles gesagt. Seit ich weis, wie man den Creator unter Parallels Desktop am Mac zum Laufen bekommt, hab ich mit ihm meinen Frieden gemacht. Da gibt es wahrlich Schlechteres;-) Reiner
Reiner W. schrieb: > Falls du damit meinst, du änderst etwas an den automatisch kreierten HAL > Dateien, dass solltest du tunlichst unterlassen. > Es gibt zwar für ISRs die Möglichkeit, diese in einen gekennzeichneten > Bereich einer solchen Datei zu schreiben, aber besser, du bringst diese > in einer eigenen Datei unter und lässt die automatisch generierten > unangetastet. Das ist mir durchaus klar. Das habe ich auch nicht gemeint. Aber gerade diese HAL Dateien ändern sich bei jedem Build. Ich benutze allerdings auch eine ältere Version vom Designer, da sich mit einem Update der IDE auch die Module ändern und ich möglichst wenig ändern möchte. Vielleicht ist das mittlerweile anders.
Du solltest wirklich auf den PSoC-Creator 3.3 updaten! Es gibt Stellen im automatisch generierten Code, in denen man gefahrlos eigenen Code unterbringen kann (ISRs zum Beispiel), allerdings reißt es den Code dann schon ziemlich auseinander. Ich empfehle die isr_StartEx(Function); Funktion zu benutzen, welche die ISR durch die User-Funktion "Function" ersetzt. Seit Version 3.3 gibt es jetezt auch die Möglichkeit das ganze mit Defines zu regeln. Ein Blick in das C-File der ISR zeigt das recht gut. Du kannst Deine Designer-Projekte übrigens auch auf den Creator portieren. Viele Grüße! Sven
:
Bearbeitet durch User
X2 schrieb: > Aber gerade diese HAL Dateien > ändern sich bei jedem Build Die sollten sich nur bei Änderungen am HardwareDesign ändern (Creator 3.3). Allerdings nervt es mich auch gelegentlich, wenn sie bei jeder kleinen Taktänderung beim nachfolgenden Build neu geschriebenen werden. Kostet einfach unnötig Zeit. Man kann halt nicht alles... Reiner
Angehängte Dateien:
-
PSoC_1.jpg
91 KB -
PSoC_2.jpg
58 KB
Wegen anderer Projekte (RedPitaya) habe ich mich einige Zeit nicht mit PSoC beschäftigt. Nun bin ich überrascht, was Cypress auf der Roadmap zu stehen hat. Man darf gespannt sein, wann die neuen Prozessoren verfügbar sind ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.