Tipps uns Tricks zu Komponenten

Umgang mit PSoC Logikkomponenten
Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Tipps uns Tricks zu Komponenten

Beitrag von Reiner W. » Di 13. Okt 2015, 14:17

Die API - Funktionen der meisten Komponenten sind i.d.R. recht flexibel.
Manchmal wünscht man aber, dass sich bestimmte Konfigurationen zur Laufzeit Umschalten lassen,
für die es keine API-Funktion gibt.
I.d.R. kann man das machen, indem man die entsprechenden Register direkt manipuliert. Das
ist aber häufig schlecht bis gar nicht dokumentiert.

Erste Anlaufstellen (in PSoC 4) sind:

PSoC 4100/4200 Family PSoC 4 Architecture TRM, Document No. 001-85634 Rev. *C
http://www.cypress.com/file/126171/download
Ein sehr gutes Dokument, mit vielen Beispielen, wie mit Hilfe der Register
Komponenten direkt angesprochen werden können

PSoC 4 Registers TRM, Document No. 001-90002 Rev. *A

http://www.cypress.com/file/126381 zu finden.

Hier finden sich alle (na ja sagen wir die allermeisten) Register im Detail.

Am schnellsten kann man sich die Zusammenhänge häufig zusammenreimen, wenn man den vom
PSoC Creator generierten Quellcode der API der betreffenden Komponente genauer ansieht.

Komponenten werden ja i.d.R. mit der Funktion NameOfComponet_Start() gestartet.
Die benutzt i.d.R die Funktion NameOfComponet_Init() um die Komponente zu konfigurieren.
Und in der findet man dann leicht die nötigen Register/Konstanten zum setzen der in der
Komponente direkt hinterlegten Parameter.
Im Kontextmenü kann man sich leicht mit Go To Declaration/Definition durch die relevanten
Dateien hangeln.

Das dauert manchmal bis man alle Infos gefunden hat, deshalb hab ich mir gedacht, es
könnte recht hilfreich sein, wenn hier entsprechende Tipps zusammengetragen werden.
Ich geh dann auch mal mit 2 Beispielen voran, in der Hoffnung, dass der eine oder andere
ähnliche Tipps beiträgt;-)
Reiner W.

Thomas Barth
Administrator
Beiträge: 90
Registriert: So 5. Apr 2015, 21:46
Wohnort: Frankfurt/M
Kontaktdaten:

Re: Tipps uns Tricks zu Komponenten

Beitrag von Thomas Barth » Mi 14. Okt 2015, 11:14

Zunächst erst einmal Danke für die Links und den Beitrag.
Reiner W. hat geschrieben:Am schnellsten kann man sich die Zusammenhänge häufig zusammenreimen, wenn man den vom
PSoC Creator generierten Quellcode der API der betreffenden Komponente genauer ansieht.
So habe ich es bisher auch gemacht, was ein wenig schade ist, ist das die Treiber bei einer Neugenereierung inkl. Änderungen überschrieben werden. Gibt es da evtl. Spezielle Kommentarzeilen/preprozessordirektiven mit denen man eigenen Code dauerhaft einbinden kann?

Code: Alles auswählen

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S
                                   ((1.0/C_M_LSB_BH) *
                                   G_M_INFO_DERIVE(T_ALG.E_BH)))

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: Tipps uns Tricks zu Komponenten

Beitrag von Reiner W. » Mi 14. Okt 2015, 16:08

Gibt es da evtl. Spezielle Kommentarzeilen/preprozessordirektiven mit denen man eigenen Code dauerhaft einbinden kann?
Ja, da hab ich auch schon Lehrgeld zahlen müssen;-)
Leider hab ich da auch noch nichts gefunden. ISRs platziere ich generell local mit ComponentName_IRQ_StartEx(LocalIsr); , obwohl ja die meisten Komponenten APIs extra Platzhalter im Source reservieren. Aber spätestens mit Clean and Build wars das dann.
Außerdem finde ich es sehr unübersichtlich, wenn eigene Funktionalitäten aus dem Sichtfeld in irgend einem API-File verschwinden.
Aber du hast recht, ich habe in einem anderen Beispiel den IDAC um eine eine Funktion idc_set_polarity() nachgerüstet, mit der man zur Laufzeit zwischen Sink und Source umschalten kann, wodurch man sich häufig den zweiten IDAC sparen kann.
Und sowas würde eigentlich ins API-File gehören.
Überhaupt ist die API Generierung nicht sehr konsistent, allein wenn ich an die verschiedenen ISR Möglichkeiten denke. Aber das ist wohl nicht zu vermeiden, wenn sich ein System entwickelt.
Was sicher cool wäre, eine Preprozessor Anweisung, mit der man eine API-Funktion mit einer eigenen sozusagen austauschen könnte.
Was auch cool wäre, wenn Komponenten im Quellcode vorlegen würden und man die einfach als Ausgangsbasis für eigene Komponenten hernehmen könnte. Aber wir sind hier nicht im Wunschkonzert;-)
So muss man halt immer aufpassen. Dafür pfuscht einem aber auch keiner in den eigenen Quellcode mit automatisch generiertem Code.
Reiner W.

