Keil µVision vs. STM32CubeIDE

Keil µVision sieht sehr altbacken aus und z.B. git Unterstützung ist 
sehr rudimentär, das ist in die Eclipse basierten IDE schon lange 
eingeflossen, und noch besser in VSCode.
Die GCC ist auch immer besser geworden, ich kenne jetzt keine aktuellen 
Benchmarks aber ich denke bei >= CM3 tun die sich nicht mehr viel. Beim 
CM0 hinkt der gcc Compiler hinterher und erzeugt gößeren Code, das ist 
ein schon seit Jahren offenes issue. Und mittlerweile funktioniert LTO 
bei gcc auch brauchbar.

Ich würden den Support nicht unterschätzen. Wenn ich Probleme mit meinen 
STM32 µC hatte oder mit der Cube IDE, bin ich bei der Suche nach Hilfe 
ab und zu mal in ein Support-Forum von Keil abgedriftet und habe dort 
Antworten gefunden.

Bei ST bekomme ich als Hobbybastler keine Antworten auf meine Anfragen.

Eine Ähnliche Erfahrung hatte ich vor vielen Jahren auch mit Bartels 
Auto-Engineer gemacht. Wer bezahlt, bekommt auch guten Support.

Erfahrung von vor paar Jahren:
Keil kostet viel Kohle aber es funktioniert einfach out of the Box.

Die IDE ist altmodisch und läßt viele moderne Features gerade was 
refactoring, codecompletion usw angeht vermissen.

Der Debugger ist diesem ganzen Eclipse Krempel haushoch 
überlegen(zumindest meine Erfahrung von vor paar Jahren)
Jetzt arbeite ich wieder mit Keil und an dem gesagten hat sich nix 
geändert. Wieviel besser die anderen IDEs geworden sind weiß ich nicht

Alex -. schrieb:
> Nun bin ich nur ein Hobbyprogrammierer, der wirklich ganz einfache
> Programme schreibt. Insofern würde mich interessieren, inwiefern der
> Debugger bei Keil besser ist?

Keil und IAR bieten die Möglichkeit Variablen/Register/Peripherie zur 
Laufzeit anzusehen und verändern zu können. Das finde ich gerade für 
Anfänger einen ganz besonderen Punkt, da der µC dadurch transparenter 
wird.
Einzelschritt ist ja ganz nett, aber wenn gerade ein Schrittmotor 
angesteuert wird stört jeder Zwischenstopp. Steht der DMA-Controller 
gerade still, kann man sich seine Flags ansehen und ggf. neu triggern. 
Manuelles Setzen/Löschen eines Portpins, sein MODER anpassen - das geht 
alles, während das Programm weiterläuft.

Keil hatte ich damals als Demoversion probiert, bin dann doch bei IAR 
hängengeblieben, da dort noch andere µCs unterstüzt werden. Keine Frage: 
IAR ist auch "altbacken" und auch "buggy", aber da gab es schon viel 
Schlechteres.
Die Demoversion geht bis 32 KB und reicht für viele Sachen aus. Wenn die 
IAR-Projekte größer werden können sie meist in andere IDEs importiert 
werden.

Sofern noch vorhanden werde ich von Keil die aktuelle Demoversion der 
IDE erneut antesten.

m.n. schrieb:
> Keil und IAR bieten die Möglichkeit Variablen/Register/Peripherie zur
> Laufzeit anzusehen und verändern zu können. Das finde ich gerade für
> Anfänger einen ganz besonderen Punkt, da der µC dadurch transparenter
> wird.

Das geht mit Segger Embedded Studio und Crossworks auch hervorragend.

Alex -. schrieb:
> Im professionellen Bereich: Welche Debugfunktionen braucht/benutzt man
> darüber hinaus?

Ich habe neulich in einem Java Debugger (IntelliJ IDEA) entdeckt, dass 
man das Programm anhalten kann, wenn eine bestimmte Variable beschrieben 
wird. Das fand ich sehr cool - wusste bis dahin gar nicht, dass das 
geht.

Irgendwann werde ich das wohl auch mal auf µC nutzen wollen. Bisher 
brauchte ich es nicht. Allerdings wusste ich auch nichts davon. Komme 
mir gerade ein bisschen altmodisch vor.

