Forum: Mikrocontroller und Digitale Elektronik Keil µVision vs. STM32CubeIDE


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 ReinerZufall24 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,
ich programmiere derzeit (beruflich) mit der STM32CubeIDE.
Nun habe ich öfters den Tipp bekommen, auf Keil µVision umzusteigen.

Blöderweise konnte mir keiner genau sagen was den bei µVision besser ist 
als bei CubeIDE - außer das µV einen anderen Compiler nutz und die 
Programme möglicherweise "schneller" werden.

Gibt's von eurer Seite her da noch weiter Vorteile die µVision (oder 
Nachteile von STM32CubeIDE) bietet?


Grüße,
Reiner

von Johannes S. (jojos)


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

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


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

: Bearbeitet durch User
von Random .. (thorstendb) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Vergleiche doch mal die Debug Features. Nur weil es "altbacken" 
ausschaut ...
Ich arbeite in meinen Projekten meisstens mit ULINK pro und viel mit den 
grafischen Analysetools der IDE.

von dunky (Gast)


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

von Alex -. (alex796)


Bewertung
0 lesenswert
nicht lesenswert
dunky schrieb:
> Der Debugger ist diesem ganzen Eclipse Krempel haushoch überlegen

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

Ich arbeite mit STM32CubeIDE und kann mit dem Debugger single step 
Aktionen durchführen, habe eine Übersicht über die einzelnen BITs im 
Register, sehe welches gesetzt und welches gelöscht ist etc. und ich 
kann Breakpoints setzen.

Das hat mir bei meinen Programmen oft geholfen, zu sehen, wo das Problem 
liegt.

Im professionellen Bereich: Welche Debugfunktionen braucht/benutzt man 
darüber hinaus?

Vielen Dank,

von Roland E. (roland0815)


Bewertung
0 lesenswert
nicht lesenswert
Keil ist Teil von ARM bzw deren "Hausmarke". Das hat unter der 
abgestaubten Haube ein paar Vorteile.

von m.n. (Gast)


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

von temp (Gast)


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

von Stefan ⛄ F. (stefanus)


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

von Random .. (thorstendb) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
dass
> man das Programm anhalten kann, wenn eine bestimmte Variable beschrieben
> wird.

MDK-ARM (Keil):
CMD> BS WRITE var
Mit Variationen, READ/WRITE/READWRITE, sowie var=0x42 etc.

Setzt einen WATCH in der Cortex-M Debug Logik.

: Bearbeitet durch User
von m.n. (Gast)


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

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Random .. schrieb:
> Setzt einen WATCH in der Cortex-M Debug Logik.

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

von Random .. (thorstendb) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> sondern die Register mit ihren einzelen Bits/Bitgruppen.

MDK-ARM:
- SystemViewer: eine Art "Live Datenblatt", vgl. SVD/SVDConv
- ComponentViewer

von m.n. (Gast)


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

von Johannes S. (jojos)


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

: Bearbeitet durch User
von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Nun einer der Vorteile von Keil wirst du auch bemerken wenn du auf einen 
ARM umsteigst der nicht von ST kommt. Dann hilft Cube STM nicht mehr 
weiter.
Es ist richtig, dass die IDE etwas altmodisch ist. Ich finde das nicht 
so schlimm und der Debugger ist besser als alles was ich bisher gesehen 
habe.

Ich würde einfach mal die Eval Version installieren und damit 
rumspielen. Keil vergibt auch kostenlose Test Lizenzen die es erlauben 
für einige Zeit eine Vollversion zu testen. Nicht zu verachten ist auch 
die Middleware die Code für viele Anwendungen abdeckt z.B. USB, Ethernet 
usw.
Nachteil ist ganz klar der Preis. Dazu kommt dann noch eine 
Jahresgebühr. (ca 500??) Ohne diese bekommst du nach einem Jahr keine 
Updates mehr.

von temp (Gast)


Angehängte Dateien:

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

von Markus M. (mmvisual)


Bewertung
1 lesenswert
nicht lesenswert
Ich nutze gerne STM32CubeIDE, funktioniert für das was ich benötige gut 
genug.

Einziger Nachteil, so wie bei allen Eclipse basierten IDE's:
Das Projekt mit einer SVN Versionsverwaltung zu pflegen/sichern und mit 
mehreren Leuten zu arbeiten ist eine mittlere Katastrophe. Nur die IDE 
öffnen und wieder schließen ändert schon irgend welche Dateien. Und wenn 
man da nicht alle mit sichert ist hinterher das Projekt so korrupt und 
öffnet nicht mehr, das ist bei Eclipse echt ein Manko das nervt 
ungeheuerlich.
So lange man nur auf einem PC arbeitet funktioniert alles, wehe man hat 
2 PC's.

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.

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