Thomas Barth
Administrator
Beiträge: 90
Registriert: So 5. Apr 2015, 21:46
Wohnort: Frankfurt/M
Kontaktdaten:

Re: Tipps uns Tricks zu Komponenten

Beitrag von Thomas Barth » Mi 14. Okt 2015, 16:21

Werde mal gucken wie ich es Cypress vorschlagen kann ;)

Bei mir war es ein SPI Treiber den ich umgeschrieben hatte.

Code: Alles auswählen

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S
                                   ((1.0/C_M_LSB_BH) *
                                   G_M_INFO_DERIVE(T_ALG.E_BH)))

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: Tipps uns Tricks zu Komponenten

Beitrag von RA1981 » Do 15. Okt 2015, 15:33

Hallo zusammen,
Was auch cool wäre, wenn Komponenten im Quellcode vorlegen würden und man die einfach als Ausgangsbasis für eigene Komponenten hernehmen könnte. Aber wir sind hier nicht im Wunschkonzert
Soweit ich weiss könnt ihr doch die Komponenten direkt in eine eigene Komponentenbibliothek importieren und dort die jeweiligen APIs nach Lust und Laune anpassen, Quellcode ist offen - dann sollte es das Problem mit C/B oder automatisch überschriebenen Sourcen nicht mehr geben.
Was sicher cool wäre, eine Preprozessor Anweisung, mit der man eine API-Funktion mit einer eigenen sozusagen austauschen könnte.
Hmmm... du meinst so etwas wie das weak attribute im GCC? Wäre aber ein ordentlicher Aufwand, den kompletten PSoC Katalog entsprechend auszurüsten (soll ja konsistent sein). Ich hab das eigentlich immer andersrum gehandhabt, ich habe mittels #define meine Wunschfunktion entsprechend angegeben und eben im Code das Symbol aufgerufen. Oder versteh ich dich hier falsch?

Ralf

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: Tipps uns Tricks zu Komponenten

Beitrag von Reiner W. » Do 15. Okt 2015, 15:53

Hi Ralf,
Soweit ich weiss könnt ihr doch die Komponenten direkt in eine eigene Komponentenbibliothek importieren und dort die jeweiligen APIs nach Lust und Laune anpassen, Quellcode ist offen - dann sollte es das Problem mit C/B oder automatisch überschriebenen Sourcen nicht mehr geben.
Hast du da nähere Infos? Das wäre interessant. Als Ganzes kann ich die Komponente ja in einer eigene Komponente integrieren. Das wäre ja auch noch eine Möglichkeit. Dabei bleibt aber die Komponente inkl. ihrer eigenen API erhalten. Das hab ich mir auch schon überlegt. Na die langen Winterabende stehen ja vor der Tür;-)
ich habe mittels #define meine Wunschfunktion entsprechend angegeben und eben im Code das Symbol aufgerufen.
Bring doch mal ein Beispiel.
Ich würde z.B. hin und wieder gern die init() der Komponente austauschen, wenn die, wie beim ADC oder IDAC, einige Parameter nur mit den Default-Konstaten der Komponente initialisiert.
Reiner W.

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: Tipps uns Tricks zu Komponenten

Beitrag von RA1981 » Fr 16. Okt 2015, 11:38

Hi Reiner,
Hast du da nähere Infos? Das wäre interessant. Als Ganzes kann ich die Komponente ja in einer eigene Komponente integrieren. Das wäre ja auch noch eine Möglichkeit. Dabei bleibt aber die Komponente inkl. ihrer eigenen API erhalten. Das hab ich mir auch schon überlegt. Na die langen Winterabende stehen ja vor der Tür;-)
1) Bibliotheksprojekt erstellen
2) Im Workspace-Explorer den Reiter Components wählen
3) Rechtsklick auf Projekt -> Import Component wählen
4) Komponente aus der gewünschten Originalbibliothek wählen
5) Komponente ändern
6) Bibliothek erstellen
7) Fertig :P

Sehr geschickt und sehr mächtig, wenn man die Komponenten anpassen kann. Wichtig ist halt, dass man sich überlegt was und wie man es tut, denn ggf muss man nach jedem Update der Originale ja dann auch seine eigenen Komponenten wieder neu anpassen!
Bring doch mal ein Beispiel. Ich würde z.B. hin und wieder gern die init() der Komponente austauschen, wenn die, wie beim ADC oder IDAC, einige Parameter nur mit den Default-Konstaten der Komponente initialisiert.
Die einfachste Variante wäre das hier:

Code: Alles auswählen

//#define customFunc_Init(x) Func_Init(x)		//Originalinitialisierung
#define customFunc_Init(x) myFunc_Init(x)		//Eigene Initialisierung
Durch Auskommentieren der jeweiligen Implementierung wird jeweils geswitched. Wichtig ist dann halt, dass man die Komponentenfunktionen nirgends direkt aufruft (sonst wundert man sich, dass nach dem switchen nix passiert :lol: )