temp schrieb:
> m.n. schrieb:
>> Keil und IAR bieten die Möglichkeit Variablen/Register/Peripherie zur
>> Laufzeit anzusehen und verändern zu können. Das finde ich gerade für
>> Anfänger einen ganz besonderen Punkt, da der µC dadurch transparenter
>> wird.
>
> Das geht mit Segger Embedded Studio und Crossworks auch hervorragend.

Vor einiger Zeit hatte ich Til S. (von Segger) hier auf eine ähnliche 
Funktion wie "Live Watch" (IAR) angesprochen. Die gab es (letztes Jahr?) 
noch nicht.
Vielleicht kannst Du nähere Informationen geben.

Von STM gibt es auch irgendein Zusatzprogramm für grafische Darstellung, 
aber mich interessieren keine bunten Bilder, sondern die Register mit 
ihren einzelen Bits/Bitgruppen.

Random .. schrieb:
> Setzt einen WATCH in der Cortex-M Debug Logik.

Schön zu lesen, dass das im ARM Kern drin ist.

Random .. schrieb:
> m.n. schrieb:
>> sondern die Register mit ihren einzelen Bits/Bitgruppen.
>
> MDK-ARM:
> - SystemViewer: eine Art "Live Datenblatt", vgl. SVD/SVDConv
> - ComponentViewer

Das Keil das kann, ist mir bekannt. Mich interessiert jetzt der Umgang 
mit Segger Emb. Studio.

m.n. schrieb:
> Von STM gibt es auch irgendein Zusatzprogramm für grafische Darstellung,

grafische Darstellung kenne ich von Profilern und wenn RTOS ins Spiel 
kommen. Das hilft vielleicht wenn das Zusammenspiel mehrerer Tasks 
komplexer wird und Breakpoints, die das Timing verändern, nicht mehr 
weiterbringen. Wenn man den Luxus nicht hat, dann hilft man sich mit 
Traces oder anderen Mitteln.
Für verschiedene RTOS gibt es aber auch Plugins für Eclipse basierte 
IDE, und auch für den Cortex-Debug im VSCode gibt es Entwicklungen in 
diese Richtung. Auch wenn das Cortex-Debug längst noch nicht soviel kann 
wie andere Debugger, die Offenheit führt zu kontinuierlicher 
Weiterentwicklung.

m.n. schrieb:
> Vielleicht kannst Du nähere Informationen geben.

Man kann in einem Watchfenster beliebige Variablen einfügen und dann 
z.B. "Twice a Second" in der Dropdownbox wählen. Dann wird hier die 
Variable "TimeTick" alle halbe Sekunde aktualisiert. Ein Click auf den 
Wert ermöglicht dann die Variable zu ändern.

Das geht aber schon immer so und war einer der Gründe warum ich vor 
Jahren mal Crossworks gekauft habe.

Markus M. schrieb:
> Wie man diese zig hunderte Eclipse Dateien ordentlich in ein SVN bekommt
> habe ich leider noch nicht heraus gefunden.

Ich habe genau das immer vermieten, indem ich sie eben nicht ins 
Repository einchecke. Aber dann muss jeder Entwickler sich einen Eclipse 
Workspace selber manuell durch konfigurieren.

temp schrieb:
> Das geht aber schon immer so und war einer der Gründe warum ich vor
> Jahren mal Crossworks gekauft habe.

War ein Ableger bzw. Nachfolger davon nicht EMbitz? Das konnte das - 
glaube ich - auch, gab es auch als eingeschränkte freie Version und war 
auch kostengünstig.
Aber mit Segger und "Live Watch" hast Du wohl keine Information?

Markus M. schrieb:
> Da ist der Keil um Welten besser, da lässt sich das Sichern viel
> zuverlässiger bewerkstelligen, auch wenn mehrere Leute an einem Projekt
> arbeiten mergt SVN die gegenseitigen Änderungen. Und sollte mal etwas
> fehlen gibt es eine sinnvolle Mecker-Meldung.

Ist eben "altbacken" ;-)

