Am 15.02.2017 um 07:52 schrieb Joerg Niggemeyer:
Moinmoin :-)
Ich habe es jetzt aber gerade geschafft, dank des
makefiles von Raik :-)
Ich habe bei Include: C:,OSLib:
Achtung der Doppelpunkt muss das stehen !
Und die Systemvariable muss gesetzt sein
So und unter den Options der Libraries vom CC war Dein Hinweis
richtig, dass dieser Pfad vom Linker mitbenutzt wird!
Hier habe ich jetzt explizit aus dem makefile von Rainer ergänzt:
C:o.stubs,OSLib:o.OSLib32
damit gehts jetzt ;-)
Könntest du mir das nochmals zusammenfassen und mir zukommen lassen,
eventuell auch und bitte mit Screenshots?
Eigentlich ist die Vorgehensweise ohne den makefile
komplett auf der WebSeite von Stephen Fryatt beschrieben mit
allen Screenshots.
Das hatte ich auch so 1:1 gemacht und seine erste Beispielapplikation
lief auch, nachdem ich jetzt Dein Beispiel zum Laufen gebracht
hatte, geht mit den Einstellungen von Fryatt simplecapp nicht mehr,
das ist doch nicht zu fassen... GRRRRRRR
Mit dem Kompilieren (d. h. Zusammenbauen des Programmes), das ist immer
so eine Sache. Kenntnisse von C alleine reichen hierfür nicht; man muss
die Werkzeuge kennen, mit denen man arbeitet. (Hatten wir auf der FH
allerdings auch nicht - wurde nicht einmal angesprochen.)
Üblicherweise hat man dafür eine IDE, die einem das abnimmt, nebst
vom Compilerhersteller dafür entsprechende Tooleinbindung.
Auf dem RiscOS scheint mir das so "comfortabel" wie aus den 80igern..
also gar keine IDE und das Erstellen des makefiles, sowie das Aufrufen
ist nicht gerade ein Selbstläufer.
Ich persönlich beschäftige mich jetzt so nebenher, wenn ich Zeit übrig
habe (derer nicht viel ist), viel mit Unix, weil C und auch das Makefile
ursprünglich von Unix herstammen. Unter Microsoft und dort speziell das
Microsoft-Visual-Studio (MSVS) kenne ich das Makefile überhaupt nicht
(oder es ist irgendwo versteckt und ich kam damit bisher nicht in
Berührung). Unter MSVS werden die Oberflächen in so einer Art
HTML-Syntax beschrieben - ganz anders als unter RISC OS. Aber mir ist
der letztere Weg lieber, weil ich da vieles in eine einzige Quelldatei
hacken kann und mir das ganze System (wieder einmal) viel transparenter
ist. Damit kann ich dann besser lernen.
Mir kommt es so vor, als ob hier nicht gerade auf dem Risc die
Transparenz (zunächst) gesteigert wird...
Ich glaube ich werde mich wohl mit diesen makefiles intensiver
beschäftigen muessen.....
Wie man GCC benutzt, dafür gibt es ein (eigenes) PDF-Dokument. Die
Möglichkeiten der zusätzlichen Parameter usw. sind derer allerdings
ziemlich viel: https://gcc.gnu.org/onlinedocs/
Den anderen Compiler von ROOL sollte ich mir wohl auch nochmal holen.
Zumn Vergleichen. Bisher hatte ich allerdings nicht wirkliches Interesse
daran, weil ich mit gcc eigentlich auch alles machen kann, was ich
möchte (einschließlich Assembler).
GCC bin ich nicht wirklicher Fan. Eigentlich mache ich nur mit
Embedded rum. Dort gibt es ja z.B. die Atmels.
Ich hatte also schoen ein Bsp. aus einem Buch nachgefrickelt
und bemerkte dann irgendwann, dass der AVR GCC Compiler meine
gewollten warte Loops einfach komplett "Herausoptimiert" hatte.
Nachdem der Compiler auf 0-Optimierung eingestellt wurde, lief
es dann so wie erwartet.
Will sagen je nach Compiler Version und Einstellungen usw. sind die
Ergebnisse(Verhalten) des PRGs unterschiedlich, was absolut null
tolerable ist.
Deswegen ist FReeTos usw. bei Medizintechnik, etc. nicht zulässig.
Die wohl beste Toolchain fuer CortexM ist wohl
Keil-aber für mich derzeit zu teuer.
Nach meinem Wissen ist der Norcroft CC dem noch sktuellen
ARM Compiler ähnlich, also dem Compiler, den man Online
über mbed.org aufrufen kann. Das erachte ich insofern als
ein gewisses Qualitätsmerkmal ;-)
Attachment:
signature.asc
Description: OpenPGP digital signature
