|
Anzeige
|
JTAG oder nicht
Gast
#44421
Die alten AVR-Controller hatten kein JTAG-Interface. Von den neuen sind es immer mehr. Der Mega16 hat es, der mega8535 als Nachfolger des weitverbreiteten 8535 nicht. Die MSP430-Familie von TI hat es. Mit JTAG vereinfacht sich das Debugging. Soll man nun eher nur die Varianten mit JTAG bevorzugen oder machen die megas ohne JTAG auch noch Sinn? Danke für Eure Beiträge . . . "Mit JTAG vereinfacht sich das Debugging." Kannst Du das mal irgendwie erläutern oder begründen ? Ich habs noch nie benutzt, sieht aber höllisch kompliziert aus und man muß sich mit einem als fehlerträchtig bekannten Windows Programm (AVR-Studio) rumplagen. Ich denke mal, sobald man JTAG-Debugging macht, bleibt die CPU stehen und das ganze Echtzeitverhalten ist zum Teufel. Ich mache Debugging immer über eine RS-232 und füge an den verdächtigen Stellen entsprechende Ausgaben ein. Dabei haben diese Ausgaben keine Priorität, d.h. die Echtzeitverarbeitung geht vor. Notfalls wird eine Meldung ignoriert, wenn die vorherige noch nicht fertig gesendet wurde. Peter JTAG kann schon ein bisschen mehr als printf-Debugging, und "höllisch kompliziert" ist da überhaupt nichts. Das Debugging funktioniert praktisch genauso wie die Simulation im AVR-Studio, mit dem Unterschied dass man direkt in der Hardware "drin" ist. Der Nachteil ist dass JTAG so viele Pins am Controller belegt, aber angeblich ist ja von Atmel eine Art 1-Wire-JTAG in Planung. "...*bisschen* mehr..." Hm, das war ja sehr konkret. Eine Simluation bleibt stehen, aber da sie nicht mit Hardware zusammenarbeiten muß, macht das nichts. Kann man nun mit JTAG "on the fly", d.h. bei Full Speed Werte abfragen, wenn sie z.B. einem nicht erwarteten Bitmuster entsprechen oder nicht ? Peter Bei manchen JTAG-Emulatoren ist es möglich bei Änderung einer Variable eine Unterbrechung auszulösen. Daten aus dem Prozessor auslesen kann man nur bei angehaltenem Prozessor, dafür hat man auf alle Register und Speicherstellen Zugriff und muss nicht für jede Variable die man beobachten will ein printf() machen. Außerdem kann man Register und Speicher beliebig verändern. In einer typischen Anwendung wo z.B. Taster und Temperatursensoren abgefragt werden, die Werte auf eine Speicherkarte geschrieben und Statusinformationen auf einem LCD angezeigt werden, passiert der Hardware überhaupt nichts wenn sie mal zwischendurch ein paar Sekunden Pause machen muss (außer man setzt einen Breakpoint mitten in eine 1-Wire-Übertragung). Geht also nicht. Danke, das wars, was ich wissen wollte. Ich mache viel mit digitalen Regelkreisen und da ist 1 Sekunde Pause schon zuviel. Außerdem fühle ich mich sicherer, wenn ich einen MAX232 als Puffer zwischen dem MC und der rauhen Außenwelt habe. Oft nehme ich auch noch zusätzlich Optokoppler (Erdschleifenproblematik). Peter
Gast
#44427
Hi wirklich ernsthaft debuggen kann man ja mit der RS232 nicht. Kontrollausgaben ja aber eben kein zeilenweises Ausführen von C-Code usw. Natürlich zerhackt einem das beim Auslesen von Werten die Echtzeitfähigkeit. Aber hin und und wieder ist das ganz nützlich wenn man mal in den Controller "reinkucken" kann und nicht alles über die RS232 rauszuschreiben. Wenn man die 4 Pins opfern kann ist das ganze ein "nice-to-have" mehr aber auch nicht. Matthias
Gast
#44428
ich habe früher einen 68F333 in Betrieb genommen. Und dazu Testprogramme für die ganze Peripherie geschrieben. Und diese Testprogramme konnte ich Step by Step ablaufen lassen und die Register etc. ansehen. Das meiste der Hardware konnte so ohne einen teuren Emulator getestet werden. Für mich war das ein wertvolles Werkzeug. Auch wenn es natürlich nicht voll in Echtzeit lief. @Andreas: Das mit den JTAG-Pins finde ich nicht so schlimm. Lieber einen MSP430 mit 20pins als einen AT TINY, wo man dann Rätselraten darf, warum er gerade nichts oder nicht das Richtige macht . . . Matthias
Gast
#44429
@Matthias Sehe ich das richtig, das es sich bei dem 68F333 um einen Motorola 32bit Controller handelt? Wenn ja, würde mich interessieren mit was für Tools du dies durchgeführt hast. Such nämlich gerade eine billige Variante um das interne Flash, bzw externe Flash zu beschreiben. Danke MfG Stephan
Gast
#44430
@Stephan: ja, es war ein 32bitter. ich hatte eine BD32-Schnittstelle. Konnte man mit ein paar Gattern selber zusammenlöten. Am LPT-Port angeschlossen. Gab es von Motorola gratis eine tolle Software dazu, wo man sich kleine Programme ins RAM der CPU schreiben konnte, um sie dort testweise einmal laufen zu lassen. Sogar Breakpoints waren möglich. Hat Spaß gemacht. Auch für das Flash gab es Programme, die man da laufen lassen konnte. Joseph Fuchs von Motorola hat damals Bücher zum Thema geschrieben. Er war ein Klasse-Supportmann. Kannte fast alle Register auswendig. Und immer nett und hilfsbereit. @alle: eben das ist es was ich von JTAG erwarte. Ein standardisiertes Interface, das problemlos Zugriffe auf verschiedene Hardware erlaubt. Also muß es doch möglich sein mit ein und demselben JTAG, z.B. dem von Atmel auch auf den MSP430 zuzugreifen und dort zu debuggen. Matthias
Gast
#44431
Hallo Stephan, kannst mal hier bei den Tools schauen wie man das flash Programmieren kann. http://www.elektronik.vhf.de/nf300/download.html Auf dem Board werden Atmel flash Chips verwendet. Evtl muß der algorithmus angepaßt werden aber ich glaube eher nicht. Dokus zum BDM32 etc findest Du bei Motorola auch eine Schaltung um ein BDM32 zu bauen. Für alle anderen : Bei JTAG weiß ich es nicht aber BDM läuft in einer Separaten Unit der MCU und das ganze auch asynchron zur MCU. Eckhard
Gast
#44432
@Eckhard Vielen Dank für den Link, muß ich mir mal genauer anschauen. Kennst du dich mit dem Board bzw den BDM Tools was dort vorgestellt werden etwas aus? Habe nämlich folgendes Problem, habe ein Evalboard eines MPC555 geschenkt bekommen. Das es einen freien C Compiler geben muß hat mir ein Kollege gesagt, jedoch wie ich das Programm ins RAM ROM oder sonst wo hin bekomme ist bisher mein Problem. Also nochmals vielen Dank für den Link. MfG Stephan Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