Segger entwickelt seine Software auf der Basis von Crossworks. Der 
Screenshot ist von der Segger IDE.

Die "Watch"-Funktion habe ich jetzt im Simulator nachvollziehen können. 
Zweimal pro Sekunde ist zwar die höchste Geschwindigkeit, aber immerhin.
Wie sieht denn die Syntax für zum Beispiel GPIOA->IDR aus? Egal, was ich 
eingebe, bekomme ich immer ein "not found".

Ob das mit den Registern der Peripherie direkt geht kann ich nicht 
sagen. Mir würde aber auch nicht einfallen das zu nutzen. Da sind dann 
zu viele Fallstricke zu beachten. z.B. bei einem UART->DR Register. Da 
würde dann der Debugger 2 mal pro Sekunde die Daten weg schnappen.
Es kann aber auch kein Problem sein, z.B. in einem sowieso vorhandenen 
SysTick- oder Timeinterrupt sowas wie:

1

uint32_t watchVar;

2

3

void SystickHdl()

4

{

5

  watchVar=GPIOA->IDR;

6

  ...

7

}

zu Schreiben. Das sind auch nur 10 Sekunden Arbeit.

Im Memory-Fenster geht die Live-Aktualisierung auch. Erreichbar über die 
rechte Maustaste im Fenster.

Ben S. schrieb:
> Manche stehen echt drauf, sich das Leben schwer zu machen. Masochismus?

Wenn du schon wetterst, dann erklär wenigstens was du damit sagen 
willst.

Ben S. schrieb:
> Wenn ich stoppe, kann ich das beim Studio auch - ist in den meisten
> Fällen auch viel sinnvoller, als in Echtzeit.

Du kannst höchstens von dir ausgehen und von deinen meisten Fällen 
berichten.
Es gibt aber auch Leute die 90% ihrer Zeit Motorsteuerungen (FOC), 
Wechselrichter o.ä. entwickeln. Da kann man dann aber sehr oft das 
Programm unter keinen Umständen anhalten. Und dafür ist ein LiveView ein 
Segen.

Ben S. schrieb:
> m.n. schrieb:
>> Keil und IAR bieten die Möglichkeit Variablen/Register/Peripherie zur
>> Laufzeit anzusehen und verändern zu können.
>
> Wenn ich stoppe, kann ich das beim Studio auch - ist in den meisten
> Fällen auch viel sinnvoller, als in Echtzeit.

Ich zeige mal einen Bildausschnitt, welcher die Variablen und die 
USART2-Register anzeigt. Neben konstanten Werten wie der Sollfrequenz 
des µC und der Messzeit sehe ich die 'reg_ereignisse' pro Sekunde. Diese 
'reg_ereignisse' sind die Summe aus 'F1_mess_ereignisse', die die Anzahl 
der Perioden (0x50 = 80) eines 16 MHz Signals mit 200 kHz Abtastrate in 
der vorgegebenen Messzeit von 1000 = 1 s ist.
'F1_ergebnis' mit rund 16 MHz ist ebenfalls zu sehen, sodaß kein 
'printf()' notwendig ist.

Wenn ich dieses Programm stoppe, kann ich die angezeigten Werte in die 
Tonne treten ;-)

Kommen wir zum Register 'USART2_RDR' dessen Inhalt angezeigt wird. Das 
laufende Programm liest RDR per ISR ein und wertet den betreffenden 
Befehl aus. Man sieht also welches Zeichen zuletzt angekommen ist.

temp schrieb:
> Mir würde aber auch nicht einfallen das zu nutzen. Da sind dann
> zu viele Fallstricke zu beachten. z.B. bei einem UART->DR Register. Da
> würde dann der Debugger 2 mal pro Sekunde die Daten weg schnappen.

Es wird nichts weggeschnappt! Der Befehl wird wie erwartet empfangen und 
ausgeführt. Falls die Baurate nicht stimmen sollte, könnte man BRR im 
laufenden Programm einfach anpassen. Oder man schreibt einen Wert in 
TDR, der dann zusätzlich ausgegeben wird.
Für meine Arbeit ist das alles mehr als praktisch!

