Die Lizenz der einzelnen stm32lxxx.h ist seit einiger Zeit BSD-3-Clause,
aber das modm Projekt ist da anderer Meinung. Letzter Absatz unter "Data
quality" in [2]
1
DO NOT UNDER ANY CIRCUMSTANCES PUBLISH THE RAW DATA EXTRACTED
2
FROM CUBEMX ANYWHERE! It is subject to ST's copyright and you are
3
not allowed to distribute it!
ABER: In einem sehr verwandten (gleicher Autor?) Blog-Artikel steht
etwas, was ich sehr vernünftig finde. Eigentlich kann man sich kaum
vorstellen, dass es anders geregelt ist. Allerletzter Satz in [1]
1
Formatting of all data excerpts is possibly copyrighted by
2
their respective owners and if so used here in fair use.
3
However, the data itself are facts which cannot be copyrighted.
Anscheinend veröffentlicht STM die Dateien sogar selbst. Das github
Projekt [3] könnte natürlich eine Fälschung sein, sieht aber sehr echt
aus und ist schon ziemlich lange online...
Unter diesen Umständen würde ich gerne ein stm*.h von [3] holen und von
"#define" zu "struct mit Bitfeldern" konvertieren. Außerdem mag ich
statt einer Riesendatei viele kleine adc.h bis wwdg.h. "Formatting of
all data" ist also total anders, aber (Tipp)-Fehler in den Daten kopiere
ich natürlich mit. Die Quelle wäre also noch nachweisbar.
Wahrscheinlich baut mein Konverter auch neue Fehler ein. Gehören die
dann mir oder sind die auch Copyright STM? Das einfachste wäre
natürlich, wenn das alles Copyright bauformb wird. Ich kann nämlich den
Lizenztext aus dem Original nicht so einfach kopieren, weil das nur die
Copyright-Zeile plus ein Link auf eine fremde HTML-Seite [4] ist.
Bonus-Frage: benutzt irgendwer so einen ähnlichen Konverter? Weil,
irgendwie ist ziemlicher Krampf (der Konverter, nicht das Ergebnis!).
[1] https://blog.salkinium.com/modm-devices/
[2] https://github.com/modm-io/modm-devices
[3] https://github.com/STMicroelectronics
]4] https://opensource.org/licenses/BSD-3-Clause
Interessante Geschichte.
Ich hab mir einen Konverter von SVD nach C++ gebaut, ähnlich svd2rust
(siehe github).
Leider sind die SVDs allgemein und speziell die von ST teilweise recht
fehlerhaft und etwas chaotisch organisiert.
Die CubeMX-Datenbanken würde ich auch nicht weiterverteilen, diese aber
direkt einzulesen und Code daraus zu generieren sollte nicht
problematisch sein, auch der daraus generierte Code sollte
lizenztechnisch unproblematisch sein, vergleichbar mit dem Code den
CubeMX generiert.
> Ich kann nämlich den> Lizenztext aus dem Original nicht so einfach kopieren, weil das nur die> Copyright-Zeile plus ein Link auf eine fremde HTML-Seite [4] ist.
Verstehe ich nicht. In die Doku gehört dann irgendwas wie "Teile
copyright " + copyright-zeile, und dann halt noch was die jeweilige
Lizenz fordert was man dazuschreiben muss.
rµ schrieb:> Leider sind die SVDs allgemein und speziell die von ST teilweise recht> fehlerhaft und etwas chaotisch organisiert.
Das hab' ich auch schon mehrfach gelesen, drum bin ich froh, dass ST die
Header jetzt auf github anbietet.
rµ schrieb:>> Ich kann nämlich den>> Lizenztext aus dem Original nicht so einfach kopieren, weil das nur die>> Copyright-Zeile plus ein Link auf eine fremde HTML-Seite [4] ist.>> Verstehe ich nicht. In die Doku gehört dann irgendwas wie "Teile> copyright " + copyright-zeile, und dann halt noch was die jeweilige> Lizenz fordert was man dazuschreiben muss.
"nicht so einfach" = es ist mir zu aufwendig, das zu automatisieren. Der
Konverter müsste die verlinkte Seite runter laden und aus dem HTML den
Lizenztext extrahieren. Wenn der Text ganz normal in der Datei selbst
oder in einem LICENSE.TXT stände, müsste ich nur kopieren. Bei Updates
muss ich ja auch vergleichen, ob es noch BSD ist.
Dabei fällt mir ein, ich kann die Datei selbst auch nur per Browser von
Hand bei github holen. Und das ist mega-umständlich, da kommt es auf den
Lizenztext auch nicht mehr an. Alles ein Krampf :(
Früher hat man alles aus dem Manual abgetippt und gut war's; vielleicht
sollte ich dabei bleiben.
Die Bit- und Registerdefinitionen per Hand aus dem RefMan abtippen habe
ich einmal gemacht "aus Spaß".
Das ist scon recht aufwendig bei den dicken Prozessoren, daher sind die
CMSIS Header schon recht nett.
Lustig ist wenn ST ein Bit im Fließtext beschreibt, es in den
Registerdefinitionen und den CMSIS Headern aber nicht auftauscht.
War beim L431 mit der UART CLK beim Sleep so.
Wozu der Aufwand?
Lade doch einfach das offizielle Device-Family-Pack¹ herunter,
extrahiere es und da ist alles drin. Und da ist auch die .svd-Datei drin
aus der man sich dann mit svd2conv die Header im bevorzugten Format
selber erzeugen lassen kann wenn man will.
----
¹ https://www.keil.com/dd2/pack/
Mw E. schrieb:> Lustig ist wenn ST ein Bit im Fließtext beschreibt, es in den> Registerdefinitionen und den CMSIS Headern aber nicht auftauscht.> War beim L431 mit der UART CLK beim Sleep so.
Davon gibt's mehrere. Besonders vermisse ich Definition für Bits. Bei
waitstates reicht meinetwegen die magic number, aber bei Sachen wie
Taktquellen sagt die ja nun garnichts. Na gut, egal wie, ohne Reference
Manual geht's sowieso nicht.
Bernd K. schrieb:> Lade doch einfach das offizielle Device-Family-Pack¹ herunter,
Dankeschön, aber da ist der/die/das Keil/ARM-EULA davor. Das sind
etwas mehr als 3 Klauseln. Wo wäre der Vorteil?
Bauform B. schrieb:> Wo wäre der Vorteil?
Da hast Du alles was Du brauchst und musst Dir die Header nicht selber
schreiben. Oder was immer Du da bezwecken willst. Die meisten Leute
brauchen halt einfach die Header um Firmware für den Controller
schreiben zu können, für solche ist das vorgesehen, dafür werden sie
veröffentlicht, keine Ahnung wozu Du sie brauchst, vielleicht schreibst
Du das mal?
Bernd K. schrieb:> Bauform B. schrieb:>> Wo waere der Vorteil?>> Da hast Du alles was Du brauchst und musst Dir die Header> nicht selber schreiben.
Dafuer brauche ich (pro Chip) genau die eine Datei mit den
Register-Definitionen, z.B. stm32l451xx.h. Die gibt es bei github
anscheinend original von ST. Keil kann nur eine Kopie oder etwas ganz
anderes anbieten (z.B. SVD, aber die braucht doch kaum jemand).
Das waere ein kleiner Nachteil.
Aber zusaetzlich muesste ich die Keil-EULA akzeptieren und vor allem
verstehen. Ich habe aber schon Schwierigkeiten mit den 3 Saetzen BSD.
Also: mein eigentliches Problem wird bei Keil nur schlimmer und die
gelieferten Daten koennen nicht besser werden.
> Oder was immer Du da bezwecken willst. Die meisten Leute> brauchen halt einfach die Header um Firmware fuer den Controller> schreiben zu koennen
Genau dafuer brauche ich die auch. Ich mag aber keine #define und
schon garnicht 1++MB am Stueck, die praktisch in jede kleine Quelle
eingebunden werden muessen. Also formatiere ich sie um. Also muss
ich den Lizenztext kopieren. Und das geht praktisch nicht, weil das
nur HTML von irgendeinem fremden Server ist.
Es waere halt nett, wenn der verlinkte Blog-Beitrag Recht haette
mit "fuer Fakten gibt's kein Copyright". Fuer mehr fehlt so einer
Header-Datei doch sowieso jegliche Schoepfungshoehe.
(gepostet mittels w3m und nano)
Bauform B. schrieb:> afuer brauche ich (pro Chip) genau die eine Datei mit den> Register-Definitionen, z.B. stm32l451xx.h.
Nein, Du brauchst die svd-datei und die wird vom Hersteller
veröffentlicht, bei Keil kann man sie alle runterladen. Damit kannst Du
die Header mittels svdconv erzeugen in dem Format in dem Du sie gerne
hättest (structs, flach, mit enums, etc).
svd ist das Ausgangsformat, alle .h die Du irgendwo siehst wurden davon
erzeugt.
> Keil kann nur eine Kopie oder etwas ganz anderes anbieten
Keil bietet das DFP genau so zum Download an wie es von STM angeliefert
wird, evtl kann man das DFP auch bei STM direkt herunterladen aber bei
Keil ist alles auf einer Seite, das ist einfacher.
Lad Dir doch einfach mal eins herunter und entzippe es (Dateiendung zu
zip ändern) und sieh selbst.
Bernd K. schrieb:> Nein, Du brauchst die svd-datei und die wird vom Hersteller> veröffentlicht, bei Keil kann man sie alle runterladen. Damit kannst Du> die Header mittels svdconv erzeugen in dem Format in dem Du sie gerne> hättest (structs, flach, mit enums, etc).
Naja, ob ich als Quelle jetzt die svd oder h nehme, ist ja erstmal egal.
Das xml aus dem svd sollte leichter zu parsen sein, aber dafür steht im
.h ein wenig mehr drin (es gilt für genau einen Chip, .svd anscheinend
für mehrere(?!)).
> Lad Dir doch einfach mal eins herunter und entzippe es> (Dateiendung zu zip ändern) und sieh selbst.
Gesagt, getan, und was sehe ich?
das svd ist neuer als das daraus erzeugte .h? Das .h ist auch älter und
hat mehr Fehler als das von github (wenn ich mal das Reference Manual
als Referenz nehme).
ABER es enthält noch den kompletten Lizenztext, keinen Link. Also, der
Trick ist gut, du hast Recht, das Keil-Paket löst mein ursprüngliches
Problem :)
Allerdings finde ich zu den SVD garkeine Lizenz außer der EULA für das
komplette Paket und da ist ja alles mögliche drin, auch Software, die
pro "seat" bezahlt wird. Entsprechend restriktiv ist sie, also gibt's
kein SVD.
Bauform B. schrieb:> das svd ist neuer als das daraus erzeugte .h? Das .h ist auch älter und> hat mehr Fehler als das von github
Generier dir doch zum Spaß mal ein frisches .h aus dem .svd
Die Lizenz des .svd ist egal da Du es ja nicht als solches
weiterverbreitest und es wird unter der selben Lizenz stehen wie die
Dokumentation denn nichts anderes ist es: maschinenlesbare
Registerdokumentation.
Bauform B. schrieb:> das Keil-Paket
Es ist kein "Keil-Paket", der Urheber ist STM. Keil sammelt nur die
Dinger von allen Herstellern und verbreitet sie weiter. Ich bin mir
sicher irgendwo auf der STM-Webseite kann man das aktuelle DFP ebenfalls
direkt runterladen, vielleicht sogar ne aktuellere Version als bei Keil.
Bauform B. schrieb:> z.B. SVD, aber die braucht doch kaum jemand).> Das waere ein kleiner Nachteil
Ein Debugger nimmt das gerne um zu wissen wie die Register(+Bits) heißen
und wo sie liegen ;)
Den Rest hat Bernd schon auf den Punkt gebracht.
Also gut, "SVD, aber die braucht doch kaum jemand" nehme ich zurück.
Bernd K. schrieb:> Die Lizenz des .svd ist egal da Du es ja nicht als solches> weiterverbreitest und es wird unter der selben Lizenz stehen wie die> Dokumentation denn nichts anderes ist es: maschinenlesbare> Registerdokumentation.
Das würde mir gefallen, aber wo ist dann der Unterschied zu den .h
Dateien? Außer, dass die nicht so leicht lesbar sind? Ein Compiler darf
die .h lesen und die Information nutzen um etwas neues zu produzieren.
Nichts anderes macht doch ein Konverter, egal, ob mit .svd oder .h als
Quelle?
Wenn der Konverter dann structs und enums ausgibt, ist es erlaubt, aber
wenn es anders formatierte #define sind, ist es eine Raubkopie?
Es kommt noch schlimmer: wenn ich alles aus dem Manual abtippe, sehen
die Dateien (natürlich) ganz genau so aus, wie sie aus meinem Konverter
kommen. Selbst Fehler muss ich ja in beiden Fällen korrigieren, wenn's
funktionieren soll.
Gibt es einen konkreten Fall aus der Vergangenheit in dem STM oder ein
anderer Hersteller je dagegen vorgegangen ist daß jemand auf Github ein
Projekt für ihre MCU hat und deren Originalheader mit Orginalcopyright
(oder svd-generierte) dort mit eincheckt? Liegt das überhaupt in deren
Interesse dagegen vorzugehen?
Vielleicht haben sie auch einfach nicht nachgedacht als sie ihre
0815-Standard-Copyrights überall reingeklatscht haben. Was ist wenn sich
herausstellt daß man "legal" überhaupt keinen Code dafür schreiben kann
wenn man es mit der buchstabengetreuen Auslegung übertreibt? Das war
bestimmt nicht beabsichtigt.
Bernd K. schrieb:> Gibt es einen konkreten Fall aus der Vergangenheit in dem STM oder ein> anderer Hersteller je dagegen vorgegangen ist daß jemand auf Github ein> Projekt für ihre MCU hat und deren Originalheader mit Orginalcopyright> (oder svd-generierte) dort mit eincheckt? Liegt das überhaupt in deren> Interesse dagegen vorzugehen?
Naja, ein so konkretes Beispiel kenne ich nicht, aber ARM hat durchaus
daran gedacht; das sind keine Anfänger ;)
1
END USER LICENCE AGREEMENT FOR MDK-ARM
2
10.General
3
(...)
4
The failure by ARM to enforce any of the provisions of this
5
Licence, unless waived in writing, shall not constitute a waiver
6
of ARM's rights to enforce such provision or any other provision
As an example, NXP's MCUxpresso uses blowfish to encrypt their
2
internal definitions which makes no sense to me seeing as the
3
information is all in the reference manual.. I could do some code
4
injection into their IDE, its just java after all, to dump the
5
files from memory when they are decrypted by the IDE, but that
6
would be incredibly tedious and still result in files I couldn't
7
redistribute or use as the basis for derivative works anyway.
Unabhängig davon bleibe ich bei den *,h von
github.com/STMicroelectronics. Die haben eine übersichtliche Lizenz
(selbst wenn die SLA0048 gelten sollte) und es sind die aktuellsten.
Keil ist bald um 1 Jahr hinten dran und in der neuesten Version 1.14
sind immer noch Fehler korrigiert worden.
Zum Ausgleich sind die SVDs von www.st.com (immer noch) hoffnungslos
veraltet und das scheint ihnen ziemlich egal zu sein. Schade, es war
eine gute Idee.
https://community.st.com/s/question/0D50X0000BADqvRSQT/what-is-the-best-place-to-obtain-current-svd-files-for-stm32-devices
1
...all I can say is things are completely out of hand:
2
the Version 1.4 SVD still has wrong addresses for ADC12_Common
3
(and possible other peripherals) but the header files have the
4
correct address. Further, the timer peripherals have all been
5
renamed in the SVD ('TIMERx' instead of 'TIMx') but not in the
6
headers. It's an absolute shambles.
Eigentlich könnten die SVD doch automatisch aus den
VHDL-oder-was-auch-immer-Daten der Chips erzeugt werden?
Bauform B. schrieb:> the Version 1.4 SVD still has wrong addresses for ADC12_Common> (and possible other peripherals) but the header files have the> correct address.
Die aktuelle svd existiert wahrscheinlich schon irgendwo bei denen, die
haben die Header nicht von Hand geschrieben, sie haben nur vergessen die
auch zu veröffentlichen, wahrscheinlich weiß bei denen die rechte Hand
nicht was die linke tut und keiner fühlt sich veranlasst tätig zu werden
solange sein jeweiliger Boss es ihm nicht explizit aufgetragen hat.
Thread beobachten
Seitenaufteilung abschalten