Wenn ein Entwickler mit Keil die Dateien unter C:\blabla\ stehen hat und 
der andere bei D:\BlubBlub\ dann stört das den Keil nicht wirklich. 
Hingegen Eclipse schon.
Da sollten die Eclipse Leute mal bitte endlich Ordnung schaffen. Dieser 
Chaos ist schon seit immer in Eclipse drin.

Eclipse hat natürlich auch Stärken:
So vom Editor her und deren Möglichkeiten ist das so ziemlich die beste 
IDE die ich je gesehen habe und daher nutze ich die auch gerne.
Man kann leider nicht alles haben, gescheite Dateistruktur und guten 
Editor schließen sich wohl gegenseitig aus.

Mit dem Keil gibt es eine freie Lizenz für alle STM32x0xx µC für die 
Voll-Version: http://www2.keil.com/stmicroelectronics-stm32/mdk

von Stefan ⛄ F. (stefanus)


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

von m.n. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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" ;-)

von temp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Segger entwickelt seine Software auf der Basis von Crossworks. Der 
Screenshot ist von der Segger IDE.

von m.n. (Gast)


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

von temp (Gast)


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

von Ben S. (bensch123)


Bewertung
-1 lesenswert
nicht lesenswert
Manche stehen echt drauf, sich das Leben schwer zu machen. Masochismus?

Stefan ⛄ F. schrieb:
> Bei ST bekomme ich als Hobbybastler keine Antworten auf meine Anfragen.

Ich schon.

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.

m.n. schrieb:
> 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.

Kann man sich beim Debuggen alles anzeigen lassen.

Thomas Z. schrieb:
> Nachteil ist ganz klar der Preis. Dazu kommt dann noch eine
> Jahresgebühr. (ca 500??) Ohne diese bekommst du nach einem Jahr keine
> Updates mehr.

Für das, was 99,9% der Hobby und auch Profianwender machen, reicht die 
kostenlose Studio Variante vollkommen aus.

von Markus M. (mmvisual)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Die Live Ansicht geht auch bei der STM32CubeIde, nicht nur bei Keil.

In diesem Beispiel kann ich den "tMainZyk" Zähler beobachten, der jede 
Sekunde aktualisiert wird und mir zeigt dass der Main-Loop nicht 
"hängt". Von da her ist so eine Live Ansicht nicht schlecht.

: Bearbeitet durch User
von temp (Gast)


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

von m.n. (Gast)


Angehängte Dateien:

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

von Alex -. (alex796)


Bewertung
0 lesenswert
nicht lesenswert
Markus M. schrieb:
> Die Live Ansicht geht auch bei der STM32CubeIde, nicht nur bei Keil.

Hi,
Welche Einstellung hast du vorgenommen für die Live Aktualisierung?

Danke,

von Markus M. (mmvisual)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Alex -. schrieb:
> Welche Einstellung hast du vorgenommen für die Live Aktualisierung?

Im Debug kann man die View aktivieren, siehe Bild.

Das sollte im CDT mit dabei sein. Also beim GDB Hardware Debugging 
Plugin, nicht nur bei der STM32CubeIde

: Bearbeitet durch User
von temp (Gast)


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

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Sonderlocken geben

Beim Keil gibt es diese Sonderlocken, beim STM32CubeIde weiß ich es 
gerade nicht. Beim Keil wird das RDR Register online nicht gelesen.

: Bearbeitet durch User
von m.n. (Gast)


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

von temp (Gast)


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

von nigg (Gast)


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

von Random .. (thorstendb) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dieses hier viel gelobte "Live Watch" scheint nichts anderes als ein 
"Periodic Update while running" zu sein. Da wird ein Cortex-M Feature 
genutzt, den Speicher zu lesen, während das Target läuft. Gibts also 
schon seit ~15 Jahren :-)
Im MDK-ARM zu finden in allen Fenstern, welche auf "globalen" Speicher 
zugreifen, also globals im Watch Window, das Memory Window, der System 
Analyzer (Peripheral Dialoge).
Neben diesen Features habe ich bei meinen Spielereien die grafischen 
Analysetools lieben gelernt, mit welchen sich - während das Target läuft 
- recht einfach Spikes und Unzulänglichkeiten im System oder den Threads 
finden lassen. So dauerte ein Timer-Interrupt in seltenen Fällen ein 
kleines bischen zu lange, was mir bei hoher (grenzwertiger) 
Geschwindigkeit die SPI Pakete ineinanderschob (ca. 120kHz mal 8 Pakete 
à 16 Bit). Grafisch sieht man das dann.

Bevor ich bei den üblen Problemen mit Trace anfange, was dann oft die 
sprichwörtliche Nadel im Heuhaufen ist (besonders wenn eine 
Synchronisation z.B. mit einem PC über Ethernet im Spiel ist), 
instrumentiere ich gerne meinen Code mit globalen Variablen, und schaue 
mir diese grafisch parallel zu den Ausführungszeiten der Threads und 
Interrupts an.