m.n. schrieb:
> Kommen wir zum Register 'USART2_RDR' dessen Inhalt angezeigt wird. Das
> laufende Programm liest RDR per ISR ein und wertet den betreffenden
> Befehl aus. Man sieht also welches Zeichen zuletzt angekommen ist.

Bist du dir dessen auch wirklich 100%ig sicher? Aus Sicht der Peripherie 
wird das Register gelesen und mit dem Lesen ändern sich Zustände in der 
Peripherie. Wenn also das Aktualisieren der Anzeige im Debugger keine 
Auswirkung haben soll, muss es dafür in allen Peripherieeinheiten 
Sonderlocken geben. Ich will nicht behaupten dass das nicht so ist. Im 
Gegenteil es ist eine spannende Frage wie das gemacht wird und ob das 
immer und überall so ist.

temp schrieb:
> Bist du dir dessen auch wirklich 100%ig sicher? Aus Sicht der Peripherie
> wird das Register gelesen und mit dem Lesen ändern sich Zustände in der
> Peripherie.

Es muß garnicht zu 100% sicher sein. Für flüssiges Auslesen arbeite ich 
normalerweise mit einer Auffrischrate von 10/s. Das heißt für RDR, es 
werden nur 10 Zugriffe/s durchgeführt. Probleme kann es nur dann geben, 
wenn innerhalb der gleichen Nanosekunden ein Zugriff stattfindet, damit 
das zugehörige RDR-Flag gelöscht und dadurch ein Aufruf der ISR 
verhindert wird.
Da würde ich die Fehlerrate auf > 10e-4 einschätzen, was zu spontanen 
Fehler führen könnte, wenn man den ganzen Tag darauf wartet ;-)

ABER: regulär fasse ich RDR natürlich garnicht an, sondern nur für den 
Fall, daß die USART scheinbar nicht funktioniert. Dann kann man sehen, 
daß das Zeichen zumindest richtig eingetroffen ist. Vielleicht ist das 
Überlaufflag schon gesetzt und hat man ISR-Enable vergessen, setzt es 
manuell und schwupps wird auch die ISR angesprungen: Debugging halt!

Weitere interessante Register für mich sind die Input-Capture-Register, 
die ich durchaus im Dauerlauf anzeigen lasse. Hier ist mir nie ein 
verlorenes Ereignis aufgefallen. Und wie gesagt, wäre das nur eine 
Störung beim Debugging und nicht im realen Betrieb des Programmes.

Es gibt natürlich geniale Programmierer, die das alles nicht brauchen. 
Aber auch die werden scheitern, wenn der µC nicht das macht, was er 
soll. In den Errata stehen nicht alle Fehlfunktionen und man staunt 
(kaum noch), wenn ein korrektes Programm nicht richtig ausgeführt wird. 
Um das zu finden hilft dann kein "eben mal hier etwas Eintippen". In der 
letzten Zeit habe ich viel mit dem G431 herumgemacht. Dessen Timer sind 
gegenüber anderen STM32 recht "auffällig". Ich hänge das nicht an die 
große Glocke, hoffe natürlich, daß ST die Fehler einmal behebt. Aber bei 
einem aktuellen Problem muß eine aktuelle Lösung her. Bei Allem, was in 
Echtzeit laufen muß, hat mir diese "Live Watch" Funktion schon sehr 
geholfen und immens viel Zeit gespart.

m.n. schrieb:
> Es wird nichts weggeschnappt!

m.n. schrieb:
> Da würde ich die Fehlerrate auf > 10e-4 einschätzen, was zu spontanen
> Fehler führen könnte, wenn man den ganzen Tag darauf wartet ;-)

Dann kannst du erste Aussage aber so nicht stehen lassen. Es passiert 
zwar in der Regel nicht, aber die Möglichkeit besteht!

m.n. schrieb:
> Weitere interessante Register für mich sind die Input-Capture-Register

Bei Registern die beim Lesen keine Rückwirkung auf den Status der 
Peripherie
haben, besteht das Problem nicht. Ich weiß jetzt aber nicht ob das bei 
den Input-Capture-Register der Fall ist.

