moin, Nur zum Verständnis: Die modernen Mikrokontroller haben ja alle einen ICE (In-Circuit-Emulator). Das ist doch ein extra-Chip, der mit dem Mikrokontroller verbunden ist. Das ganze Debuggen, Flashen u.s.w. geht ja über diesen ICE. Man greift also nicht direkt auf den Mikrokontroller zu. Könnt ihr mir da weiterhelfen?
2. Frage: Wenn ich irgendetwas über den Emulator mache, geht es direkt auf den Original-Mikrokontroller über. z. B. wenn ich über den Emulator Flashe, Debugge etc.. --> wirkt sich das dann auf den eigentlichen Mikrokontroller aus. Was ist denn der Sinn vom Emulator?
Der Sinn eines Emulators ist wie der Name schon vermuten lässt den jeweiligen Mikrocontroller zu emulieren. Also sein gesamtes Spektrum der Fähigkeiten (in einer Software) nachzubilden. Das gibt einem die Möglichkeit unbeschränkt Eingriffe für das Debugging, etc. vorzunehmen. Den meisten Entwicklern reichen z.B. Breakpoints um zu diesen beispielsweise Timer auszulesen, etc. Das alles aber ein viel größeres Spektrum kann man mit einem ICE erreichen. Unverzichtbar bei Sicherheitskritischen Entwicklungen um Fallbackmodes, etc zu testen. Für den Hobbyanwender so gut wie unbezahlbar.
Toffifee schrieb: > Das ist doch ein extra-Chip, der mit dem > Mikrokontroller verbunden ist. Damit kommt man nicht weit, da an einem µC-Chip fast nichts entscheidendes von aussen gelesen werden kann, wie z.B. der Inhalt eines Registers oder der Stand eines Timers. Dazu gab es früher "Bond-Out-Chips", Spezialanfertigungen des Prozessors, bei dem entsprechende interne Busse nach aussen geführt waren. Zu Zeiten eines Z80 war zum Ersetzen der CPU noch ein 40 poliges Kabel mit DIL-Stecker ausreichend, heute geht das praktisch nicht mehr, da es keinen Stecker gibt, um etwa ein TQFP-100-Package zu emulieren, es gibt ja kaum noch Chips, für die überhaupt Fassungen verfügbar sind. Deshalb wird heute eher eine Debugschnittstelle im Chip selbst vorgesehen, z.B. JTAG, so dass man die Informationen über 4 Leitungen und ein Debug-Interface abfragen kann. D.h. aber auch, wenn man diese Leitungen auf der Leiterplatte nicht auf einen Debugstecker führt, sondern als I/O verwendet, kann man auch nicht debuggen. Gruss Reinhard
Bevor's vergessen geht. Ein Emulator ist in der realen Hardware. Und laesst den Benutzer das Programm zb Singlesteppen. Wenn nur simuliert wird, nennt sich das Simulator.
Die wichtigste Frage ist aber: Wirken sich alle Sachen, die ich mit dem Emulator mache z. B. das Flashen des Programms oder das Steppen des Programms auf den eigentlichen Mikrokontroller aus? grus
Was ich einfach wissen will ist: Es gibt einen JTAG-Adapter, den man ans Board anschließen kann. Dabei gibt es die Modi's "Debugging" und "Flashing". Wirkt sich beides auf den eigentlichen / originellen Mikrokontroller aus?
Toffifee schrieb: > Wirkt sich beides auf den eigentlichen / originellen > Mikrokontroller aus? Es kann nur einen geben - der der eingelötet ist. Im Interface kann zwar auch ein Controller sein (fast immer), aber der macht USB und das JTAG-Protokoll und ist meistens auch ein anderer als der Debuggee. Rein prinzipiell könnte man in einem Mehrprozessor-System mehr als einen Prozessor an den JTAG-Stecker verbinden, aber ich vermute dass viele Debugger die garnicht getrennt ansprechen können, ich würde das daher lassen. Da für viele Chips Fassungen und Adapter nicht erhältlich oder unbezahlbar sind, ist das Flashen "In System" die gängige Methode auch für die Fertigung. Die nötigen Pins muss man sich halt gönnen. Gruss Reinhard
JTAG ist erstmal nur die gebräuchliche Bezeichnung einer Hardwareschnittstelle, die mit einem internen Zustandsautomaten verbunden ist, der über diese Schnittstelle angesteuert werden kann. Ursprünglich wohl hauptsächlich für Boundary-Scan entwickelt (d.h. Pins über die Schnittstelle schalten und abfragen) - der "Modus" wurde noch nicht genannt. Es gibt aber noch eine andere Methoden (BDM, SWD, PDI ...) Debuggen ist zumindest abhängig von der Schnittstelle (z.B. JTAG, BDM...) und dem verwendeten Controllerkern (z.B. Cortex M3, MIPS, AVR etc.). Da der aber bisher nicht genannt wurde, auch auf Nachfrage von 2v3, gibt es keine konkrete Antwort. "Auswirkungen" auf den Controller können sein: verändertes Laufzeitverhalten durch breakpoints/steppen, Temporäre Änderunge des Programmcodes durch zeitweise eingefügte Halteanweisungen und anderes. Konkrete Antwort ohne mehr Details kaum möglich. Bei "flashen" muss man zwischen internen und externen Speichern unterscheiden. Bei internen Speichern ist es zumindest bei ARM-basierten Controllern üblich, dass über die Debug-Schnittstelle ein kleines Programm ins RAM des Controllers übertragen wird, dass dann Blockweise die vorher über die Schnittstelle in andere Bereiche des RAMs übertragene Daten in den Flash-Speicher schreibt. Wie das "kleine Programm" aussieht ist abhängig vom Controller (nicht nur von dessen Kern). Wäre bitter, wenn sich das nicht auf den "eigentlichen" Controller(-speicher) auswirken würde. Externer Speicher kann mit dem gleichen Ansatz geschrieben werden allerdings gibt es auch die Möglichkeit über die Boundary-Scan-Funktinoalität zu schreiben - meist aber mit deutlich geringeren Übertragungsraten. Nachtrag: Besagtes Verbinden mehrerer Targets an eine JTAG-Schnittstelle ist meines wissens Teil der Spezifikation. Wenn alle Teilnehmer diese richtig implementieren (wohl nicht immer der Fall), ist eine Scan-Chain über JTAG möglich und bei Controller-FPGA-Kombiboards wohl üblich.
Martin Thomas schrieb: > Nachtrag: Besagtes Verbinden mehrerer Targets an eine JTAG-Schnittstelle > ist meines wissens Teil der Spezifikation. Ja, aber nicht das Debuggen - daher sind auch die JTAG-Debugger i.A. nicht austauschbar, sondern nur für eine bestimmte Prozessorklasse geeignet. Als Mod könntest du dafür dankbar sein, Fragen wie "kann ich mit einem XYZ-JTAG-Kabel auch einen AVR debuggen und wenn ja warum nicht" füllen die Elektronikforen zuverlässig. Prinzipiell kann man sagen, jedem Prozessor sein JTAG-"Kabel", wobei das immer mehr ist als bloss ein Kabel. Gruss Reinhard
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.