Hallo, momentan bin ich dabei mich in die ARM-Programmierung einzuarbeiten. Ich habe mir als Einfuehrung auch schon das ARM-gcc-tutorial hier aus dem Forum durchgelesen. Dort wird empfohlen nur die von "uns" getesteten Startups und Linkerscripte zu verwenden um unschoene Effekte zu vermeiden. Nu ist die Frage wo finde ich diese von "uns" getesteten Scripte? Im speziellen Suche ich die fuer den LPC2138. Ja man koennte jetzt zu Keil klauen gehen, aber wie ists denn wenn man seine Projekte als open source rausgeben sollte? Das ist doch mit Sicherheit problematisch. Gibts vielleicht offen verwendbare vom Hersteller? cu Tarzanwiejane
Tja ist schon witzig, es ist OK die Keil Startups und Beispiele in ein kommerzielles Projekt einzubauen aber es ist (natuerlich) nicht erlaubt einen Code, der von jemand mit Copyright versehen ist, ploetzlich als Open Source zu deklarieren, so wie das andesrum auch nicht geht. Da prallen zwei Welten aufeinander, diejenigen, die irgendwann in einem Lebensabschnitt Code erzeugen der fuer die ganze Welt bestimmt sein soll und diejenigen, die ueber sehr viele Jahre ihren Lebensunterhalt mit Software verdienen muessen. Ich weiss, dass mindestens bis 2007 bei NXP keine eigenen Start Ups generiert wurden, die jetzt als Open Source zur Verfuegung gestellt werden koennten. Vielleicht ist das bei Atmel und ST ander, weiss ich nicht. Robert
Das arm-gcc Tutorial im Wiki ist etwas in den Kinderschuhen stecken geblieben. Es gibt halt bis auf die Verwendung der eigentlichen Toolchain nicht so sehr viele Gemeinsamkeiten zwischen verschiedenen Controllern sobald es um die Verwendung integrierter Funktionen geht. Tutorial würde sehr ausführlich und wahrscheinlich hat niemand die Zeit dafür. Bin kein Experte für Lizenzfragen, dennoch ein paar Anmerkungen. Hoffe, alle Hunde bleiben in Nachtruhe: Habe mir schon Beispielcodes von einigen Herstellern von Controllern und Compilern angesehen (nicht nur für solche mit ARM-core). In Sachen Lizenz ein ziemliches Wirrwar. Anfangs habe ich auch oft - wie viele andere - für Experimente mit der GNU-Toolchain für ARM auf Beispiele von Keil für die GNU-Toolchain als Vorlage zurückgegriffen. Es gab halt wenig anderes. Aber irgendwann tauchten zusätzliche Kommentarzeile in Keil-Beispielcode auf: "This software may only be used under the terms of a valid, current, end user licence from KEIL for a compatible version of KEIL software development tools. Nothing else gives you the right to use this software." Danach einen Bogen um diese Codes gemacht, was ich hiermit auch dem OP empfehle. Hat man nun als jemand der gelegentlich mit der Eval-Version (nicht kommerziell) spielt das Recht den Code zu verwenden (to use)? Wenn nicht, warum liegt dann überhaupt Beispielcode bei? So man denn auch als Eval-User eine "Evaluierungslizenz hat", dann könnte man den Code auch verwenden. O.k. rhetorische Fragen, jemand von Keil/ARM wird sich kaum in dieses Forum verirren. Sicher hat sich bei Keil jemand Arbeit gemacht aber die Arbeit beim Startup-Code bestand wohl vermutlich, zumindest zu ADS-Zeiten, meist darin, vorhandenen Startup-Beispielcode von Controllerherstellern zu nehmen und um Textmarken für den uVision-Wizard zu erweitern. So unähnlich sind die Startup-Codes in MDK-ARM eval und EWARM-KS nicht, abgesehen von den Toolchain-spezifischen Anpassungen. Es gibt ja einen technisch erforderlichen kl. gemeinsamen Nenner aus ein paar Zeilen Assembler-Code. Mit startup-code verdient - hoffentlich - niemand seinen Lebensunterhalt, mit der Bereitstellung einer anwenderfreundlichen IDE und eines guten Compilers hoffentlich möglichst viele. Angepasster Startup-code ist dann Mittel zum Zweck. Dennoch: zumindest der Text in den Codes von Keil lassen wenig/keinen Spielraum, also besser kein "copy-paste". Jetzt, da Keil zu ARM gehört, ist es auch nicht wirklich gut nachvollziehbar, warum man derartige Restriktionen auferlegt. - Anwender die einen Cross-Compiler unter Linux betreiben werden ausgeschlossen. MDK-ARM ist "MS-only" - Anwender die sich MDK-ARM nicht leisten können werden ausgeschlossen - Anwender die eine andere Toolchain nutzen müssen werden ausgeschlossen Kann alles nicht wirklich im Sinne von ARM als Prozessorlizenzverkäufer sein, sicher aber im Sinne von ARM als Compilerverkäufer. Wird wohl der Grund sein. Wie auch immer, zurück zur eigentlichen Frage: die Kommentare im Code sind eindeutig und man sieht besser davon ab, Startup-Code von Keil zu portieren, kann sich ja dennoch davon inspirieren lassen. Man muss ohnehin für GNU einiges mehr beim Startup erledigen, was bei Realview durch Libraryfunktionen realisiert wird (z.B. data-copy, bss init) und einen "open-source" Wizard ähnlich dem in uVision gibt es meines Wissens ohnehin nicht. Bei nxp.com gibt es ein Code-Bundle für LPC213x/4x mit Startupcode für andere Assembler. > Ich weiss, dass mindestens bis 2007 bei NXP keine eigenen Start Ups > generiert wurden, die jetzt als Open Source zur Verfuegung gestellt > werden koennten. Hmm, wirklich? Im code-bundle für LPC213x/214x (heruntergeladen Januar 2007 von philips.com (oder war es schon nxp.com?) ist in common/src ein Startup-Code enthalten. Ist zwar für RealView bzw. den alten Keil-Assembler, aber leicht auf GNU-as zu portieren. Damit ist ein Teil der ursprünglichen Frage hoffentlich beantwortet. Dennoch wieder Lizenz-Wirrwar: Zu Beginn der Datei findet man folgendes: "Copyright(C) 2006, Philips Semiconductor, All rights reserved". In der readme-Datei: "Software that is described herein is for illustrative purposes only which provides customers with programming information regarding the products." gefolgt von einer Reihe Haftungsausschlüssen. Bleibt offen, was man jetzt mit "all rights reserverd" anfangen soll. Ich habe es so verstanden, dass ich den Code nehmen und für GNU-tools anpassen/erweitern kann. Damit also den Code als "programming information for the product" genutzt und - hoffentlich - der Lizenz entsprochen. > Vielleicht ist das bei Atmel und ST ander, weiss ich nicht. Wüsste auf Anhieb keinen Hersteller, der in seinen Beispielen keinen Startup-Code für mindestens eine Toolchain bereitstellt. Nicht unüblich, aber leider auch nicht immer, unter einer BSD-(-ähnlichen) Lizenz, also ganz grob: lass das Copyright der ursprünglichen Autoren drin; wir geben keine Garantie, dass der Code so o.k. ist; ansonsten mach damit was zu willst. Gelegentlich findet man noch die Einschränkung, dass der Code nur mit Controllern des Herstellers genutzt werden darf (z.B. bei Luminary, alten Sharp-Beispielen). Verständlich und akzeptabel aber zumindest bei low-level Treibern sinnlos, da man diese ohnehin nicht auf anderen Controllern verwenden kann. Zum Linker-Skript: zur Einstellung des Linkers braut ohnehin jeder Toolchain-Hersteller sein eigenes Süppchen. Scatter-File für Realview oder Scripte für den IAR-Linker helfen also für GNU nicht wirklich weiter. Allenfalls um darin Speicheraddressen abzulesen aber die findet man im Datenblatt schneller. Die Linker-Skripte für ARM-Controller und GNU-toolchain sind aber sehr ähnlich. Für den Anfang genügt es, sich ein freies Linker-Skript als Vorlage zu nehmen und die Speicheraddressen und -größen an den verwendeten Controller anzupassen. (Die einfachen Linker-Skripte für GNU im MDK-ARM Packet sind lustigerweise bis auf Copyright-Mitteilung und geänderte Speicheraddressen identisch mit "uralten" Skripten, die man noch im Internet findet.) Für den Anfang reicht vielleicht sogar das default-linker-script, man muss aber dem Linker dann ein paar Kommandozeilenoptionen mit Flash/RAM-Speicheraddressen mitgeben. Oh je, schon wieder so viel getippt. Zum Schluss noch ein "möglicherweise hilfreich" für den OP: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/lpc2k_bundle_port/index.html
Hi, das Problem mit dem Startup-Code und Linkerscripten ist bekannt. Und nicht nur bei ARM-Prozessoren vorhanden. Und im Prinzip auch einfach zu lösen: Reqisiten sind Datenblatt des Prozessors, Beschreibung Linker-Script-Sprache des Compilers-Toolkits resp. des Linkers. Eventuell ein "anderes" Linkerscript bzw. Startupcode als Blaupause daneben legen (nicht im Sinne von Copy-And-Paste sondern im Sinne von verstehen, was da gemacht wird). Ein Experimentierboard samt Programmer bzw. Debugger etc. ist hilfreich. Und dann, in die Hände gespuckt und tippen ... Klar, ich weiß, das klingt so einfach. Ich weiß aber auch, das vermutlich mehr als 90% der Programmierer dies nicht können. Linker-Scripte schreiben bzw. modifizieren ist schon etwas leicht elitäres, Literatur selten bis Ausnahme. Und auch das Verständnis, was der Startupcode machen soll/muß ist nicht wirklich verbreitet (ich erinnere mich da an bereits legendäre Diskussionen: "... der RAM ist am Anfang IMMER zu Null initialisiert, das macht doch schon der Prozessor ...". Nun ja, was der Mensch glaubt, läßt er nicht so schnell los ... ;-) Leider hat mich bisher noch niemand genötigt, mit ARM und arm-gcc zu arbeiten ... ;-), sonst könnte ich da etwas mehr zu einbringen. Aber es gibt ja auch andere "Verwandte", wie PPC, Tricore, kleine AVR, PIC und auch sehr "interessante" Compiler-Hersteller, wie Tasking etc. Schönen Tag noch, Thomas
Wobei ich finde, dass der Startup-Code nicht soo kompliziert ist. Da finde ich es schwieriger die Makefile zu verstehen. Ich saß zwar auch eine Weile dran, nur so lange man eine Vorlage, z.B. die aus dem ARM-Turorial von J. Lynch kann man diese anpassen. Ausser dem Stack und den Vektoren für IRQ etc. wird doch gar nichts im Code gemacht oder? Mit dem Makefile war es bei mir schon schwieriger. Ich hatte von einem Kommilitonen funktionierenden Startup-Code und Makefile für einen ADUC7000. Beides konnte ich so unter Eclipse/Openocd nicht mehr einsetzten. Ich war froh, ein Tutorial zum entlanghangeln haben, einfach war es aber trotzdem nicht, da ich mich plötzlich mit dem Compiler auseinander setzen musste.
@ Martin Mit startup-code verdient - hoffentlich - niemand seinen > Lebensunterhalt, mit der Bereitstellung einer anwenderfreundlichen IDE > und eines guten Compilers hoffentlich möglichst viele. Angepasster > Startup-code ist dann Mittel zum Zweck. Kein Einspruch, hast Du vollkommen Recht > kann sich ja dennoch davon inspirieren lassen. Da hast Du einfach die besseren Worte gewaehlt. Kein Compilerhersteller wird jemand an die Wolle gehen fuer "Aehnlichkeiten" im Startup. Nur eben nicht ohne irgendwelche Aenderungen kupfern. > Bei nxp.com gibt es ein Code-Bundle für LPC213x/4x mit Startupcode für > andere Assembler. Das ist die o.g. Prozedur in Anwendung. > Wüsste auf Anhieb keinen Hersteller, der in seinen Beispielen keinen > Startup-Code für mindestens eine Toolchain bereitstellt. Vielleicht muesste der Satz eher so lauten: "Wüsste auf Anhieb keinen Hersteller, der in seinen Beispielen keinen Startup-Code von mindestens einer existierenden Toolchain benuetzt."? Aus Erfahrung sehen die "Startups" in den Entwicklungsabteilungen der Hersteller so aus, dass eine Weitergabe an moegliche Kunden eher nicht so gut waere. Wenig Struktur, viel Kraut und Rueben. Wenn ein Chip Hersteller auch ueberall Copyright rein macht, dann hat das viel mit der rechtlichen Lage in den USA zu tun. Jeder John Smith kann eine Klage einreichen, dass der Code des Herstellers soundso dafuer verantwortlich ist, dass sein Waschmaschine das ganze Haus ueberschwemmt hat (obwohle er vergessen hatte den Schlauch richtig dran zu machen). Ist vielleicht etwas uebertrieben aber nicht sehr. An alle, die Startups und Linker Scripts erstellen wollen, lasst Euch sehr viel inspirieren und macht einige wichtige Aenderungen, z.B. in den Kommentaren, in der Reihenfolge der Befehle, bestimmt braucht jeder noch ein paar spezielle Initialisierungen dafuer andere eher nicht..... Use your fantasy ;-) Robert
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.