Stefan ⛄ F. schrieb:
> Irgendwann werde ich das wohl auch mal auf µC nutzen wollen. Bisher
> brauchte ich es nicht. Allerdings wusste ich auch nichts davon. Komme
> mir gerade ein bisschen altmodisch vor.

Ich habe 15 Jahre lang 8051er und AM186 nur mit simplem ROM-Monitor und 
Reset-Taste programmiert.
Dabei sind Steuerungen unter anderem für Produktionsstrassen, Hochöfen 
und Einspritzanlagen für Verbrennungsmotoren entstanden.
Erst in der darauf folgenden Stelle habe ich das erste mal überhaupt 
einen "Debugger" in der Hand gehabt. Habe immer gedacht, ich wäre der 
Debugger...

Da muss man sich nicht altmodisch vorkommen. Wenn uart_putbyte auf einem 
AVR und PRINT in QBasic ausreichen, dann nimmt man halt das ;)

Vorallem der 186 ist ein ekliges Biest, da hätte mir ein Live-Debugger 
viele Stunden Rätseln ersparen können.
Die 8051-"Toolchain" war die kompletten 15 Jahre über ein Assembler von 
Intel, der lange vor meiner Zeit schon outdated war und ein paar 
vorgefertigte "stdio"-Funktionen.


"Anekdote": Als ich das erste mal mit einer komplett diskreten H-Brücke 
zu tun hatte und selbst auf die Schaltmomente+Überlappen achten musste, 
hatte ich dafür einen 80C515 mit externem ROM/Flash und nicht ein 
einziges mal gingen die Transistoren hoch.
Vor ein paar Monaten habe ich mir ein STM32 Board wegen der PWM mit 
Dead-Time-Insertion geholt und gleich zweimal direkt hintereinander 
Rauch aufsteigen lassen.
Damals war klar, ich muss das jetzt verstehen und umsetzen. Vor ein paar 
Monaten war das nicht mehr so klar, weil ich mir Arbeit ersparen wollte 
und das den Chip machen lassen wollte.

temp schrieb:
> Dann kannst du erste Aussage aber so nicht stehen lassen. Es passiert
> zwar in der Regel nicht, aber die Möglichkeit besteht!

Willst Du mich nicht verstehen? Es ist doch völlig wurscht, wenn ich 
damit einem Programmfehler auf die Schliche kommen kann!

temp schrieb:
> Bei Registern die beim Lesen keine Rückwirkung auf den Status der
> Peripherie
> haben, besteht das Problem nicht. Ich weiß jetzt aber nicht ob das bei
> den Input-Capture-Register der Fall ist.

Es ist der Fall, und ich dachte, Du weißt das.


Bauform B. schrieb:
> Das geht alles in Hardware. Einen Debugger, der das nicht nutzt, sollte
> man garnicht benutzen.

Das ist klar, aber die Debugger-Software muß es auch untertützen.

> Im Extremfall braucht man garkeinen Debugger,

Aber wenn es die IDE anbietet, nutzt man das natürlich. Als Anwender ist 
es mir derzeit egal, wie das implementiert ist.

Bauform B. schrieb:
> Im Extremfall braucht man garkeinen Debugger,
> weil die Watchpoint-Hardware auch einen ganz normalen Interrupt mit
> eigenem Vektor auslösen kann.

Auf oben erwähntem am186 sollte ich mal eine Art "Memory Watchdog" 
bauen. Die (mir unbekannte) Software, die darauf lief, schreibt niemals 
in einem bestimmten Speicherbereich. Wenn doch, liegt was im Argen 
("Log-File").
Nach mehreren Tagen disassembler und nicht vorhandener 
Dokumentation/Code wurde das meinem Chef zu bunt.
Der hat dann kurzerhand bestimmt, dass ich nur die Adresse für das 
Log-File patch-bar mache und dann wurde ein RAM Chip auf Zwei 
aufgeteilt. Das Log-File kam in den Zweiten und die Handshake-Leitungen 
von diesem triggerten irgend eine Art von Flag (FlipFlop oder einen 
Interrupt auf einem anderen Chip, ich weiss es nicht mehr genau....)

