Das Hardware-Debuggen klappt! Bin mit dem MPLAB-System und den Progs umgezogen auf eine andere HD und dort läuft es. Das Debuggen lässt sich starten, dann per Pausen-Knopf anhalten, dann einen Breakpoint setzen, weiter laufen lassen und es hält dann auch am BP und auch die vorher vermissten Variablen mit ihrem aktuellen Wert werden im passenden Fenster gelistet. Ist alles noch ungewohnt, auch läuft das "Weiterlaufen" erstaunlich langsam, aber lass' ma, das wird wohl so richtig sein.
So richtig steige ich da erst in den nächsten Tagen ein, es sollte eh' nur ein erster Versuch sein. Stattdessen muss ich mich jetzt wieder mit den üblichen üblen Computer-Problemen rum ärgern, siehe bei Interesse anderer Fred.
Grüße und noch möglichst schöne Ostern, picass

Die Formulierung "Stoppen des Debuggers" ist eine eher lautmalerische. Gemeint ist damit das Nutzen der Pause-Taste, so, wie ich es vom Simulator gewohnt bin. Anschließend kann man halt die Werte der Variablen ansehen oder z.B. im Einzelschrittmodus das Programm bei der simulierten Arbeit betrachten.
Dieses Pausieren scheint - warum: scheinen? Erklärung kurz drauf - den Debugger noch im Rennen zu halten, der Cursor verharrt dann an einer Prog-Stelle. Was auch zu funktionieren scheint, ist das Setzen eines Breakpoints z.B. einige Zeilen später. Nach Drücken des "Weiter"-Buttons schien das Prog auch bis zu genau diesem B-Punkt zu laufen. Aber dann...., dann war nichts mehr mit Debugger-Herrlichkeit: alle wichtigen Debug-Symbole ausgegraut.

Der Schein muss sein: Kämpfe gerade mal wieder mit Hardwareproblemen an meinen Compis. Nach dem Niederringen der Probs an meinem Spielecomputer hat es nun meinen sonst extrem zuverlässigen "Arbeits"-Computer erwischt und das möglicherweise gleich auf zwei SSDs. Auf derjenigen, welche das MPLAB beherbergt, scheint ein Trouble mit Datenstrukturen aufgetaucht zu sein. Der PC läuft nur noch mit mehr als angezogener Bremse: quälend langsam. Es fand auch schon ein automatischer Reparatur-Versuch statt, aber wohl ohne Erfolg. Muss das ganze MPLAB-System wohl auf eine andere HD umziehen lassen.
Auch die SSD mit dem Eagle-Prog scheint 'ne Macke zu haben, die ziert sich beim Starten des Compis und versteckt sich, rsp. den Bootsektor häufig. Meist startet sie erst beim dritten oder vierten Anlauf.
Murphy ist bei bester Laune, all seine Therien über vermeintliche, aber nicht zutreffende Zufälle scheinen sich zu bewahrheiten. Wegen dieser Probs kann ich z.Z. kaum noch arbeiten, und muss erst mal gegen unzuverlässig werdenden SSDs ankämpfen.
Grüße, picass

Was genau meinst du mit "Stoppen des Deb-Laufes"?

(der "Stop" Button bricht dass Debuggen komplett ab)

Wollte mir heute einen lang ersehnten Traum erfüllen: einen Hardware-Debugger in Betrieb zu nehmen. Dazu sollte sich ja das vorhandene PICkit3 eignen. Zu meiner Freude fand ich im Regal eine passende Schaltung, die schon fast wieder in Vergessenheit geraten war: ein PIC18F14K22 nimmt an seinem Port A2-Pin ein analoges Signal auf – hier von einem Trimmer – , verarbeitet das und gibt über PORT B und C die Daten dezimal auf eine 4-stellige 7-Seg-Anzeige aus, und zwar schlicht im Umfang von 0 bis 1023. Funktioniert prächtig, die letzte Ziffer springt etwas, egal.

Der Port A ist bis auf A2 frei gehalten und seine entsprechenden Leitungen führen auf einen kleinen 5-pol-Pinsockel, welcher direkt mit dem PICkit3 verbunden werden kann. Auch das klappt, also z.B. das Programmieren.

Aber der erste Versuch des Hardwaredebuggens endete sehr fix. Die Verbindung zwischen MPLAB und Zielplatine wird sichtbar hergestellt, das Debuggen lässt sich starten, läuft auch, und es klappt auch das Stoppen des Deb-Laufes. Da zeigte sich eine erste Nicklichkeit: es wurden keine Variablen im Whatch-Fenster angezeigt. Der Grund dafür war aber die Haupt-Nicklichkeit: nach dem Stoppen des Laufes springt der Debugger aus seiner Routine, sichtbar daran, dass das rote Symbol, welches den aktiven Lauf anzeigt, nicht mehr rot ist sondern ausgegraut und auch daneben liegende Symbole – etwa Reset und Fortführen, etc. - ausgegraut sind. Es gibt auch eine Zeile mit Fehlermeldung, nach dem Clickern dadrauf zeigen sich nacheinander die Texte in den zwei ersten Bildern.

