Hallo liebes Forum, das ganze mag für einige hier naiv klingen, aber ich will es trotzdem fragen. Habe schon etwas Erfahrung mit verschiedenen AVRs und dem Dragonboard. Bei den AVRs ist es ja ganz einfach möglich, den Quellcode vom PC aus, Schritt für Schritt durch zu debuggen. Ich stelle mir seit einiger Zeit nun die Frage, ob es auch möglich ist in einen Echtzeitbetriebssytem Step für Step zu debuggen. Angenommen auf nen ARM9 o.ä. läuft z.B. ein RTOS und in diesem meine Applikation. Das ganze ist über einen Emulator mit dem PC verbunden. Ich kenne nun die Aussage, dass dies nicht ohne weiteres möglich wäre. Welche Probleme oder Schwierigkeiten gibt’s es denn dabei? Oder klappt dies bei modernen Entwicklungsumgebungen ganz einfach? Danke für eure Antworten Xerfu
xerfu schrieb: > Ich stelle mir seit einiger Zeit nun die Frage, ob es auch möglich ist > in einen Echtzeitbetriebssytem Step für Step zu debuggen. Ja, das ist naiv - dein Gehirn ist einfach um einen Faktor von einigen Millionen zu langsam dafür. Wenn du z.B. eine Lageregelung hast, die jede ms Position und Geschwindigkeit prüft und den Motor nachregelt, funktioniert einfach nichts mehr, wenn du den Prozessor auch nur kurz anhältst. Es gibt die Möglichkeit, das System ungehindert laufen zu lassen und dabei alles aufzuzeichnen (Logikanalysator), aber dann musst du die aufzuzeichnenden Daten aufwendig filtern um z.B. nur eine bestimmte Funktion in ihrem Ablauf zu betrachten, oder du erhältst irrsinnige Datenmengen, in denen du nichts mehr findest. Bei einem heutigen Prozessor kommen leicht 100 MB pro Sekunde zusammen. Ausserdem brauchst du dazu spezielle Hardware, da bei µControllern Adress- und Datenleitungen meistens gar nicht nach aussen geführt sind. Gruss Reinhard
mit dem InstructionTrace und Keil UlinkPro geht das ohne weiteres beim ARM Cortex, auch ohne was anhalten zu müssen
@Reinhard Ja das mit der Regelung leuchtet mir ein. Hier wird man wohl nicht drum rum kommen die Applikation frei laufen zu lassen und nur bestimmte Werte z.B. über nen Hyperterm zu bekommen. Aber ich stelle mir nun vor z.B. ein Filesystem zu entwickeln und dieses muss ich doch dann auch Schritt für Schritt durchsteppen können, oder? Wie macht man so was in der Praxis. Da kann ich doch ned einfach drauflos Proggen und dann laufen lassen und wenn ein File auf der Karte ist, sagen dass alles prima läuft. Das wäre doch wie Blindflug. Stichwort: Simulation ist da wohl das Allheilmittel, oder? @TTL Grundsätzlich scheint es ja zu funktionieren mit solch einen Emulator. Nur was passiert dann bei ner Lageregelung ;) Danke für eure Antworten. Ich glaube da muss ich mich noch weng mit beschäftigen. Scheint ja sehr spannend zu sein. xerfu
@ xerfu (Gast) >z.B. über nen Hyperterm zu bekommen. Aber ich stelle mir nun vor z.B. >ein Filesystem zu entwickeln Da gibt es keine oder kaum Echtzeitbedingungen. Das ist reine statische Logik, einfach. > und dieses muss ich doch dann auch Schritt >für Schritt durchsteppen können, oder? Teilweise. > Wie macht man so was in der >Praxis. Da kann ich doch ned einfach drauflos Proggen und dann laufen >lassen und wenn ein File auf der Karte ist, sagen dass alles prima >läuft. Sicher nicht. >Simulation ist da wohl das Allheilmittel, oder? Nein. Das schaffen eines (voll)automatischen Test. Dieser prüft, ob die Daten/Files/Ergebniss so sind wie erwartet. Simulation ist nur die Vorstufe, der Nachweis der Funktion muss in der Realität erfolgen.
Hallo, ja ein Echtzeitdebugging ist so natürlich nicht möglich. Man sollte sich vorher überlegen, ob man manche Dinge nicht auch langsamer ablaufen lassen kann, um jedenfalls den Code auf Fehler überprüfen kann. Die zweite Variante ist man ließt nur die Variablen aus, bei laufendem System. Das geht ohne Probleme.(zumindest bei JTAG) und bei ST gibts da sogar ein Tool für die Cortex M3 Familie. Ich habe auch schon so manche Entwicklung auf einem AVR (Xmega) gemacht, wo ich das System nicht anhalten konnte. Besonders wenn PWM Motoransteuerungen dran waren, die bei einem Breakpoint dann sich etwas gefählich verhalten haben. Man muss halt einen gesonderten Protopypenaufbau machen mit etwas geänderter Hardware. Unter umständen muss man seine Software zum Start etwas anders aufbauen, damit sie Debug freundlicher bleibt. Oder gewisse zusätliche kommunikationen einrichten wie RS232 oder USB um Daten zum PC weiterleiten. Um ein Filesystem zu entwicklen sehe ich diese Probleme aber nicht, weil keine zeitkritische Elemente enthalten sind. Im Grunde wird es auf Sektor lesen und schreiben beschränkt. Gruß Sascha
Angehängte Dateien:
-
LA_ILDA_Testpic.png
17 KB
Das Bild im Anhang ist aus meinem aktuellen Projekt, man sieht hier das ILDA 12/30k Laser Testbild in X, Y und Intensity auf dem Logic Analyzer im µVision, mit ULINK pro und Cortex-M3, live während der Ausgabe auf die Laser / Galvos. Was ist das? http://www.mylaserpage.de/DasILDATestbild.html
Ich bin mir gerade nicht ganz sicher, ob ich Dein Problem richtig verstehe, aber vielleicht hilft Dir das weiter: Angenommen, Du hast etwas, das in Echtzeit laufen muß wie z.B. einen Regler. Und Du hast irgendwo einen Bug, aufgrund dessen der Regler nicht immer so tut, was Du erwartest. Dann kannst Du folgendermaßen vorgehen: Du baust an bestimmten Schlüsselpositionen Abfragen ein, ob die eingehenden Daten plausibel sind, so in der Art wie:
1 | temp_s16 = GetTemperature(); |
2 | if ((temp_s16 >= 10) and (temp_s16 <= 50)) |
3 | {
|
4 | // Das ist in meiner Anwendung der erlaubte Wertebereich
|
5 | }
|
6 | else
|
7 | {
|
8 | // Das darf bei korrektem Programmablauf nicht vorkommen
|
9 | // Hier Breakpoint setzen
|
10 | }
|
Du setzt in den else-Zweig einen Breakpoint und wenn der Debugger auf den Breakpoint läuft, schaust Du Dir an: Was ist passiert, damit dieser unerlaubte Fall eintreten ist? temp_s16 außerhalb des erlaubten Bereiches! Wie kam es dazu? GetTemperature() hat Mist geliefert! Wie kam das dazu? Der ADC hat Mist gemessen! Wie kam das dazu? usw. Hierbei hilft es enorm, wenn Du Dir zu Debugzwecken bestimmte Schlüsseldaten in statischen Variablen merkst, so daß Du diese Daten greifbar hast, wenn Du auf den Breakpoint läufst:
1 | static int16_t debug_AdcWertInGetTemperature; |
2 | int16_t GetTemperature(); |
3 | {
|
4 | int16_t t; |
5 | int16_t adcwert = ReadADC( 3 ); |
6 | debug_AdcWertInGetTemperature = adcwert; // Zum Debuggen merken! |
7 | t = (adcwert - 512) * 3; // irgendeine Umrechnung |
8 | return(t); |
9 | }
|
Nun hast Du den ADC-Wert verfügbar und kannst den Bug eingrenzen: Der ADC-Wert stimmt noch? Dann muß der Fehler in der Umrechnung liegen.
... oder visualisiert die Werte einfach mit dem LA, dann sieht man auch, ob z.B. periodisch Mist gemessen wird, und wie dieser ausschaut :-)
TTL schrieb: > mit dem InstructionTrace und Keil UlinkPro geht das ohne weiteres beim > ARM Cortex, auch ohne was anhalten zu müssen Instruction Trace (ETM) braucht man hier nicht, DWT (Data Watch & Trace) in Verbindung mit dem Logic Analyzer und ggf. etwas ITM (Instrumentation Trace Macrocell) printf reicht. Ich debugge die Echtzeitanforderungen (UDP_Send - UDP_Receive - Turnaround) mit dem ULINK pro und dem Logic Analyzer (zum Ausmessen der Zeiten), und schreibe selten auftretende Probleme (z.B. ETH Buffer full oder Package Error) auf dem ITM printf Channel raus.
Danke für die interessante Diskussion. Meine Frage war rein hypothetisch. Man sollte also bei Echtzeitbetrieb die Funktionen in zwei Kategorien einteilen. In Programmteile die Echtzeit erfordern (Regler, PWM Ansteuerung etc.) und in Programmteile die keine echte Echtzeit erfordern (Filesystem, LED blinken etc.). Die Funktionen die keine Echtzeit erfordern könnte man ganz normal mit nen Emulator debuggen (KÖNNTE). Dabei sollte keine Echtzeitfunktion aktiv sein. Somit kann das System auch angehalten werden. Die Funktionen die Echtzeit erfordern, könnte man zum Beispiel dann über GPIO-Pins (diese gehen dann z.B. in bestimmten Programmteilen auf high; Auswertung über Logicanalyzer) oder über die Ausgabe von Variablen über Terminal debuggen. Zusätzlich gibt’s da wohl noch spezial Emulatoren die Unmengen an Daten aufzeichnen können. Diese Daten werden nach einen Durchgang von hand ausgewertet. Kann man das so in etwa stehen lassen? xerfu
nicht wirklich. Der ULINK pro ist kein Emulator, sondern ein Debugger, der in CPU Echtzeit (z.B. 72MHz STM32, 84MHz SAM3X, 100MHz LPC1768) die Daten aus dem Chip ziehen kann. Das µVision auf dem PC verarbeitet diese und zeigt sie idR. (gängiger Core-i) mit <2sec Verzögerung an. Da wird nix emuliert. Das ist hier die Coresight-Debug-Architecture auf dem Cortex-M3, und die Auswertung geschieht in der IDE. Schreibst du deine Daten auf dem UART raus, bremst du dein Programm, da der UART nur rund 115kBaud kann. Schickst du hingegen den gleichen Datenstrom auf den ITM und logst den in ein File, so tust du das mit Core speed in meinem Beispiel. Beobachtest du per DWT Speicherstellen (= variablen), so geschieht dies ohne beeinflussung der Laufzeit deines Programms (im Gegensatz zu der Verwendung der ITM, wo deine Software gezielt (von dir programmiert) Daten rausschreibt). Lesenswert: Beitrag "Re: STM32F107 Keil Datenübertragung"
Random ... schrieb: > Da wird nix emuliert. Verwexelst du das mit Simulator? Das was du beschreibst hiess schon im vorigen Jahrhundert In-Circuit-Emulator und lief mit der Origimal-CPU plus einem Tracespeicher, und zwar in Echtzeit. Gruss Reinhard
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.