Beckhoff/CoDeSys Lib in C

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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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!?
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zurück
Oben