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!!
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"
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?
@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.
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.
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.
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.
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ß
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
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
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
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 ...