Es gibt mindestens so viele Wege, zu debugge, wie es Fehler geben kann. 
Der Debugger kann aber auch zum Teil der Anwendung werden. Die Grenzen 
verwischen sehr leicht...

Um mal wieder über den Tellerrand zu sehen, hatte ich in den letzten 
Tagen mit STM32CubeIDE, Keil µVision und Segger Embedded Studio für ARM 
herumgespielt. Dabei habe ich versucht, ein existierendes Projekt zu 
importieren und zum Laufen zu bekommen. Dazu habe ich keine Manuals 
gelesen, sondern versucht, intuitiv die richtigen Einstellungen zu 
finden.

Bei STM und Keil gelang es mir nur, über CubeMX ein Projekt erzeugen zu 
lassen und dann die vorhandenen .c und .h Dateien hinzu zu kopieren.
STM32CubeIDE ist HAL-verseucht; damit bin ich nicht weit gekommen und 
wollte es auch garnicht mehr.

Bei Keil µVision (MDK-ARM) war mir die Projektstruktur nicht so richtig 
klar, um die vorhandenen Quelldateien abzulegen. Mit etwas Probieren ist 
es mir gelungen, das Projekt zu kompilieren und zu linken. Das Programm 
war aber nicht richtig lauffähig. Ich habe dann irgendwann den Versuch 
beendet.

Was bei Keil positiv aufgefallen ist, daß über 'View->Watch Windows' die 
Variablen sichtbar und veränderbar sind und über 'View-> System Viewer' 
die Peripherie. Update-Rate und Feineinstellungen dazu habe ich nicht 
gefunden.

Segger Embedded Studio bietet als einzige dieser IDEs den Import von 
Eclipse, IAR EWARM und Keil MDK Projekten an. Das hat auch gut 
funktioniert. Beim Compilieren/Linken gab es wie bei STM und Keil 
Gemecker über die selbstdefinierte 'putchar()'. Und zwar wollte SES 
immer die Funktion aus der eigenen Lib dazupacken. Gut, zur 
Problemlösung habe ich meine Funktion umbenannt.
Soweit, so gut! Zum Debuggen geht kein ST-Link; es muß j-Link verwendet 
werden. Das Programm lief auch an, landete aber recht schnell im 
HardFault Handler.
Ohne in die Tiefe zu gehen, habe ich ein paar Sachen probiert, aber nach 
kurzer Zeit aufgegeben. Wie gesagt, unter IAR läuft alles problemlos.
Aus einem früheren Versuch weiß ich jedoch, daß der Import von 
IAR->Segger ein lauffähiges Programm zur Folge hatte.

Mein erster, kurzer Eindruck:
STM mit seinem HAL-verseuchtem Zeug mag ich nicht. Man ist damit auch 
voll auf STM32 festgebunden.

Bei Keil sind die Debugging-Funktionen wohl recht gut. Allerdings ist 
die Demoversion auf 32 KB begrenzt und liefert keine .lst-Dateien der 
eigenen Programme. Ohne ein Grundgerüst von CubeMX sieht man bei den 
Einstellmöglichkeiten vor lauter Bäumen den Wald nicht.

Segger bietet den direkten Import von Projekten anderer IDEs. Es macht 
einen schlanken, effizienten Eindruck. Scheint sehr schnell zu sein und 
gefällt mir am besten. Was mit Debugging los ist, hat sich mir in der 
kurzen Testzeit nicht voll erschlossen. Macht braucht auf jeden Fall 
einen j-Link. Mit etwas Zeit würde ich mein Testprogramm schon zum 
Laufen bringen.
Einem Anfänger würde ich die Demoversion von IAR EWARM nahelegen. Das 
Debugging mit der IDE ist da gut. Wegen einiger offensichtlicher Mängel 
(wurden hier schon an anderer Stelle angesprochen) würde ich dafür aber 
kein Geld ausgeben, sondern bei wachsender Programm größe eher zu Segger 
oder Keil tendieren. Ich weiß aber nicht, was die kosten. Mit 
(kostenfreier) Eclipse bin ich nie warm geworden.

Meine Meinung.

