Dragon vs. JTAGICE 3

[jschilli]

Also auf Änderungen einer Variable kannst Du schon einen Breakepoint unabhängig vom Code setzen.

Ja, die Echtzeitdebugger sind richtig teuer. Das bietet aber Atmel nicht an. Damit hatte ich früher mal in Verbindung mit NEC µC zu tun. Allerdings waren das richtig große Kisten mit einem speziellen "bounded out" µC drin. Für jede Variante musste man ein neues Board kaufen und für jedes Package ein neuen "Schnorchel"... Und dann hatte man, gerade bei den 100pinnern ständig mit Kontaktproblemen zu kämpfen... Also ich habe Echtzeitdebugging noch nicht vermisst, zumal das bei 100MHz+ Taktfrequenz gar nicht mehr sinnvoll ist... So schnell kannste eh nicht kuggen, wie die Dinger rennen...

Ich arbeite jetzt schon über 10 Jahre mit AVR's und den entsprechenden Debuggern und muss soweit feststellen, dass diese ziemlich gut arbeiten und ich konnte sogar einmal einen Defekt in einem AVR damit nachvollziehen... Die Tools sind eigentlich zuverlässig, wenn sie auch die ein oder andere Funktion nicht besitzen und auch die eine oder andere Macke haben...

Was für ein TI µC war das? MSP430?

Liebe Grüße,Jürgen

[DerPMO]

Wie genau setze ich so einen Breakpoint? Geht das auch mit dem Dragon?

Teilweise wäre es schon sinnvoll das ganze in Echzeit zu sehen, ich habe ein paar Probleme mit Funkempfang, wenn da das Programm mitten im Ablauf unterbreche kriege ich nicht das ganze Signal rein, wenn ich das ganze Signal abwarte und was schief läuft ist es verdammt schwer herauszufinden wo und was nicht geklappt hat.

Wenns kein echtzeit Debugging gibt, was kann denn dann der ICE3 gegenüber dem Dragon besser das der 4-5 Fache Preis gerechtfertigt ist?

Müsste ein MSP430 gewesen sein, weiß aber leider nicht was für ein Debugger da verwendet wurde. Hat mich aber enorm beeindruckt weil es schon einige Möglichkeiten eröffnen kann.

mfg PMO

[jschilli]

Nun, einen Breakepoint setzt Du im Atmel Studio 6 an eine Position im Code, in dessen Fokus sich Deine Variable befindet und dann kannst Du dem eine Condition, wie z.B. i==5 geben. Wenn dann i==5 dann hält die Ausführung an der stelle des Brakepoints.

Also einen Dragon nimmste nur einmal mit zum Kunden, dann kannste den wegschmeißen... Das JTAGICE 3 ist auf jeden Fall robuster für den Einsatz unterwegs bzw. für den professionellen Einsatz. Der Dragon eignet sich nur für den Labortisch und ist z.B. auch nicht als Fertigungsprogrammer von Atmel zugelassen. Und für den professionellen Einsatz sind 300 Euronen auch kein Thema... Und dann gibt es noch die Besonderheiten, wie PDI und Spannungsbereich herunter bis 1,5 V, die der Dragon nicht bietet...

Falls Du günstiger an einen JTAGICE 3 kommen möchtest, melde Dich einfach bei Atmel on Tour an... Da kriegste meist ein Demoboard und ein JTAGICE 3 samt Mittagessen für wesentlich weniger EUROs... Dazu gibt es dann auch jede Menge Infos und Handons...

Liebe Grüße,
Jürgen

[DerPMO]

Danke erst mal für die Antwort!

Aber das ist nicht ganz das was ich meine. Wenn ich eine Kondition irgendwo in den Code einbaue und dort einen Breakpoint setze, hab ich ja eine fixe Position an dem das Programm hält. Das die Variable sich ändert weiß ich ja, aber ich möchte wissen WO im Code die (globale) Variable verändert wird. Und das kann an sehr vielen Stellen passieren.

Step-by-Step ist auch keine Alternative, da, wie gesagt, einige der Funktionen sehr Zeitkritisch sind und jede Pause die Funktion zu nichte macht.

Deiner Beschreibung entnehme ich auch, das ich mir den ICE sparen kann, hat für mich keinen zusätzlichen Nutzen ;)

thx anyway, spare ich zumindest Geld wenn schon nicht Zeit

[jschilli]

Ich dachte da eher an eine zentrale Position für den Breakepoint, wie z.B. der Scheduler von Deinem RTOS, der immer durchlaufen wird. Damit erreichst Du eine globale Überwachung einer Variable und kannst anhand des aufrufenden Thread zurückverfolgen, wo die Variable zuletzt geändert wurde... Was damit natürlich nicht geht, ist, wenn Du die Variable zusätzlich im Interrupt manipulierst... Das sollte aber eigentlich vermieden werden und möglichst über das Messaging vom RTOS abgewickelt werden...

Falls Du kein RTOS verwendest, dann hast Du bestimmt eine Endlosschleife oder ähnliches, in dem Du den Breakepoint setzen könntest...

Was für einen Funk hast Du denn in Deiner Applikation? ISM 433MHZ oder 868MHz oder irgendwas wie Bluetooth, Z-Wave oder ähnliches?

Liebe Grüße,
Jürgen

[DerPMO]

Ich hab eine Statemachine, also while schleife die immer wieder durchlaufen wird. (Ich nehm an RTOS ist was anderes, da kenn ich mich aber nicht so gut aus, hast du da vlt. einen Link zu was Vernünftigem mit Atmel Bezug? Wiki gibt da nicht so viel her mit dem ich was anfangen kann).

Wenn ich den Breakpoint in der Hauptschleife setze, weiß ich trotzdem nicht wo die Variable verändert wird. (Da wäre eine "Zurück" Funktion Praktisch

Als Funk hab ich einen 868Mhz Empfänger der über einen Interrupt abgehandelt wird. Als konkretes Problem hab ich momentan Folgendes: Manchmal, wenn der µC längere Zeit im Stand-By Powersave mode ist, reagiert er nicht mehr auf die Funksignale. Leider tritt das relativ selten auf, und ich habs noch nicht geschafft die Ursache zu finden. Da wäre es praktisch wenn ich alle damit verbunden Variablen überwachen könnte um zu sehen ob sich irgendwann eine Verändert ohne das es beabsichtigt ist. Jede einzelne per Breakpoints überall im Code zu überprüfen verhindert den eigentlichen Funkempfang und ist auch sehr Zeitaufwendig.

Wäre praktisch gewesen, aber dann muss ich halt so weiter suchen.

[jschilli]

Du kannst Dir ja mal das http://www.freertos.org mal anschauen...

Wenn Du Variablen im Interrupt und in Deiner normalen Schleife manipulierst, musst Du unbedingt dafür sorgen, dass die Manipulation in Deiner Schleife atomic ist... Das heißt konkret, jede Manipulation einer Variable, die auch im Interrupt verwendet wird, darf nicht durch einen Interrupt unterbrechbar sein. Das erreichst Du, indem Du alle Interrupts vor der Bearbeitung sperrst und anschließend wieder frei gibst...
Ich habe das auch schon vergessen und mich hinterher über merkwürdiges Verhalten gewundert...

Liebe Grüße,
Jürgen