Ist jetzt im Moment für mich kein dräuendes Problem, weil ich das letzte Prog – Garagentorsteuerung – schon erfolgreich entwanzen konnte. Zukünftig würde ich doch gerne das HW-Debuggen nutzen können.
Grüße, picass

Habe geschnüffelt! In der MPLAB-x-IDE-Hilfe und bin auf die im Anhang nieder gelegte Vergleichstabelle gestoßen.
Also gettz Butter bei die paar Fische bei uns in der Ruhr, was der nächst gelegene Fluß ist: demnach müsste das PICkit3 ja grundsätzlich auch für Hardware-Debuggung brauchbar sein. Schwitz...., habe ich noch nie probiert und werde das etwas später heute Nachmittag mal versuchen.
Aber der Tabelle entnehme ich auch, dass das ICD3 da etwas mehr zu bieten hat, irgendwas mit Breakpoints. Würde mich über Aufklärung freuen .... wäre auch an der Zeit bei meinem  Alter!
Grüße, picass

Nachtrag: der Hinweis auf "kostenlos bekommen" ist ein eher ungünstiger. Macht die Sache aus meiner Sicht nicht einfacher, weil es überhaupt nicht meine Absicht ist und auch keinen Hintergedanken gibt, das was abzustauben. Aber vielleicht ging ja was über eine gezielte Spende.
Wichtiger aber als Finanzielles wäre mir der Nutzwert, also ob der ICD3 da in der hatten Debugger-Praxis einen brauchbaren Mehrwert hätte.

ICD2 hätten wir noch jede Menge nutzlos rum liegen.
Für die haben wir mal von Microchip die PICkit3 kostenlos als Ersatz bekommen
und den alten Schrott wollten die nicht zurück haben.

Mit dem PICkit3 als Debugger bin ich mir absolut sicher ;-)

Schau mal....!
Habe gerade im Datenblatt für das ICD2 geschnüffelt und dann in der von mir verwendeten MPLAB-IDE-Umgebung geschaut: die mögen sich nicht. In der Version MPLAB X IDE 5.20 geht es erst aber ICD3 los, der Zweier ist nicht aufgeführt, wird also entsprechend auch nicht funktionieren. Schade, ich hätte nur hier im Pott in die Nachbarstadt fahren müssen und wäre für "kleines Geld" an so'n Zweier gekommen.

Nochmal auf diesen Punkt: Nach meine bisherigen Verständnis kann man mit dem PICkit3-Programmer dieses Hardware-Debuggen nicht ausführen. Es muss ja einen Grund geben, warun das damals wesentich teurere ICD2 eingeführt wurde. Muss mal nach den Datenblättern für MPLAB forschen, ob da was über die Verwendungsmöglichkeiten des Hardware-Debuggens drin steht und ob die zwei Programmer, das PICkit2 und das ICD3 in diesem Punkt unterscheiden. 

Für das ICD3 gibts auch Anbieter im Inet, aber natürlich würde ich - wenn - das Gerät lieber von dir kaufen, vloki!
Grüße, picass

Ein ICD3 hätte ich noch irgendwo rumliegen.
Müsste ich mal schauen, ob das funktioniert...

ICD2 wird mit MPLABX nicht mehr funktionieren!

Macht aber nichts, weil PICkit3 auch ein Debugger ist ;-)

Ich habe das PICkit3. Es geht mir nicht um ein Programmiergerät, sondern um diejenige Funktion, welche dem ICD2, rsp. seinen neueren Nachfolgegeräten zugeschrieben wird, nämlich bei einem schon programmierten und in die Anwenderschaltung eingebauten/eingelöteten PIC quasi ein Hardware-Debuggen ausführen zu können. Also den PIC in seiner häuslichen Umgebung laufen zu lassen, auch im Einzelschrittmodus und dann dessen Register auszulesen. Nach meinem Verständnis geht das nur mit den ICD-Geräten, aber nicht mit dem PICkit3.

Bei der Gelegenheit, weil ich gerade einen Anbieter eines ICD2 an der Angel habe, der sich aber auch nicht mehr auskennt, weil das für ihn zu lange zurückliegt und er das Gerät eh kaum nutzte:
- läuft ein ICD2 auch noch unter neueren Win-Versionen, also Win10?
- muss man für das anvisierte Hardware-Debuggen noch weitere Zwischensockel anschaffen oder reicht ein Verbindungskabel?
Würde das angebotene Gerät, das ICD2, gerne kaufen, aber laufen sollte es schon.
Grüße, picass