Es gibt etwas neues aus dem Hause ST. Den STM32CubeProgrammer. Ersetzt das ST Link Utility und läuft prima unter Linux. ST-Link Firmware Update hat auch funktioniert.
Angehängte Dateien:
-
CubeProgrammer.png
180 KB
Schöne Sache, heute gleich mal ausprobieren. Achja - damit man nicht ewig suchen muss, so wie ich: http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stm32cubeprog.html
Habe es auch gerade mal ausprobiert. Bei mir funktioniert es weder unter Kubuntu 14.04, noch unter Arch. Führe ich STM32CubeProgrammer aus, bekomme ich immer den Fehler
1 | Error: Could not find or load main class com.st.app.Main |
Eventuell liegt es daran, dass ich kein Java von Oracle, sondern OpenJDK installiert habe. Der "Trusted Package Creator" funktioniert hingegen.
Christopher J. schrieb: > dass ich kein Java von Oracle, sondern OpenJDK > installiert habe Mein OpenJDK ist von Oracle, oder sehe ich das falsch? http://openjdk.java.net/ java -version openjdk version "1.8.0_151" OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12) OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
Unter OpenSuse ohne Sun Java aber mit dem normalen Distributionsjava muss man java-openjfx installieren.
Christopher J. schrieb: > Error: Could not find or load main class com.st.app.Main Gleiches Problem hier.
Uwe B. schrieb: > Unter OpenSuse ohne Sun Java aber mit dem normalen Distributionsjava > muss man java-openjfx installieren. Danke für den Hinweis! Das hat auch unter Kubuntu zum Ziel geführt.
Beitrag #5270067 wurde vom Autor gelöscht.
Unter Arch hat es bei mir ebenfalls mit java-openjfx geklappt. Bei *buntu 14.04 finde ich beim besten willen keine fertigen Pakete und mir das selber zu kompilieren ist mir zu aufwändig, da ich das 14.04er ohnehin mal erneuern wollte. pegel schrieb: > Mein OpenJDK ist von Oracle, oder sehe ich das falsch? Stimmt, scheint mittlerweile auch von Oracle betreut zu werden. Hauptsponsor und treibende Kraft hinter dem OpenJDK war lange Zeit Intel. Mit dem "Java von Oracle" meinte ich das "richtige" Java von Oracle ;)
... ich habs mit Slackware 14.2 ausprobiert und funktioniert mit java-openjfx
Unter Windows 7 und Windows 10 läuft es ebenfalls absolut Problemlos. Was ich ein bisschen "Naja" finde, ist der Updatezwang für den ST-Link. Lief aber absolut problemlos durch. Nur bei den kleinen China-ST-Link Clone hatte ich erst so meine Sorge, da hat er aber auch tadellos mitgemacht und läuft noch. Der ST Link an den Nucleos geht wunderbar und auch der normale ST Link.
Nach dem ich keine Möglichkeit gefunden habe den µC Speicher auszulesen und in eine Datei zu speichern, habe ich mir die Kommandozeilen Version angesehen. Damit geht es, und noch mehr. Hilfe: ./STM32_Programmer.sh -h File -> µC: ./STM32_Programmer.sh -c port=SWD -w test1.bin 0x08000000 µC -> File: ./STM32_Programmer.sh -c port=SWD -r 0x08000000 0x10000 test2.bin
Ein direktes hochladen der .elf Datei und anschliessendes Reset geht so: ./STM32_Programmer.sh -c port=SWD -w Blinky.elf -rst
Rene K. schrieb: > Nur bei den kleinen China-ST-Link > Clone hatte ich erst so meine Sorge, da hat er aber auch tadellos > mitgemacht und läuft noch. ... dann dürfte bei den Clones dann allerdings STM8 nicht mehr funktionieren, weil ja eine neue Firmware überschrieben wird, die keine Unterstützung für STM8 hat. Oder hat das Update auch gleich eine Software mit STM8-Unterstützung parat ?
stm8flash funktioniert bei mir mit der neuesten Firmware problemlos. Im Grunde muss das ja auch so sein, weil ST ja auch den ST-Link V2 als eigenes Gerät anbietet und der explizit auch für STM8 geeignet ist. Wäre ja echt ein Knaller wenn sie den STM8-Support per Update entfernen würden und das auch noch quasi unwiederbringlich. Lediglich die STM32CubeProgrammer Software hat keinen STM8-Support.
Das Tool ersetzt so wies ausschaut auch gleich den alten "FlashLoader", der die meisten neuen Typen (z.B. L4) nicht einmal mehr erkannt hat... Für die platformübergreifende Veröffentlichung gibts auch ein Mitarbeitsplus. Sehr brav ST, sehr brav ;)
Interessant ist, wann (und zu welchem Preis) es den STLINKv3 geben wird. SWD mit 24 MHz hört sich ja schon mal besser als 4 MHz an ...
hm, scheint mit dem alten USB DFU Mode nicht kompatibel zu sein. Musste die alten Treiber löschen und ne *.bat für die neuen Treiber erneut anklicken... dann konnte ich DFU Mode programmieren. Leider erstellt es keine *.dfu Files und kann auch keine Einspielen... also was DFU angeht, muss ich gleich wieder zurück rollen... :-/
A. B. schrieb: > Interessant ist, wann (und zu welchem Preis) es den STLINKv3 geben wird. > SWD mit 24 MHz hört sich ja schon mal besser als 4 MHz an ... Woher hast du diese Info?
Christopher J. schrieb: > A. B. schrieb: >> Interessant ist, wann (und zu welchem Preis) es den STLINKv3 geben wird. >> SWD mit 24 MHz hört sich ja schon mal besser als 4 MHz an ... > > Woher hast du diese Info? http://www.st.com/content/ccc/resource/technical/document/user_manual/group0/76/3e/bd/0d/cf/4d/45/25/DM00403500/files/DM00403500.pdf/jcr:content/translations/en.DM00403500.pdf Seite 28 -> "SWD: STLinkV2: 4000 kHz, STLinkV3: 24000 kHz"
Ahhh, ich hab natürlich das Kleingedruckte nicht gelesen. Klingt sehr interessant. Ich gehe mal davon aus, dass der V3 dann auf einem F7 mit USB-HS basiert. Das dürfte dann auch einen guten Geschwindigkeitszuwachs beim Tracing (SWO) bringen.
Christopher J. schrieb: > stm8flash funktioniert bei mir mit der neuesten Firmware problemlos. Im > Grunde muss das ja auch so sein, weil ST ja auch den ST-Link V2 als > eigenes Gerät anbietet und der explizit auch für STM8 geeignet ist. ... ich habe jetzt auch einmal einen China-Clone riskiert und ein Update darauf gemacht und der Clone funktioniert mit stm8flash bei mir auch immer noch. Verwunderlich, dass ein China-Clone updatefähig ist. Das was China in den Clones am laufen hat, dürfte dann wohl eine Raubkopie (weil nirgends irgendwo eine Quelle im Source frei verfügbar ist). Vewunderlich, dass ST dem kein Riegel vorschiebt.
Ralph S. schrieb: > Vewunderlich, dass ST dem kein Riegel vorschiebt. Die machen vermutlich mit dem ST-Link eh kein Geld. Da freuen die sich dass ein paar Chinesen ihnen den Aufwand für Produktion & Betrieb abnehmen, um so auch den Markt der Ultra-Geizigen zu bedienen, die an jedem Tool noch ein paar € sparen wollen. Im Endeffekt machen sie so vermutlich noch Gewinn, weil sie so mehr Controller verkaufen.
Dr. Sommer schrieb: > Im Endeffekt machen sie so > vermutlich noch Gewinn, weil sie so mehr Controller verkaufen. Denke ich auch. Der originale ST-Link V2 kostet bei Mouser 18,79€. Was wollen sie denn daran noch groß verdienen? Ralph S. schrieb: > Verwunderlich, dass ein China-Clone updatefähig ist. Das was China in > den Clones am laufen hat, dürfte dann wohl eine Raubkopie (weil nirgends > irgendwo eine Quelle im Source frei verfügbar ist). > > Vewunderlich, dass ST dem kein Riegel vorschiebt. Sie können dem auch keinen Riegel vorschieben. Findige Leute haben den Updatemechanismus des ST-Link reversed, die (verschlüsselten) Binaries stecken in den .jar-Dateien des Updaters und die Schlüssel sind bekannt. Siehe z.B. http://www.taylorkillian.com/2013/01/retrieving-st-linkv2-firmware-from.html oder auch https://lujji.github.io/blog/reverse-engineering-stlink-firmware/. Problematisch ist die Sache in meinen Augen vor allem für Firmen wie Segger, die dann per Update einen J-Link daraus machen, den aber nicht verschenken wollen, weil sie eben damit ihre Brötchen verdienen. Es grenzt für mich schon fast schon an ein Wunder, dass die ST-Link "mini" Dinger nicht auch in identischer Bauweise als J-Link "mini" verkauft werden.
Christopher J. schrieb: > verschenken wollen, weil sie eben damit ihre Brötchen verdienen. Es > grenzt für mich schon fast schon an ein Wunder, dass die ST-Link "mini" > Dinger nicht auch in identischer Bauweise als J-Link "mini" verkauft > werden. Hm, https://www.aliexpress.com/item/CJMCU-Jlink-for-SWD-Jlink-3-Wire-for-STM32-on-SWD-Debug/32622682260.html sieht verdächtig genau danach aus.
Joa, sieht tatsächlich so aus. Scheint sich wohl noch nicht in ganz Shenzhen herumgesprochen zu haben, sonst wären es die exakt gleichen Dinger wie die ST-Link, also im USB-Dongle nur eben mit anderer Firmware und der Preisunterschied wäre geringer bzw. nicht vorhanden ;)
Hat so ein Segger J-Link Vorteile gegenüber einem ST-Link? Außer dass der J-Link auch andere Controller als ST kann?
Bla schrieb: > Hat so ein Segger J-Link Vorteile gegenüber einem ST-Link? Die sind wesentlich schneller und stabiler, und es gibt offiziellen Linux-Support (auch zum Debuggen, nicht nur Flashen). Es hat vermutlich seinen Grund, warum ST bei seinen "Premium"-Eval-Kits einen J-Link und keinen ST-Link beilegt... ;-)
Wie viel ist denn wesentlich? Wenn ich 3-4 Sekunden brauche um mit dem ST-Link 64k Flash eines STM32F0 zu programmieren, was könnte so ein Segger zeitlich?
Bla schrieb: > as könnte so ein > Segger zeitlich? Hier steht was dazu: https://www.segger.com/products/debug-probes/j-link/technology/flash-download/#tab-3145-1 Bei mir war's jedenfalls so schnell dass das Starten der Debug-Configuration in eclipse schon länger dauert ;-) Wichtiger als die Geschwindigkeit des Flashens ist aber IMO die Geschwindigkeit fürs Step-by-Step-Debuggen. Das war (zumindest bei mir) beim ST-Link immer 1-2sec pro Zeile, beim JLink kaum wahrnehmbar (0.1sec oder so). Beim ST-Link haben mich die skurrilen wohl von der Mondphase abhängigen Fehler (selbst von der Original ST-Software) irgendwann so genervt dass ich mir einen JLink "gegönnt" habe... Das hat sich auf jeden Fall gelohnt. Für den Einstieg ist ein ST-Link aber gewiss nicht verkehrt.
Interessant, danke. Ich frage nicht einmal für mich. Die Fertigung hätte immer am liebsten alles ganz schnell, aber setzt nen ST-Link ein. Werde mal drauf hinweisen
Bla schrieb: > Die Fertigung hätte > immer am liebsten alles ganz schnell, aber setzt nen ST-Link ein. Werde > mal drauf hinweisen Jo. Die haben auch spezielle Production Programmer zum Massen-Programmieren: https://www.segger.com/products/production/flasher/ Aber nicht ganz billig ;-)
Ich kann Dr. Sommers Bemerkungen zum ST-Link nicht bestätigen. Ich experimentiere seit einem Jahr mit STM32F103 Controllern und hatte bisher noch kein einziges mal Fehlfunktionen oder Treiberprobleme. Auch die Geschwindigkeit beim Debuggen ist völlig Ok (weitaus schneller als 1-2s pro Step). Ich habe keineswegs das Gefühl, dass der ST-Link mich irgendwo merklich ausbremst oder behindert. Meine Erfahrungen beziehen sich auf den ST-Link v2.1, der am Nucleo64 Board hängt. Den nutze ich auch für "externe" Chips.
Der STLink kann fast so schnell sein wie ein JLink wenn die Software mitmacht. Mit OpenOCD hatte ich auch das Problem daß jeder Einzelschritt eine gute Sekunde gebraucht hat. Mit Crossworks dagegen geht das praktisch ohne Verzögerung - wie mit einem JLink. Das Flashen ist mit dem JLink vielleicht 30% schneller. Einziges Problem das ich mit dem STLink habe ist daß ich das Teil kurz vom USB abstecken muß wenn ein Verbindungsfehler aufgetreten ist. Z.B. wenn ich die Stromversorgung vom Controller abgeschaltet habe. Beim JLink reicht dann ein einfacher "Reconnect" per Software.
> Einziges Problem das ich mit dem STLink habe ist daß ich das Teil kurz > vom USB abstecken muß wenn ein Verbindungsfehler aufgetreten ist Ist mir noch nicht passiert. Meiner kann "einfach so" reconnecten.
Das GUI Dingens mach hier Zicken (die CLI Version nicht). Umgebung: Debian 8, x86_64. Schon der Installer wollte nicht mit meiner default-JRE 1.7.0_151 starten, also habe ich JAVA_HOME auf die 1.8-er JRE gesetzt. Dann lief immerhin der Installer los. Die Anwendung selber dann nicht. Fehlermeldung:
1 | Exception in Application start method |
2 | ... (stack trace) |
3 | There is an incompatible JNA native library installed on this system |
4 | Expected: 5.2.0 |
5 | Found: 4.0.0 |
6 | ... |
7 | To resolve this issue you may do one of the following: |
8 | - remove or uninstall the offending library |
9 | - set the system property jna.nosys=true |
10 | - set jna.boot.library.path to include the path to the version of the |
11 | jnidispatch library included with the JNA jar file you are using |
Punkt 1 kommt nicht in Frage. Punkt 2 führte zum Ziel, nachdem ich herausgefunden habe, wie man dieses dämliche Java bequatschen muß, damit es tut was man will:
1 | cat STM32CubeProgrammer |
2 | #!/bin/bash |
3 | |
4 | # XL was here! |
5 | export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 |
6 | export JAVA_TOOL_OPTIONS=-Djna.nosys=true |
7 | # end XL |
8 | |
9 | DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
|
10 | export LD_LIBRARY_PATH=$DIR/../lib:$LD_LIBRARY_PATH |
11 | $DIR/STM32CubeProgrammerLauncher |
Warum STM ihr Startup-Gerümpel als Binärcode ausliefert und Java nicht einfach aus einem Shellskript aufruft wie alle anderen das tun, verstehe ich auch nicht.
Dr. Sommer schrieb: > Bla schrieb: >> Die Fertigung hätte >> immer am liebsten alles ganz schnell, aber setzt nen ST-Link ein. Werde >> mal drauf hinweisen > Jo. Die haben auch spezielle Production Programmer zum > Massen-Programmieren: > https://www.segger.com/products/production/flasher/ > Aber nicht ganz billig ;-) Ich denke ~600,- Euro in die Fertigung investieren kann sich lohnen. Wenn die Produktion steht wird es wahrscheinlich teurer ;-). Kommt aber sicherlich immer auf die Anzahl der gefertigten Geräte an. Wenn ich nur 10 Geräte im Jahr fertige reicht vielleicht auch ein ST-Link.
Stefan U. schrieb: > Ich kann Dr. Sommers Bemerkungen zum ST-Link nicht bestätigen. > > Ich experimentiere seit einem Jahr mit STM32F103 Controllern Ja es kann gut sein dass sich das geändert hat, seitdem ich meine Probleme damit hatte (ca 2012). OpenOCD hatte da IIRC noch gar keinen ST-Link Support, das ging unter Linux nur mit dem texane st-link utility. Oft hatte ich die Situation, dass entweder nur das texane st-link funktionierte oder das ST-Eigene ST-Link Utility - aber nie beide an einem Tag. Außerdem konnte das ST-Link keine Controller resetten, die sich im Sleep-Mode ("WFI"-Instruktion) befinden - der JLink hat da keine Probleme mit. Deswegen hab ich gewechselt und nicht zurückgeblickt ;-) Vor ca. 2 Jahren hab ich mir ein STM32F7-Discovery zugelegt, und der interne ST-Link hat natürlich überhaupt nicht funktioniert - die ST-eigene SW4STM32-Software hat nur kuriose Fehlermeldungen produziert. Das war mir zu blöd, hab mir von einem Freund helfen lassen die SWD-Leitungen rauszuführen (super dass die kaum zugänglich sind), JLink drangeklemmt, hat sofort funktioniert.
PS: Ich habe mal mit einen STM32-Discovery-Board von der Uni gearbeitet und da ganz naiv auch "WFI" genutzt - ich kannte den Trick, den Reset-Button im richtigen Moment zu drücken, ja. Am nächsten Tag beschuldigte mich der Prof den Controller zerstört/gebrickt zu haben (Debug-Interface abgeschaltet oder so), weil die integrierten ST-Links nicht mehr funktionierten. Da wusste ich wieder warum ich dieses Teil wenn möglich vermeide!
> Außerdem konnte das ST-Link keine Controller > resetten, die sich im Sleep-Mode ("WFI"-Instruktion) befinden Das kann er inzwischen, wenn man die optionale Reset Leitung verbindet. Bei den Nucleo64 Boards ist die Reset Leitung auch ordentlich mit dem Target verbunden.
Ok, das ist gut. Wäre auch leicht absurd, stromsparende Controller wie die STM32L*-Serie zu vermarkten, und dann die Nutzung der wichtigstem Stromspare-Maßnahme (Sleepmodes) unnötig zu erschweren...
Offensichtlich befindet sich die Software von ST auf breiter Front noch im Entwicklungsstadium. Naja, Atmel war in dieser Hinsicht auch nicht besser.
Demnächst soll es einen ST-Link/v3 geben, der wohl deutlich schneller als die bisherigen ST-Link und ST-Link/v2v sein soll: https://community.st.com/thread/46479-stlinkv3 Philipp
Angehängte Dateien:
-
st.png
35 KB
Hmm...wenn ich auf den Link klicke, komme ich auf die Seite im Screenshot...SCNR ;-)
:
Bearbeitet durch User
Til S. schrieb: > Hmm...wenn ich auf den Link klicke, komme ich auf die Seite im > Screenshot...SCNR ;-) Ja, ein Bug in der Forensoftware von ST. Manchmal geht es, manchmal nicht. Für viele (einschließlich mir) funktioniert es nahezu immer, wenn ich bei ST eingeloggt bin, aber ohne Login nur etwa jedes zweite Mal. Scheint sich aber jeden Tag zu ändern. Dazu gibt es schon eine lange Diskussion: https://community.st.com/message/180957-re-how-to-use-forum-nowdayshttps://community.st.com/message/180957-re-how-to-use-forum-nowdays Philipp
Philipp Klaus K. schrieb: > Für viele (einschließlich mir) funktioniert es nahezu immer, wenn > ich bei ST eingeloggt bin Das hatte ich noch nicht probiert aber nachdem ich mich mal eingeloggt habe, hat es dann auch funktioniert. Es kam dann gleich ein "Welcome to Jive" und danach gleich oben die Meldung "We have identified the technical issues..." vom 01.01.18 ;) Naja, die Mühlen bei ST mahlen eben manchmal etwas langsamer :D
Man kann den Stlink auch zu einem BMP Debugger umflashen: https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe Single Stepping geht da ohne nennenswertes Delay.
Uwe B. schrieb: > Man kann den Stlink auch zu einem BMP Debugger umflashen: > https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe > > Single Stepping geht da ohne nennenswertes Delay. Aber dann halt nicht mehr für den STM8. Philipp
Der STLink auf den Disco/Nucleo Boards kann aber sowieso kein SWIM fuer STM8.
Ich bin gerade dabei das Tool (STM32CubeProgrammer) auszuprobieren. Die Verbindung mit dem Device über UART funktioniert. Beim Ausführen der "STM32Bootloader.bat"-Datei, für die Installation des "USB DFU" Treibers, bekomme ich folgende Fehlermeldung: "Verarbeitungsinf.: DFU_in_HS_Mode.inf Fehler beim Hinzufügen des Treiberpakets: Der Hashwert für die Datei ist in der angegebenen Katalogdatei nicht vorhanden. Die Datei ist wahrscheinlich beschädigt oder wurde unerlaubt geändert." Den alten USB-Treiber für das "DfuSe" Tool habe ich inkl. des Tools deinstalliert und dann die .bat-Datei ausgeführt. Also genau so wie es in der Anleitung steht. Das STM32CubeProgrammer Tool läst sicht einwandfrei starten und die Verbindung zum Device über UART funktioniert auch. Ist dieses Problem auch schon bei jemandem aufgetretten? Gibt es eine Lösung?
Angehängte Dateien:
-
jfx.png
15 KB
Jetzt habe ich auch ein Problem mit dem CubeProg. In Ubuntu nach der Aktualisierung von openjdk-8 auf openjdk-11 startet die graphische Oberfläche nicht mehr. Hat jemand eine Lösung, ohne zur Version 8 zurück zu kehren?
Du musst Oracle JRE 8 verwenden. Ist doof, geht aber nicht anders. Nimm diesen Download: https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html Und starte das Programm mit folgendem Script:
1 | #!/bin/bash
|
2 | |
3 | # Set path of Oracle JRE 8
|
4 | JAVA_HOME=/opt/jre1.8.0_202-amd64/ |
5 | |
6 | PATH=$JAVA_HOME/bin/:$PATH |
7 | |
8 | # Unpack libraries, if necessary
|
9 | cd $JAVA_HOME/lib |
10 | if [ ! -f rt.jar ]; then |
11 | ../bin/unpack200 rt.pack rt.jar |
12 | fi
|
13 | if [ ! -f jsse.jar ]; then |
14 | ../bin/unpack200 jsse.pack jsse.jar |
15 | fi
|
16 | if [ ! -f charsets.jar ]; then |
17 | ../bin/unpack200 charsets.pack charsets.jar |
18 | fi
|
19 | |
20 | # Start STM32 Cube Programmer
|
21 | cd /opt/STM32CubeProgrammer
|
22 | bin/STM32CubeProgrammer |
Stefanus F. schrieb: > Ist doof Das stimmt. Darum will ich das möglichst vermeiden. Problem ist, auch die Versionen 1.0 und 1.4 vom CubeProg wollen nicht mehr. Ob ST das wohl ändern wird?
pegel schrieb: > Ob ST das wohl ändern wird? Ich glaube nicht, dass sie die alten Programme noch pflegen. Aber sie sollten wenigstens die aktuelle Version für Java 11 fit machen und die Abhängigkeit zu Java FX loswerden.
Die 2.0 hatte ich noch am Laufen. Mit der 2.1 und dem neuen CubeMX wollte ich alles auf den neuesten Stand bringen. :(
pegel schrieb: > Die 2.0 hatte ich noch am Laufen. > Mit der 2.1 und dem neuen CubeMX wollte ich alles auf den neuesten Stand > bringen. :( Läuft 2.1 schon wieder nicht? Auch nicht mit Orale JRE 8?
Ich habe openjdk-8 vollständig deinstalliert, da kein anderes Programm das mehr benutzt hat.
pegel schrieb: > Ich habe openjdk-8 vollständig deinstalliert, da kein anderes Programm > das mehr benutzt hat. Ich rede aber von Oracle JRE 8. Und zwar von dem Download der Oracle Seite. Oracle JDK ist nicht Oracle JDK und Oracle JRE ist wieder (in Details) anders.
Ist wohl irgendwie alles Oracle, nur die Lizenzen unterscheiden sich. Mit Oracle JRE 8 geht es mir nicht sonderlich gut. Deshalb mein zögern.
pegel schrieb: > Ist wohl irgendwie alles Oracle, nur die Lizenzen unterscheiden sich. Nein. Oracle JRE enthält nur die Laufzeitumgebung, während Oracle JDK auch Entwickler-Tools enthält. Beide Oracle Pakete enthalten Features, die in Open JRE/JDK nicht enthalten sind. Umgekehrt enthält die Open-Variante Features, die die der kommerziellen Version von Oracle nicht enthalten sind. Ich programmiere beruflich seit 20 Jahren mit Java. Dieser Cube Programmer ist allerdings mein erster Fall, wo diese feinen Unterschiede zwischen geht und geht-nicht entscheiden.
Das Problem ist nur die graphische Oberfläche. Die Kommandozeilen Version funktioniert ja.
Die Version 2.1.0 läuft jetzt bei mir. https://community.st.com/s/question/0D50X00009q3X4jSAE/stm32cubeprogrammer-for-linux Dank dem Beitrag:
1 | Kolja Waschk (Community Member) |
2 | a month ago |
3 | |
4 | For the record, I seem to have succeeded in Ubuntu 18.04 with openjdk-11 and openjfx 11 after commenting out the check for javafx in STM32CubeProgrammer/util/OpenJFXScript.csh and replacing the |
5 | |
6 | $DIR/STM32CubeProgrammerLauncher in STM32CubeProgrammer/bin/STM32CubeProgrammer by |
7 | java --module-path /usr/share/openjfx/lib --add-modules=javafx.controls,javafx.base,javafx.fxml,javafx.media,javafx.web,javafx.swing -jar $DIR/STM32CubeProgrammerLauncher |
Ich meine natürlich die graphische Oberfläche. Im Textmodus funktioniert auch die neue 2.2.1 .
Ich würde gar nicht so großartig herum fummeln sondern das Programm einfach mit der Java Version starten, für die es geschrieben wurde. Und das ist Oracle JRE 1.8. https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html Benutze dazu das Startscript aus Beitrag Beitrag "Re: STM32CubeProgrammer" Das funktioniert mit allen Programm-Versionen, die bisher veröffentlicht wurden. So spart man sich, bei jeder neuen Version mit neuen Problemen zu kämpfen. Ich verstehe auch gar nicht, warum manche Leute sich so schwer damit tun, neben der aktuellen auch eine alte Java Version zu installieren. Die schließen sich ja nicht gegenseitig aus! Wer das für grobe Platzverschwendung hält möge mal bitte die Größe des Paketes mit dem tatsächlichen Disk Space vergleichen. Oder schau mal in deine Windows Installation, wie viele Versionen vom wesentlich größeren .NET Framework da parallel installiert sind. Auch auf Linux Rechnern findet man zahlreiche Bibliotheken parallel in unterschiedlichen Versionen - so what?
Ich will OpenJava! Nicht Oracle! ;) Davon habe ich die 8 und die 11 umschaltbar installiert. Die 2.2.1 funktioniert auch mit der 8 nicht. Ausserdem ist es nur vorübergehend. STM ist sehr dynamisch, ich denke die schaffen das bald. Bis dahin ist das für die gedacht, die das so sehen wie ich. Andere können das gern ignorieren.
pegel schrieb: > STM ist sehr dynamisch, ich denke die schaffen das bald. Ich warte seit einem Jahr darauf.
Stefan F. schrieb: > Ich warte seit einem Jahr darauf. Noch etwas Geduld bitte. Das mit CubeMX auf 4k Schirm und viele andere Kleinigkeiten sprechen für sich. Ich bin guter Hoffnung.
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.