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
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.
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.
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
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,
Keil ist Teil von ARM bzw deren "Hausmarke". Das hat unter der abgestaubten Haube ein paar Vorteile.
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.
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
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.
m.n. schrieb: > sondern die Register mit ihren einzelen Bits/Bitgruppen. MDK-ARM: - SystemViewer: eine Art "Live Datenblatt", vgl. SVD/SVDConv - ComponentViewer
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.
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.
Angehängte Dateien:
-
watch.JPG
18 KB
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.
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
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.
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.
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
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.
Angehängte Dateien:
-
live-watch.PNG
260 KB
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!
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,
Angehängte Dateien:
-
Bild1.png
8,2 KB
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
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: > 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
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.
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
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.
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...
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.
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.
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.
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.
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.
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.
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.