Echzeitbetrieb debuggen

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

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

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.

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

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