Hat sich schon mal jemand darüber Gedanken gemacht? http://gekogeek.com/hacks/stm32-demo-code-carries-extra-hidden-copyrights/ Ich muss gestehen ich habe das linkfile einfach so benutzt. Wie kann ich das "umstricken" damit es meins ist wenn ich doch für die ST libraries die Namen und Bereiche aus dem .ld File brauche???
> Hat sich schon mal jemand darüber Gedanken gemacht? Das ist uralt. Ich wundere mich schon sehr lange, dass immer wieder Leute naiv diese Dateien verteilen. Was man nicht sieht, ob diese Linker-Skripte in kommerziellen Produkten verwendet werden. Lizenzen (und Verträge) lesen und verstehen gehört zum Geschäft. > Ich muss gestehen ich habe das linkfile einfach so benutzt. "Einfach so" geht nicht mehr. Ich kenne kaum noch Verträge, in denen die "Rechte Dritter" nicht sehr detailliert behandelt werden. > Wie kann ich das "umstricken" damit es meins ist wenn ich doch für die > ST libraries die Namen und Bereiche aus dem .ld File brauche??? Scherzkeks. "Umstricken" führt nicht dazu, dass es "Deins" wird. Entweder selber schreiben, oder z. B. das von http://code.google.com/p/openstm32/ verwenden. Aber auch da gilt: Lizenz lesen (GPL3). Wegen der Verträge hab ich inzwischen die Nase voll und schreibe alles selber: Startup, Linker-Skripte, selbst die newlib ist komplett rausgeflogen. Im Desktop-Bereich werden auch keine Fremdbibliotheken mehr verwendet. Alles andere ist inzwischen kommerziell ein unkalkulierbares Risiko. Und bis man die Feinheiten der Verträge verstanden hat, hat man das "linker script" schon lange geschrieben. Das Schöne am ARM ist doch, dass man den Startup auch in C schreiben kann. Und wenn man ein "linker script" für den ARM hat, passt das bis auf die "memory regions" für die anderen auch.
Hallo Roland, vielen Dank für die ausführliche Antwort. Was könnte der Grund sein das ST kein eigenes linkscript mit passender startup anbietet wenn doch sonst alles vorhanden ist?
Hm, oder vielleicht Prozente von den Herstellern der -teuren- kommerziellen IDEs?
pegel schrieb: > Hallo Roland, > > vielen Dank für die ausführliche Antwort. > Was könnte der Grund sein das ST kein eigenes linkscript mit passender > startup anbietet wenn doch sonst alles vorhanden ist? Wie mir mal jemand von ST sehr deutlich sagte, hat man bei ST absolut keinen Bock auf Software, schon gar nicht auf freie Software. Freie Software hasst man regelrecht. Unprofessionell, Kinderkram ... Am liebsten würde man nur Hardware machen und die ohne alles über den Zaun zum Kunden werfen. Einen Mikrocontroller kann man heutzutage allerdings nicht mehr ohne Software verkaufen. Daher hat ST Deals mit Firmen, deren Produkte ST - vermutlich gegen Bezahlung - empfiehlt. So muss sich ST nicht so oft die Finger an Software schmutzig machen. Nun habe aber diverse der empfohlenen Partner ihre Compiler-Produkte wiederum auf GCC und binutils aufgebaut. So hat ST durch die Hintertür doch die dort verhasste freie Software am Hals. Die Partner wiederum versuchen gerne die GPL zu umgehen, um ihre Produkte besser vermarkten zu können. So kommt es, dass Atollic dem GPL-lizenzierten Linker mal eben ein proprietäres Linkerskript unterschiebt. Aber das interessiert ST nicht - Hauptsache man muss nicht selber Software anfassen und formal gibt es über die Partner ja alles - auf Windows. Alles andere als Windows ist für ST auch unprofessionell. Sinnvoll ist das was ST macht, bzw. nicht macht zwar nicht, aber die wollen das so. Ändern wird sich nichts, über ST kreisen schon die Finanzgeier http://www.bloomberg.com/news/2012-10-12/stmicro-sees-third-quarter-sales-trailing-estimates.html
> Wie mir mal jemand von ST sehr deutlich sagte, hat man bei ST absolut > keinen Bock auf Software, schon gar nicht auf freie Software. Freie > Software hasst man regelrecht. Das ist inzwischen auch bei vielen anderen auch so. > Unprofessionell, Kinderkram Die Schwierigkeit besteht für diese Firmen tatsächlich darin, dass sie es rechtlich nicht "fassen" können. > Am liebsten würde man nur Hardware machen und die ohne alles über den Zaun > zum Kunden werfen. Wenn sie da mal nur konsequent wären ... und ihre eigene Library endlich einstampfen würden :-) > Daher hat ST Deals mit Firmen, deren Produkte ST - > vermutlich gegen Bezahlung - empfiehlt. Das dürfte vermutlich auch eine Rolle spielen. Der guten Ordnung halber: Es gibt gut gepflegte Linker-Skripte/Startups bei AVR und MSP430. Bei den ARMs ist es lieblos (STM, NXP, TI Stellaris). Kurios ist es bei Renesas RX (Linker-Script ist von Red hat), und so richtig verwirrend ist es für PIC32. Zitat aus dem Stellaris-Linker-Script
1 | You may not combine this software with "viral" open-source |
2 | * software in order to form a larger program. |
Ja, so Zeugs können sie formulieren. Aber bei C++ - Support im Linker-Skript hapert es. Aber wie schon sehr treffend formuliert wurde ... Ist so schrieb: > Nun habe aber diverse der empfohlenen Partner ihre Compiler-Produkte > wiederum auf GCC und binutils aufgebaut. So hat ST durch die Hintertür > doch die dort verhasste freie Software am Hals. ... haben sie einfach keine Chance mehr, ohne den GCC auszukommen. Am deutlichsten sieht man das im Fall von PIC32.
Danke euch für die Aufklärung. Dann ist es ja so, dass wenn ich zum Beispiel ein Projekt ohne das ST Verzeichnis weitergebe, bei dem der Empfänger selbst die Libs von ST laden muss die von meinem Makefile benutzt aber nicht geändert werden und wenn er selbst mit gcc compiliert und linkt ich auch nicht schuldig bin. Bürokratie find ich gut! Musste meinen eigenen Satz auch zweimal lesen bevor ich ihn verstanden habe ;-) Schade, die STM32 find ich eigentlich echt fantastisch.
> Dann ist es ja so, dass wenn ich zum Beispiel ein Projekt ohne das ST > Verzeichnis weitergebe, bei dem der Empfänger selbst die Libs von ST > laden muss die von meinem Makefile benutzt aber nicht geändert werden > und wenn er selbst mit gcc compiliert und linkt ich auch nicht schuldig > bin. Ich meine, dass es so OK ist (bin aber kein Jurist), weil der Empfänger selbständig herunterladen (und prüfen) muss. Ein ähnlichen Fall hatte ich kürzlich. Aus vertraglichen Gründen (die der Kunde selbst so will) muss er sich nun die Libraries selbst besorgen und integrieren. Der Schuss ging nach hinten los. Man sieht es auch immer wieder, dass vom Makefile die Libraries automatisch heruntergeladen werden, so dass der Empfänger nichts "bemerkt". Das könnte aber schon eine Grauzone sein, insbesondere dann, wenn der Empfänger nicht darauf hingewiesen wird. > Musste meinen eigenen Satz auch zweimal lesen > bevor ich ihn verstanden habe ;-) Nach der Lektüre von 10 Verträgen geht das dann richtig flüssig :-) > Schade, die STM32 find ich eigentlich echt fantastisch. Das sollte die Freude nicht trüben :-) Das ist nicht STM spezifisch. Wie schon geschrieben, wirklich freie Linker-Skripte und Startups sind eher die Ausnahme als die Regel. Bei den ARMs kann man sich diese auch selbst erstellen. Bei Renesas RX und PIC32 ist das wesentlich schwieriger (da Assembler Voraussetzung ist).
Recht brauchbares lizenzloses Linker-Script und Startup-Fragment als Basis für Cortex Mx-Entwicklungen (für ARM7TDMI fehlt ein wenig) in diesem Text: https://launchpadlibrarian.net/109296007/readme.txt. Startup-Codes in CMSIS-Packeten zu Controllern scheint inzwischen, bis auf die üblichen Garantieausschlüsse, frei zu sein. Ansonsten ist es angebracht, ST Mircoelectronics einen Hinweis zu senden, denn deren Softwarepacket dürfte die Hauptquelle sein, aus der das Skript von anderen übernehmen und weitergegeben wird.
Roland H. schrieb: > Kurios ist es bei Renesas RX (Linker-Script ist von Red > hat), Der Grund dafür dürfte DJ Delorie heißen. Jener Programmierer, der vor ewigen Zeiten den GCC und diverse Tools nach MS DOS portiert hat. Der ist heute ein Red-Hat-Mitarbeiter und mag Renesas MCUs. > und so richtig verwirrend ist es für PIC32. Microchip ärgert sich je ebenfalls furchtbar, dass es bei GCCs für PIC nicht so einfach ist den Compiler zu verkrüppeln. Da baut man jahrelang eigene Compiler und verkrüppelt sie, damit der Kunde die Vollversion kauft, da legt man sich vor einiger Zeit zusätzlich eine renommierte Compilerschmiede zu, und dann macht man doch den GCC-basierenden C32. Und muss mit dem HI-TECH XC32 Compiler nachlegen und versuchen die Kunden wieder ins proprietäre Lager zu ziehen. > Zitat aus dem Stellaris-Linker-Script >
1 | > You may not combine this software with "viral" open-source |
2 | > * software in order to form a larger program. |
3 | > |
> > Ja, so Zeugs können sie formulieren. Aber bei C++ - Support im > Linker-Skript hapert es. Anwälte werden sich sicher stundenlang darüber auslassen können, was in dem Zusammenhang "combine" heißt. Soweit ich weiß, ist der unter der GPL stehende ld der einzige Linker der die Skripts versteht. Wenn man "combine" so streng auslegt, dass die Ausführung des Skripts durch ld schon ein Kombinieren ist, dann dürfte man das Skript gar nicht verwenden. > ... haben sie einfach keine Chance mehr, ohne den GCC auszukommen. Am > deutlichsten sieht man das im Fall von PIC32. Bei den Herstellern von großen ARM-CPUs ist es noch schlimmer. Spätestens seit dem Siegeszug von Android-Smartphones, die fast alle auf ARMs laufen, sind viele Hersteller auf Gedeih und Verderben mit freier Software verheiratet. Trotzdem tun die so, als wolle man ihnen die Unschuld rauben, wenn man nach nicht-Windows Tools und freier Software fragt.
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.