Teure Debugger Vorteile

Ausrede für Manager.

"Wenn das Projekt sogar mit professionellem Equipment, Schulungen und 
Support in die Hose gegangen ist - was wäre dann erst passiert, hätten 
wir China-Glump gekauft?"

Ein ehemaliger Marktführer hatte mal den Werbespruch: Es wurde noch 
keiner entlassen, weil er IBM gekauft hat.

Und das auch noch extrem resourcenschonend!

Wenn man low cost hw benutzt wie Bluepill oder die STLink clones hat man 
ein super Preis-Leistungsverhältnis. Aber zb auch die 3.3 V 
Einschränkung.
Das org BMP hat einen Buffer und passt sich der VTarget an, kostet aber 
auch gleich ein vielfaches.
Durch die einfache Konfiguration ist BMP meine Lieblingsprobe.

Ich nutze einen Debugger von Lauterbach. Die SW stammt gefühlt noch aus 
DOS Zeiten. Sieht nicht toll aus, aber man kann sie individuell Anpassen 
wie man Lust und Laune hat. Eigene Schaltflächen, Makros, Befehle. 
Selbst das Layout der Oberfläche. Steht einem alles frei.

Die Anzahl der unterstützten Controller ist gigantisch. Der Support 
erste Klasse. Der Debugger selbst hat eine irre Perfpormance. JATG mit 
50 cm Kabelpeitsche dazwischen, egal läuft bei 20 MHz. Hunderte 
Breakpoints, klar kein Problem. Ach du willst zu dem nur Springen, wenn 
die Variable den Wert hat, du vorher durch diesen Zweig gelaufen bist 
und heute Donnerstag ist? Klar auch kein Problem. Du willst zwei 
verschiedene Controller gleichzeitig Debuggen, na aber sicher doch.

Das kann der Debugger vom Nucleo Board nicht.

Lauterbach zb rufst du an und bekommst in deutsch Hilfe.
Da der Kopf bei den Debuger auch die Liezen enthält behält man das 
Grundgerät und kann dann so ziemlich alles debugen was 1 von 0 
unterscheiden kann.
Die einfachen ohne Hardwartraces Unterstützung gehen preislich.
Die großen sind privat nicht bezahlbar. Und den 4 Gb Tracespeicher auf 
dem Debuger hast uU extrem schnell voll.

Auch schön ist halt Multicore debugen, oder Datenbreakpoints.

Von den Spannungen gehen die glaub bei 1,5 V los bis 5 V hoch.

> Die Anzahl der unterstützten Controller ist gigantisch.

Das ist einer der Hauptgruende warum gute Debugger (und Eprommer) so 
teuer sind.

Schaut als Beispiel mal hier:

https://processors.wiki.ti.com/index.php/ICEPICK

JTAG ist nicht gleich JTAG. Das muss immer passend implementiert werden.

> 50 cm Kabelpeitsche dazwischen, egal läuft bei 20 MHz. Hunderte
> Breakpoints, klar kein Problem. Ach du willst zu dem nur Springen, wenn
> die Variable den Wert hat, du vorher durch diesen Zweig gelaufen bist
> und heute Donnerstag ist? Klar auch kein Problem.

Das geht mit dem gdb auch. Also dann z.B auch dem jLink. Man muss nur 
mal die Anleitung lesen.

> Klar auch kein Problem. Du willst zwei
> verschiedene Controller gleichzeitig Debuggen, na aber sicher doch.

Yep. Oder auch zwei gleiche Debugger an einem PC verwenden. Kommt ja 
auch manchmal vor wenn man Schnittstellen programmiert.

Das wichtigste aber, es muss ZUVERLAESSIG sein. Wenn ich auf Fehlersuche 
bin das ist keine schrullige Kiste akzeptabel wo ich mich frage ob das 
Problem nicht vielleicht auch am Debugger liegen koennte!

Und dann gibt es manchmal noch so Extremfaelle. Wenn der Debugger mit in 
den Klimaschrank muss. .-)

Olaf

Olaf schrieb:
> Yep. Oder auch zwei gleiche Debugger an einem PC verwenden. Kommt ja
> auch manchmal vor wenn man Schnittstellen programmiert.

Das geht mit den low cost BMP aber auch, die erzeugen ja verschiedene 
Schnittstellen und arbeiten autark.