# Beckhoff/CoDeSys Lib in C



## Anaconda55 (20 Dezember 2011)

Hallo,
gibt es irgendwelche Nachteile eine CoDeSys Lib in C anstatt ST/AS zu implementieren?
Eventuell im Bezug auf Hardwarekompatibilitäten?


----------



## RobiHerb (21 Dezember 2011)

Wenn man es zum Laufen bringt (Dokumentation äusserst dünn!) dann sollte es nur von dem C Compiler abhängen, ob man effektiver geworden ist als mit ST. 

Ich vermute, C native Code ist schneller, da weniger Prüfung etc. einfliesst als im defensiven ST (Pascal). Natürlich läuft es nur auf dem System, für das der C Compiler den Code erzeugt. 

Ich habe Erfahrung mit Codesys unter WIN CE und dem MSC 6.0 Compiler. Mehr Arbeit reingesteckt als effektiv gewonnen.


----------



## Werner29 (21 Dezember 2011)

Natürlich gibt es die. Erstens ist das erstellen umständlicher, man braucht einen C-Compiler, der auch
das passende Format liefern muss. Es wird nicht alles unterstützt, was ein C-Compiler kann, das merkt man
dann vielleicht erst bei der Verwendung der Lib. Und natürlich ist die Lib dann nur für eine Hardware geschrieben.
Wann immer es geht sollte man eine Lib in IEC schreiben. Wir (3S) schreiben alle unsere Libs in IEC, ausser die
Systemspezifischen, die direkten Zugriff auf Betriebssystemeigenschaften brauchen, die sind dann Teil
des Laufzeitsystems.

Bernhard


----------



## Anaconda55 (23 Dezember 2011)

ST wird doch auch kompiliert? Läuft das ST kompilat dann nativ oder in einer virtuellen Maschine?
Wenn ich eine binäre Lib die mit ST geschrieben ist weitergebe, dann müsste ich ja die selben Probleme haben, da der Sourcecode nicht vorhanden ist und dieser für ein anderes Zielsystem kompiliert wurde!?


----------



## zotos (23 Dezember 2011)

Anaconda55 schrieb:


> ST wird doch auch kompiliert?
> ...



Ja wird es aber den passenden Compiler hat der Anwender (der Lib) in der Regel eh schon, da er ja seinen eigenen Quellcode mit der Lib zusammen übersetzt.
Bei C ist er eigentlich immer darauf angewiesen die passende Lib zu seinem Zielsystem zu haben. Dies macht eben nur dann Sinn wenn es nicht anders geht (wegen Betriebssystemfunktionen).

Werner29 hat es ja bereits ausführlich erklärt warum 3s die Libs in einer IEC Sprache verfasst und in welchen ausnahmen sie zu C greifen.


----------



## Anaconda55 (23 Dezember 2011)

Das heißt aber jetzt trotzdem, dass wenn ich eine Lib entwickle in ST und den Quellcode nicht mitgebe, dass der Lib-Anwender dann eventuell Probleme bekommt mit der kompilierten Version. C oder ST ist dann egal.


----------



## RobiHerb (23 Dezember 2011)

Anaconda55 schrieb:


> Das heißt aber jetzt trotzdem, dass wenn ich eine Lib entwickle in ST und den Quellcode nicht mitgebe, dass der Lib-Anwender dann eventuell Probleme bekommt mit der kompilierten Version. C oder ST ist dann egal.



Wenn ein anderes Target bedient werden soll, nützt im Prinzip eine LIB ohne Source nix. Man hat aber das gleiche Problem überall, nur, wer den Source hat kann das System wechseln. Wer dann noch den Compiler selber schreiben kann, also auch dessen Source hat, hat alle Karten.

Eine Ausnahme (leider, da ich vom Entwickeln lebe) ist Microsoft .NET, da gibt es Tools, die aus einer LIB oder EXE wieder einen brauchbaren Source erstellen können. Deshalb gibt es auch wieder Tools, die den Source vor dem Compi8lieren so verunstalten, dass man auch Hyroglyphen verwenden kann.

Schöne Weihnachten ansonsten.


----------



## Anaconda55 (23 Dezember 2011)

> Eine Ausnahme (leider, da ich vom Entwickeln lebe) ist Microsoft .NET,  da gibt es Tools, die aus einer LIB oder EXE wieder einen brauchbaren  Source erstellen können. Deshalb gibt es auch wieder Tools, die den  Source vor dem Compi8lieren so verunstalten, dass man auch Hyroglyphen  verwenden kann.



Und diesen obfuscated code finde ich schlimmer als ein asm disassembly. Gibt es einen Obfuscator für ST?



> Wenn ein anderes Target bedient werden soll, nützt im Prinzip eine LIB  ohne Source nix. Man hat aber das gleiche Problem überall, nur, wer den  Source hat kann das System wechseln. Wer dann noch den Compiler selber  schreiben kann, also auch dessen Source hat, hat alle Karten.



Sowohl für ST Bibliotheken als auch C Bibliotheken muss ich dann für verschiedene Targets jeweils neu kompilieren. Einziger Nachteil, die schlechte Dokumentation zur C CoDeSys-Programmierung sowie die schwierige Umsetzung.


----------



## RobiHerb (27 Dezember 2011)

Einen sehr interessanten Link zum Thema, wie viel Performance bringt ein Compiler, wie wirkt sich DEBUG aus etc.

http://www.codeproject.com/KB/tips/Performances.aspx

Interessant wäre damit auch, läuft CoDeSys immer im Debug Mode? 

Ich kann doch immer mit der Entwicklungsumgebung mich einloggen?


----------



## Werner29 (9 Januar 2012)

jetzt mal der Reihe nach:

in CoDeSys sind Bibliotheken nichts anderes als Projekte mit einer anderen Dateiendung. In den Bibliotheken wird der Quellcode gespeichert.
Man muss die nicht für ein bestimmtes Target compilieren. Um diesen Quellcode zu schützen sollte man ein Passwort vergeben.
In der V3 gibt es die "compiled-libraries", in denen wird zwar nicht der Quellcode gespeichert, aber targetunabhängiger Zwischencode.

Debug Mode: in der V 2.3. gibt es in den Compile-Optionen einen Schalter für Debug-Code, nur wenn der eingeschaltet ist, kann man Breakpoints
setzen und Flowcontrol einschalten, dafür hat man etwas grösseren Code und etwas langsamere Ausführungszeiten.
In der Praxis wird der Schalter selten ausgeschalten.
In der V3 gibt es die Unterscheidung nicht, Breakpoints und Flowcontrol benötigen keinen zusätzlichen Code mehr.


----------



## Anaconda55 (9 Januar 2012)

Und was ist da jetzt der Unterschied zu C? Wird hier auch der Quellcode in der Bibliothek gespeichert?


----------



## Werner29 (10 Januar 2012)

Der wichtigste Unterschied ist, das Codesys kein C-Compiler ist. 
Man muss sich zuerst passende Schnittstellen in IEC schreiben und daraus C-Header generieren. Dann schreibt man sich in C die Implementation dazu und
dann braucht man einen C-Compiler für die entsprechende Plattform, der das übersetzt. Für einige Plattformen (386, PowerPC, ARM) können wir dann mit einigen
Einschränkungen COFF-obj-Dateien (das macht auch nicht mehr jeder C-Compiler) zu einem Projekt dazulinken.
Das passt natürlich nur für diese Plattform und für keine andere. Für eine andere Plattform brauchst du wieder einen anderen C-Compiler.
Also ich empfehle das überhaupt nicht.


----------