Wäre auch ein Anwendungsfall für die H-Brücke einen Post höher, da 
sollte man die CPU auch nicht mittendrin anhalten :-)

: Bearbeitet durch User
von Bauform B. (bauformb)


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

Beim Cortex-M (jedenfalls beim M4) sollte der Debugger garnicht dauernd 
lesen, man setzt einen Watchpoint. Der triggert, wenn die UART-ISR das 
RDR liest. Der Debugger liest es dann irgendwann nochmal (ok, bevor das 
nächste Zeichen kommt), aber der zweite Zugriff ändert die Flags nicht 
mehr. Die Reihenfolge ist fest und richtig.

Das geht alles in Hardware. Einen Debugger, der das nicht nutzt, sollte 
man garnicht benutzen. Im Extremfall braucht man garkeinen Debugger, 
weil die Watchpoint-Hardware auch einen ganz normalen Interrupt mit 
eigenem Vektor auslösen kann.

von m.n. (Gast)


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

von nigg (Gast)


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

von Random .. (thorstendb) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Das geht alles in Hardware. Einen Debugger, der das nicht nutzt, sollte
> man garnicht benutzen. Im Extremfall braucht man garkeinen Debugger,
> weil die Watchpoint-Hardware auch einen ganz normalen Interrupt mit
> eigenem Vektor auslösen kann.

Einen Debugger brauchst du trotzdem, der beim Breakpoint aktiv wird. Du 
kannst natürlich auch einen Interrupt zum Schreiben eines Log auf SD 
Karte verwenden, der dir aber wieder andere Sachen blockiert :-)

Du hast einige Möglichkeiten beim Cortex-M, die Debug Hardware zu 
nutzen:
- DHCSR, DEMCR: Vector catch auf Faults, spart Breakpoints auf die Fault 
Handler Hard, Usage, usw...
- Hardware (Adress-)Breakpoints:
  -- 8 Stück
- Memory read/write:
  -- samplen von Speicherstellen / Bereichen (MemWin, Variablen)
  -- ändern von Speicherstellen
  -- auch zur Laufzeit
- DWT Data watches:
  -- als conditional Breakpoints, wenn auf eine Speicherstelle 
zugegriffen wird (eine von 4 Units), oder mit zusätzlichem Vergleich auf 
einen Wert (2 Units)
  -- als ITM write, wo der Wert der Speicherstelle per Trace Channel an 
den Debugger geschickt wird (SWO oder 1-4pin TracePort), interessant für 
grafische Analyse. Max. 4 x 32Bit gleichzeitig.
- ITM:
  -- instrumentierung von Code, meisst printf auf Ch.0 (CMSIS-Standard), 
einige RTOS auf Ch. 31
  -- 32 serielle Kanäle
  -- PC sampling ("statistisches Instructiontrace")
  -- Ausgabe über SWO / TracePort
- ETM Trace:
  -- Nadel im Heuhaufen :-)
  -- Ausgabe über TracePort

Diese Features bietet die Cortex-M Architektur. Die Einzelfeatures 
werden sicherlich von allen Tools unterstützt. Was sie aber draus 
machen, und in welcher Weise diese Kanäle genutzt und miteinander zu 
einem Gesamtbild verbunden werden, ist dann doch sehr unterschiedlich.

von Random .. (thorstendb) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Zum Lesen/Anzeigen von Peripherals werden oft die Daten aus den 
CMSIS-SVD files verwendet, um eine Art Live Datenblatt zu erstellen. 
D.h., die Peripherie-Register werden gelesen, und je nach 
Informationsdichte im SVD file textuell aufbereitet dargestellt, bis hin 
zu Dropdown Boxen mit den verschiedenen Möglichkeiten der 
Register-Fields.
Für Spezialfall eines Registers, bei welchen ein READ eine Aktion in dem 
Peripheral auslöst, gibt es einen extra Eintrag im SVD, der den Zugriff 
auf dieses Register dann auslässt.

von m.n. (Gast)


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

von drm (Gast)


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

von drm (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> 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

von m.n. (Gast)


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

von Til S. (Firma: SEGGER) (til_s)


Bewertung
1 lesenswert
nicht lesenswert
m.n. schrieb:
> 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.

Ne, mit Embitz haben wir nichts zu tun.
Ja, SEGGER Embedded Studio basierte ursprünglich mal auf Rowley 
CrossWorks. Viele Sachen sind daher ähnlich.

> 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.

von m.n. (Gast)


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

von Til S. (Firma: SEGGER) (til_s)


Bewertung
1 lesenswert
nicht lesenswert
Das hatte ich eben in dem anderen Thread beantwortet, 
Beitrag "Segger Embedded Studio und Watch Fenster"

Ansonsten, wie gesagt, gerne bei uns im Forum melden. Da antworten dann 
auch die Kollegen, die mehr Ahnung von Embedded Studio haben ;-). Vor 
allem auch schneller weil ich hier nicht so oft rein schaue.

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]
  • [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.