Hallo Forum, benutzt wird ein AT90CANXX. Momentan wird er erstmalig per SPI (Parallelport-Programmer) programmiert (Bootloader), danach dann per RS232. Aber das geht ja alles über die selben Anschlusspins. Am SPI hängen auch andere ICs dran. SCK zu diesen ICs geht über 100R. Gibt soweit auch keine Probleme. Aber es wird ja auch entweder Programmiert oder es läuft das Programm. Nun würde ich eigentlich gerne mein Programm debuggen können -> JTAG. Dafür müsste ich aber 4 Portpins "opfern". Lohnt das überhaupt? Portpins sind immer knapp. Da beim Debuggen ja quasi das Programm und der Debugger gleichzeitig laufen, scheidet eine Doppelbelegung wie beim SPI vermutlich aus, oder? Mir erscheint der Vorteil des Debuggers teuer erkauft. Gibt es da irgendwelche Tricks für eine Art Doppelbelegung?
Du kannst darauf auchten, das auf den JTAG-Pins irgendwelche Nebenfunktionen liegen, die (1) den JTAG-Debugger nicht stören und (2) beim Debuggen nicht wichtig sind. Dann geht beides. Entweder du kommst ohne Debugger aus, oder du brauchst die Pins. Das musst du selber wissen. Es gibt 2 Gruppen von Entwicklern. Die einen schwören auf Debugger, die anderen kommen fast immer ohne aus.
Bischen nachdenken sollte helfen ;-). Wenn da beispielsweise low current LEDs dranhängen, dann werden die zwar bei aktivem JTAG nicht funktionieren und während dem Debuggen fröhlich blinken, sonst aber nicht stören. Such dir also in der Schaltung ein paar weniger wichtige Output-Pins, deren unkontrolliertes Herumgewackel niemanden wirklich stört, und lege die auf die JTAG Pins. Oder wenn das Gewackel stört (z.B. Relais), dann häng Jumper dazwischen.
A. K. wrote: > Es gibt 2 Gruppen von Entwicklern. Die einen > schwören auf Debugger, die anderen kommen fast immer ohne aus. Was aber nicht heißt, daß diese nicht debuggen. Debuggen muß jeder und macht auch jeder. Um ohne JTAG zu debuggen, fügt man entsprechende Debugausgaben in das Programm mit ein und sendet diese über einen beliebigen Kanal (CAN, RS-232, Ethernet, Funk, ...) an ein Terminal. Das hat verschiedene Vorteile. Man kann remote debuggen, die CPU wird beim Debuggen nicht angehalten, es wird nicht bei jeder Debugsitzung das Programm neu geflasht. Auch ist diese Debugmethode nicht an eine bestimmte CPU (AVR) gebunden und ein bestimmtes Interface (JTAG), sie ist quasi universell und immer anwendbar. Daher wird sie gerne genommen, anstatt sich bei jeder CPU in ein bestimmtes Debugtool neu einarbeiten zu müssen. Peter
Wenn man das richtig anstellt, dann baut man in den Code an entscheidenden Stellen des Programms von vorneherein solche Traces ein und lässt sie da auch später noch drin. Entweder macht man die per Preprocessor abhängig von Debug/Produktions-Build abschaltbar, besser aber zur Laufzeit global und/oder selektiv ein/ausschaltbar. Wenn letzteres, dann kann man bei später auftretenden Problemen live ohne Neuprogrammierung oder Beeinträchtigung des Betriebs zusehen. Und braucht spezielle Debugausgaben nur bei Detailproblemen.
Bitte 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.