mikrocontroller.net

Forum: Compiler & IDEs Lizenz der STM32 Header Files


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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]
DO NOT UNDER ANY CIRCUMSTANCES PUBLISH THE RAW DATA EXTRACTED
FROM CUBEMX ANYWHERE! It is subject to ST's copyright and you are
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]
Formatting of all data excerpts is possibly copyrighted by
their respective owners and if so used here in fair use.
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

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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/

: Bearbeitet durch User
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Meinst du die ganzen MUXe im RCC?
Genau da hab ich meine eigenen enums getippt ;)

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Genau die oder die DMA-Kanäle. Und, besonders übel, man muss sich auch 
noch Namen dafür ausdenken ;)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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?
$ unzip -l Keil.STM32L4xx_DFP.2.2.0.pack | egrep 'stm32l451xx.h|STM32L4x1.svd'
 1792188 2018-12-12 15:03 CMSIS/SVD/STM32L4x1.svd
 1171909 2018-07-31 10:00 Drivers/CMSIS/Device/ST/STM32L4xx/Include/stm32l451xx.h
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Das Eclipse GNU-MCU Plugin lädt die DFP-dateien herunter, entpackt sie 
und verwendet sie für verschiedene Zwecke, unter anderem zum 
Register-Debuggen.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)
END USER LICENCE AGREEMENT FOR MDK-ARM
10.General
(...)
The failure by ARM to enforce any of the provisions of this
Licence, unless waived in writing, shall not constitute a waiver
of ARM's rights to enforce such provision or any other provision
of this Licence in the future.
NXP versucht direkt zu verhindern, dass man solche Dateien benutzt. 
Jeder soll gefälligst eigenhändig das Manual abtippen:
https://www.eevblog.com/forum/microcontrollers/cortex-m-svd-files-(nvic-etc)/msg2089162/?PHPSESSID=bngojeitlak3uh4h9mg806hea7#msg2089162
As an example, NXP's MCUxpresso uses blowfish to encrypt their
internal definitions which makes no sense to me seeing as the
information is all in the reference manual.. I could do some code
injection into their IDE, its just java after all, to dump the
files from memory when they are decrypted by the IDE, but that
would be incredibly tedious and still result in files I couldn't
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
...all I can say is things are completely out of hand:
the Version 1.4 SVD still has wrong addresses for ADC12_Common
(and possible other peripherals) but the header files have the
correct address. Further, the timer peripherals have all been
renamed in the SVD ('TIMERx' instead of 'TIMx') but not in the
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?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.