Gruß Ralf

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: Tipps uns Tricks zu Komponenten

Beitrag von Reiner W. » Fr 16. Okt 2015, 14:20

Hi Ralf,

1000 Dank! Gerade ausprobiert. Funktioniert klasse.
Du hast natürlich recht, gerade im Hinblick auf Komponentenupdates ist da große Vorsicht geboten. Aber man kann sehr gut lernen, wie die Komponenten aufgebaut sind.
Wollte mich ohnehin demnächst mal mit dem Erstellen von Komponenten beschäftigen.
Die einfachste Variante wäre das hier:
Da hab ich wirklich nicht klar ausgedrückt. Das ersetzt natürlich nicht die Originalaufrufe, wenn die von anderen Funktionen aufgerufen wird. Im Falle der ini() wird die ja z.B. automatisch von der Start() aufgerufen. Und wer weis, von wo sonst noch.

Da hab ich gleich mal ne Frage an die C-Gurus. Werden unused functions eigentlich vom GCC wegoptimiert?
Reiner W.

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: Tipps uns Tricks zu Komponenten

Beitrag von RA1981 » Fr 16. Okt 2015, 15:59

Hi Reiner,

gern geschehen ;) Freut mich wenn ich helfen kann.
Das ersetzt natürlich nicht die Originalaufrufe, wenn die von anderen Funktionen aufgerufen wird. Im Falle der ini() wird die ja z.B. automatisch von der Start() aufgerufen. Und wer weis, von wo sonst noch.
Also möchtest du wirklich quasi die Funktionen überschreiben können? Das wäre m.E. ein Fall für "weak" und ggf in Verbindung mit "alias", als Erklärung z.B. das hier:
http://www.valvers.com/programming/c/gc ... ttributes/

Wenn ich dich richtig verstehe wäre das dann genau das was du suchst. Mit "weak" sagst du, dass diese Funktion aufgerufen werden soll, wenn keine andere definiert wurde, und mit "alias" kannst du den Aufruf umbiegen.
Das blöde wäre nun, dass man wirklich alle Komponenten umbiegen müsste, damit es konsistent ist. Man sollte mal als größere Gruppe an Cypress herantreten und sie bitten, für das nächste Release alle Komponenten um das weak-Attribute zu erweitern =)
Da hab ich gleich mal ne Frage an die C-Gurus. Werden unused functions eigentlich vom GCC wegoptimiert?
Du meinst Funktionen in einem Sourcefile, welche nicht aufgerufen werden? Das kannst du doch einfach herausfinden, indem du vergleichst um wieviel größer der Speicherbedarf ist, wenn du die Funktion doch aufrufst: sind's nur ein paar Byte, dann ist das nur der Aufruf der (bereits vorhandenen) Funktion, ist es spürbar mehr, dann ist es der Aufruf und die Funktion zusätzlich. Ich würde sagen, zum Test einfach eine Funktion schreiben, in der ein größerer Text auf einer Schnittstelle ausgegeben wird.

Gruß Ralf

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: Tipps uns Tricks zu Komponenten

Beitrag von Reiner W. » Fr 16. Okt 2015, 18:12

Hi Ralf,
Also möchtest du wirklich quasi die Funktionen überschreiben können? Das wäre m.E. ein Fall für "weak" und ggf in Verbindung mit "alias"
Ja, genau. Aber wie schon sagst, wird es schwierig, das ganze konsistent hinzubekommen.
Da gefällt mir der Ansatz mit dem modifizieren originaler Komponenten schon besser. Evtl könnte man es so hinbekommen, dass die eigenen Teile in einem eigenen Sourcefile gelagert sind und in die Komponente nur inkludiert werden. Dann reduziert sich die Änderung der Originalkomponente auf den #include und bei Komponenten-Update muss dann ggf. ebenfalls nur der #include gemacht werden.
Ich werde da mal etwas rumbasteln und schauen ob das brauchbar ist.
Du meinst Funktionen in einem Sourcefile, welche nicht aufgerufen werden?
...indem du vergleichst um wieviel größer der Speicherbedarf..,
Ja sicher. Hatte nur gehofft, jemand sagt ja oder nein ;-)
Funktionen würde ich ungern aus der API rausschmeissen, wer weiss schon, was das nach sich zieht. Bei 32k (PSoC 4) will ich die aber auch nicht unnütz im Speicher haben.

Generell hat es schon Vorteile, Funktionen die quasi die API erweitern, in die Komponente einzubinden. Man muss den Kram nicht jedesmal neu schreiben bei einem neuen Projekt. Bisher hab ich das immer in einem eigenen Modul ausgelagert. Da muss man aber aufpassen, dass man die Komponente immer gleich benennt, oder jedesmal sein Modul ändern.

Gruß und schönes Wochenende
Reiner W.

Antworten