Was ist der funktionale Unterschied zwischen einem In-Circuit-Debugger und einem In-Circuit-Emulator?

In-Circuit-Emulatoren (abgekürzt ICE) rühmen sich ihrer großartigen Debugging-Funktionen und rühmen sich auch hoher Preise.

In-Circuit-Debugger (abgekürzt ICD) können das meiste von dem, was ein ICE kann, kosten aber oft viel weniger.

Ich weiß, dass ICEs früher tatsächlich den problematischen Chip aus dem Sockel entfernten und ihn durch ein Emulatorkabel ersetzten, aber mit modernen QFN-, BGA- und zerbrechlichen TQFP-Paketen scheinen sich die meisten Produkte "ICE" -Debugger zu nennen sind ähnlich wie ein ICD mit einem Debug-Header verbunden.

Hier sind einige Beispiele für Produkte, die "ICE" im Namen verwenden:

Es gibt auch JTAG 'ICE'-Produkte von mehreren Anbietern. Beachten Sie, dass ich diese nicht rabattiere, weil sie nicht physisch im Schaltkreis sind, aber ich würde sie rabattieren, wenn sie nicht als echte ICE funktionieren.

Bei welchen Entwicklungsaufgaben benötige ich einen ICE und wann sollte ich mich mit einem ICD begnügen? Nehmen wir an, ich möchte meinen Code schrittweise durchlaufen und keine LEDs und printf () -Anweisungen verwenden.

Was sind einige Beispiele für Probleme, die Sie mit einem ICE gelöst haben, die Sie aber (realistisch) ohne ihn nicht hätten lösen können?

Antworten (1)

Ein ICE (In-Circuit Emulator) ersetzt den Zielchip. Es verhält sich für den Rest der Schaltung wie der echte Chip, hat aber alle möglichen Haken im Inneren, damit Sie sehen können, was los ist, Haltepunkte setzen, neuen Code laden, Spuren erfassen usw. Ein ICD (In-Circuit Debugger) wird verwendet spezielle Debug-Hardware, die zu diesem Zweck dem Zielchip hinzugefügt wird, und versucht, Ihnen ICE-ähnliche Fähigkeiten zu verleihen. Leider haben sich Marketingleute eingemischt und versucht, diese langjährigen Begriffe neu zu definieren, um Sie zu täuschen, dass ihr Produkt besser ist als das nächste. RealIce von Microchip ist ein besonders ungeheuerliches Beispiel dafür. Es ist echt, aber das einzige, was es nicht ist, ist ein ICE.

Ein echtes ICE (nicht das RealIce) ist die beste In-Circuit-Debugging-Umgebung. Leider sind diese aufgrund der hohen Kosten für die Herstellung einer speziellen Bondout-Version des Zielchips für die Verwendung im ICE und der Tatsache, dass die Geschwindigkeiten so hoch geworden sind, dass es problematisch ist, etwas vom Chip zu entfernen, so gut wie verschwunden. Ein weiteres Problem besteht darin, dass ein ICE erfordert, dass sich der Zielchip in einem Sockel befindet, oder dass ein spezieller Adapter erforderlich ist, der anstelle des Zielchips montiert ist, damit der ICE eine Verbindung zu seinen Leitungen herstellen kann.

Heute bleiben wir bei ICDs hängen. Glücklicherweise tun sie die meisten Dinge, die Sie mit einem ICE tun möchten. Sie haben sogar den Vorteil, dass der Code auf dem echten Zielchip läuft und nicht etwas, das versucht, wie der Zielchip zu sein. Der Nachteil ist, dass sie On-Chip-Ressourcen benötigen und daher für Ihren Code und Ihre Hardware nicht vollständig transparent sind, wie es ein ICE ist. Der ICD benötigt Zugriff auf Debugging-Leitungen, die oft mehrere Rollen haben können. Sie können diese Pins während des Debuggens nicht in anderen Rollen verwenden. Die Menge an Debug-Schaltkreisen, die in jedes Teil eingebaut sind, muss auf einen kleinen Bruchteil der Gesamtmenge beschränkt werden, sonst wären die Kosten zu hoch, sodass bei den Funktionen Kompromisse eingegangen werden müssen. Ein nettes Feature, das zu teuer wäre, um es auf jedem Chip hinzuzufügen, ist die True-Trace-Fähigkeit, da dies einen großen RAM-Puffer erfordert.

Jedes Problem kann schließlich mit einer Vielzahl von Tools gelöst werden. Es geht nicht darum, ob Sie es lösen können, sondern wie lange und wie viel Aufwand es kostet. Als ich regelmäßig ICEs (Microchip ICE-2000 und ICE-4000) verwendete, habe ich die Trace-Funktion nicht oft verwendet, aber wenn ich es getan habe, wären andere Mittel erheblich teurer gewesen. Manchmal haben Sie einen Fehler, bei dem eine Variable plötzlich den falschen Wert enthält. Sie gehen den Code durch und alles ist in Ordnung, und die Routine, die die Variable manipuliert, scheint alles richtig zu machen, aber wenn Sie sie ausführen, scheitern die Dinge schließlich und Sie finden diese Variable im Müll. Die Ursache ist ein anderer Code mit einem fehlerhaften Zeiger, Pufferüberlauf, Stack-Nichtübereinstimmung oder ähnlichem. Mit einem ICE können Sie einen Haltepunkt auf die zu ändernde Variable setzen,

Meist reicht ein ICD aus. Besonders bei großen Chips sind die paar Pins, die dem Debugging gewidmet sind, kein großes Problem. Heutzutage verwende ich das RealIce hauptsächlich zum Debuggen. Es ist viel stabiler und weniger flockig als das ICD2. Man lernt damit zu leben.