STM32CubeMX ist jetzt in die IDE integriert. https://www.st.com/en/development-tools/stm32cubeide.html
Na dann hoffen wir mal, dass es keinen MX Zwang gibt. Im Sinne von, dass man ohne einbinden der Libs etc. nichts übersetzen kann. Ich benutze nämlich nur direkten Registerzugriff. PS: Was soll eigentlich dieser Unsinn, dass man für jeden Download seinen Namen, Nachnamen und E-mail angeben muss. Die wissen doch genau, dass die meisten (genauso wie ich) da nur Unsinn und eine Wegwerf E-mail angeben. EDIT: Scheinbar gibt es immernoch keine Strg+F11 Run option.. oder übersehe ich die?
Curby23523 N. schrieb: > Ich benutze > nämlich nur direkten Registerzugriff. Ich schätze CubeMX sehr, weil ich damit in wenig Zeit viel erreiche. Wie lange brauchst Du denn z.B. um eine DMA Übertragung von ADC1 und ADC2 im Dual-Mode zu einem Buffer im RAM aufzubauen wenn Du die Bits in den Registern direkt ansprichst? Ich stelle mir das sehr aufwändig vor die Datenblätter und Referenzen zu wälzen und dann den Code zu debuggen?
Thomas L. schrieb: > STM32CubeMX ist jetzt in die IDE integriert. > https://www.st.com/en/development-tools/stm32cubeide.html Sieht fancy aus, vor allem wegen der Trace-Optionen. Gab/gibt es die schon im TrueStudio?
Ich habe die STM32CubeIDE inzwischen in gebrauch. Sieht nicht sonderlich anders aus, als das bisherige Atollic. Horst schrieb: > Ich schätze CubeMX sehr, weil ich damit in wenig Zeit viel erreiche. Wie > lange brauchst Du denn z.B. um eine DMA Übertragung von ADC1 und ADC2 im > Dual-Mode zu einem Buffer im RAM aufzubauen wenn Du die Bits in den > Registern direkt ansprichst? Ich stelle mir das sehr aufwändig vor die > Datenblätter und Referenzen zu wälzen und dann den Code zu debuggen? 5 Minuten, manchmal 10 (wenn noch nie gemacht). Macht man in einem Projekt in der Regel ein oder zwei mal, dafür hat man komplett auf HAL verzichtet. Ich verbrauche wesentlich mehr Zeit beim Programmieren/debuggen meines eigenen Codes, als vom Zugriff auf die Hardware. Und wie immer geht es bei Registerzugriff NICHT um Zeitgewinn (wobei man auch sehr schnell ist, wenn man es einmal verstanden hat) - es geht um Sicherheit. Ich weiß wie es geht und was passiert und ich weiß, dass kein versteckter Code vorhanden ist, der mir irgendwie dazwischen grätscht und womöglich noch viele Bugs hat (was die HAL nachgewiesener Maßen hat). Bei SPI sind es z.B. nur diese Zeilen:
1 | RCC->AHBENR |= RCC_AHBENR_DMA1EN; |
2 | RCC->APB2ENR |= RCC_APB2ENR_SPI1EN; |
3 | |
4 | DMA1_Channel2->CPAR = (uint32_t)&SPI1->DR; |
5 | DMA1_Channel2->CMAR = (uint32_t)&au8OutputData; |
6 | DMA1_Channel2->CNDTR = DATASIZE - 1; |
7 | DMA1_Channel2->CCR = DMA_CCR_EN | DMA_CCR_MINC | DMA_CCR_DIR | DMA_CCR_TCIE; |
8 | |
9 | SPI1->CR1 |= SPI_CR1_SSM; |
10 | SPI1->CR1 |= SPI_CR1_MSTR; |
11 | SPI1->CR1 |= ((uint16_t)2<<3); |
12 | SPI1->CR2 |= (0b0111ul << 8); |
13 | SPI1->CR2 |= SPI_CR2_SSOE; |
14 | SPI1->CR2 |= SPI_CR2_FRXTH; |
15 | SPI1->CR2 |= SPI_CR2_RXDMAEN; |
16 | SPI1->CR1 |= SPI_CR1_SPE; |
17 | |
18 | SPI_SendDMA(SPI1, au8OutputData[0]); |
Thomas L. schrieb: > STM32CubeMX ist jetzt in die IDE integriert. Ich glaub es einfach nicht. Es scheint keine 32-Bit-Installation zu geben. Warum muss so eine billige Java App 64-bittig sein?
Au weia schrieb: > Es scheint keine 32-Bit-Installation zu geben. X64 gibt es seit 2003, wo ist das Problem?
Damals in Stalingrad schrieb: > X64 gibt es seit 2003, wo ist das Problem? Dass es triftige Gründe gibt ein 32-Bit (Betriebs-)System zu verwenden (auch wenn man 64-bittige Hardware hat) und darauf keine 64-Bit Applikationen laufen.
>> X64 gibt es seit 2003, wo ist das Problem? > Dass es triftige Gründe gibt ein 32-Bit (Betriebs-)System Ich frage mich welche? Ich weiss keine echten Gründe noch 32 Bitig fahren.
Weiß jemand, wie man in STM32CubeIDE im Debug Modus mehrere Instanzen der SFR View anzeigen erzeugen kann? Wäre ganz cool beim Debuggen mehrere Hardwareregister aufeinmal beobachten zu können...
Funktioniert der Scheißdreck bei irgendwem? Hab mir jetzt vor kurzem mal die aktuelle Version auf eine Arch-Installation gezogen, ein Projekt erstellt und eine Debug-Konfiguration dafür kreiert. Bis ich soweit kam musste ich schon einmal den Indexer abdrehn weil mein Projekt scheinbar zu groß ist... Ja gut, verständlich dass 2MB Text einen Rechner mit 64GB in die Knie zwingen. Dann musste ich mein executable umbenennen, weil sich das Plugin weigert irgendwas zu nehmen was nicht auf .elf endet. Auto-build abdrehn? Geht nicht. Weder in den Workspace settings noch in der Debug-Konfiguration. Egal, proceed... Dann erbarmt sich mein JLink tatsächlich und spielt das Projekt ein! Es öffnet sich die Debug Perspective und BOOM. Die Scheiß IDE is tot...
Vincent H. schrieb: > Funktioniert der Scheißdreck bei irgendwem? Ja, vollkommen problemlos. Vincent H. schrieb: > ein Projekt > erstellt und eine Debug-Konfiguration dafür kreiert. Die Debug-Konfiguration ist bereits fertig wenn das Projekt korrekt erzeugt wurde. Ausser dem Umstellen auf J-Link musste ich da noch nie etwas ändern. Vincent H. schrieb: > Dann musste ich mein executable umbenennen, weil sich das Plugin weigert > irgendwas zu nehmen was nicht auf .elf endet. Dann war das aber kein CubeIDE-Projekt. Das widerspricht sich dann mit dem, was du oben schreibst. Vincent H. schrieb: > ein Projekt > erstellt Vincent H. schrieb: > Dann erbarmt sich mein JLink tatsächlich und spielt das Projekt ein! Es > öffnet sich die Debug Perspective und BOOM. Die Scheiß IDE is tot... Ist bei meiner täglichen Arbeit damit noch nie passiert. Bist du sicher, daß dein JavaRuntime dazu passt?
Harry L. schrieb: > Dann war das aber kein CubeIDE-Projekt. > Das widerspricht sich dann mit dem, was du oben schreibst. Ist es auch nicht. Mein executable erzeuge ich mit cmake und als Editor nutze ich lieber VSCode. STM32CubeIDE wollte ich eigentlich nur ausprobieren weil die aktuelle Hardware-Revision eines Produkts an dem ich arbeite wieder einen SWO-Ausgang besitzt und damit doch einige ganz praktische Dinge möglich sind. Was natürlich trotzdem problemlos gehn sollte ist ein "default" Projekt auf Basis des selben Prozessors zu erzeugen, dort alles rauszulöschen und dann schlichtweg eine Debug-Konfiguration anzulegen die eben auf das via cmake compilierte executable zeigt. Harry L. schrieb: > Ist bei meiner täglichen Arbeit damit noch nie passiert. > Bist du sicher, daß dein JavaRuntime dazu passt? Keine Ahnung ehrlich gesagt. Pacman sagt mir das folgendes installiert ist: local/java-environment-common 3-1 Common files for Java Development Kits local/java-runtime-common 3-1 Common files for Java Runtime Environments local/jdk8-openjdk 8.u222-2 OpenJDK Java 8 development kit local/jre8-openjdk 8.u222-2 OpenJDK Java 8 full runtime environment local/jre8-openjdk-headless 8.u222-2 OpenJDK Java 8 headless runtime environment Ein normales Eclipse + GNU MCU Plugin funktioniert interessanterweise, nur fehlen dort halt die ganzen Trace Features. :/ /edit Einspielen tut er die Software noch bevor er sich abschießt.
:
Bearbeitet durch User
Von Java hab ich leider wirklich keine Ahnung, und um Problemen damit von Anfang an aus dem Weg zu gehen hab ich bei mir Oracle-Java 8 installiert. Das hat zumindest immer problemlos funktioniert. Ob es tatsächlich an OpenJDK liegt kann ich also nicht sagen. Vielleicht solltest du mal versuchen, dein komplettes Projekt in CubeIDE zu importieren. Das funktioniert eigentlich recht gut - zumindest mit makefile-Projekten. Mit cmake hab ich aber auch keine Erfahrungen. Oder du erzeugst ein neues Cube-Projekt und kopierst deinen Code in das Projekt unter Beibehalten von Linker- und Debug-File.
:
Bearbeitet durch User
Also bei mir funktioniert STM32CubeIDE auch. Es bringt, wenn nichts verstellt wurde, sogar sein eigenes java mit. Siehe Verzeichnis jre.
Oh man. Ich hab grad durch Zufall entdeckt was Schuld is. Man darf in den Debug-Konfigurationen aus irgendeinem Grund keine Variablen verwenden ala:
1 | ${project_loc}/build/test.elf |
Verwende ich einen absoluten Pfad (home/...), dann funktionierts problemlos...
pegel schrieb: > Es bringt, wenn nichts verstellt wurde, sogar sein eigenes java mit. Aber nur in der Windoof-Variante. Vincent und ich nutzen Linux.
Harry L. schrieb: > Vincent und ich nutzen Linux. Ich auch. Nur weiss ich nicht welcher Programmteil java benutzt. So meldet es sich im Verzeichnis jre: $ ./java -version openjdk version "1.8.0_202" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
pegel schrieb: > Nur weiss ich nicht welcher Programmteil java benutzt. Die gesamte IDE (Eclipse) und CubeMX sind Java-Programme.
Der STM32CubeProg auch. Der ist auch im Paket enthalten. Müsste man mal testen, ob dessen GUI Version damit funktioniert.
Harry L. schrieb: >> Nur weiss ich nicht welcher Programmteil java benutzt. Ich hätte schreiben sollen, welches dieses und nicht das System Java benutzt.
Gibt es mittlerweile Erfahrungen mit der neuen Version 1.02? Noch benutze ich True Studio und ganz selten mal CubeMx. Gibt es Gründe, noch bei der alten 2er Kombination zu bleiben? Zusätzlich habe ich noch einige alte CooCox Projekte, die ich auch mal umziehen müsste. Gruß Ingo
Ich habe in letzter Zeit etliches getestet... Eine moderne und die meiner Meinung nach flexibelste Lösung ist Eclipse_cpp_2019_06 dazu noch das MCU Plugin installieren.
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.