zum Thema besserer Support :
vor ein paar Jahren bin ich auf der Hitex Cortex-M Schulung gewesen.
Tatsächlich 100% der Teilnehmer haben STM32 verwendet.
Meine Firma hat ein paar Keil Standard Floating Lizenzen gekauft, Chef 
wollte das so.
Wir waren also frisch in der Wartung, da habe ich gedacht, ich frag mal 
ne Frage beim kostenpflichtigen Support.
Bis dahin hatte ich mit der Cortex-M0 Version von ST/Keil, die kostenlos 
ist/war einen guten Eindruck von Keil gehabt. (Dito für eine IAR 
Volllizenz Cortex-M ):
Aber der Support durch Hitex für Keil war keinen Cent wert.
Das Projekt habe ich mit CubeMX aufgesetzt und für Keil exportiert.
Es hat irgendwas mit der Peripheriekonfiguration nicht funktioniert.
Antwort von Support : Dann konfigurieren sie den uC nicht mit CubeMX 
sondern benutzen die Funktionen von Keil Professional. Mein Einwand, wir 
haben ja nur die Standard Version, wurde geflissendlich übergangen.
Bin dann schnell zu SW4STM32 gewechselt, STM32CubeIDE gabs noch nicht.
Vielleicht ist man heute besser im Support, die kostenlosen Tools von ST 
sind aber so gut das ich keinen Mehrwert zu Keil/IAR mehr sehe.
Ein Vertriebler von IAR hat das auch noch mal bestätigt. Ein Tutorial 
von ST war für IAR, Testlizenz inclusive. Anschliessend wollte natürlich 
der Vertrieb von IAR mir eine Lizenz verkaufen. Auf meine Antwort, ich 
nutze SW4STM32 und sehe auf Grund meiner Erfahrungen mit Keil/IAR keinen 
Mehrwert in kostenpflichtige Compiler/IDEs war die Antwort : Das hören 
wir immer öfter, die Verkaufszahlen( bei IAR) gehen seit Jahren nur noch 
runter.

Das bessere Debugging mit Keil/IAR hat sich mit CubeIDE eigendlich auch 
erledigt:
https://www.youtube.com/watch?v=4wT9NhlcWP4&list=PLnMKNibPkDnEDEsV7IBXNvg7oNn3MfRd6

> m.n. schrieb :

>Dazu habe ich keine Manuals gelesen, sondern versucht,
>intuitiv die  richtigen Einstellungen zu finden.
Als ob solche Tools intuitiv zu bedienen sind ...

>STM mit seinem HAL-verseuchtem Zeug mag ich nicht.
Handbuch lesen hilft.

>Man ist damit auch voll auf STM32 festgebunden.
ST bietet keine kostenlose Tools für fremde uC ? Pfui aber auch !

>die Demoversion (von Keil) auf 32 KB begrenzt
Wenn Cortex-M0 für STM32 reicht sind es 256kB
https://www2.keil.com/stmicroelectronics-stm32/mdk

drm schrieb:
>>Dazu habe ich keine Manuals gelesen, sondern versucht,
>>intuitiv die  richtigen Einstellungen zu finden.
> Als ob solche Tools intuitiv zu bedienen sind ...

Wenn man weiß, was man erreichen will und wie das normalerweise abläuft, 
sollte man das Grobe auch ohne Handbuch schaffen. Das ist mir ja auch 
soweit 'gelungen'.
Sofern die Inzidenzzahlen weiter sinken, werde ich hier nicht tagelang 
diverse Handbücher durcharbeiten.


>>STM mit seinem HAL-verseuchtem Zeug mag ich nicht.
> Handbuch lesen hilft.

Geschmäcker sind verschieden. Womöglich mag ich es anschließend noch 
weniger.

Til S. schrieb:
>> Aber mit Segger und "Live Watch" hast Du wohl keine Information?
> Das funktioniert einfach. Du kannst im Watch Fenster die Update Rate
> auswählen, z.B. zweimal die Sekunde.

Zweimal pro Sekunde ist schon die schnellste Einstellung zur Anzeige von 
Variablen; soweit waren wir schon. Mir ist das alles noch zu langsam.
Wie werden denn Register wie GPIO->IDR angewählt und wie verändert 
während das Programm läuft? Das war noch offen.