Ich hätte da mal ein paar Fragen zum Debuggen. Leider habe ich im Internet nicht viel gefunden oder nur lückenhaft, oder es nicht verstanden. es geht mir dabei nur um AVR. Speziell dabei um 1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie Debuggen kann? und gibt es auch µCs die ich nicht richtig Debuggen kann? also nicht mit Atmel ICE sondern nur indem ich mir Daten z.b. auf nem LCD anzeigen lasse oder im PC? Beim Atmega32-16PU hab ich im Datasheet z.b. JTAG gefunden, aber bei manchen kleineren finde ich garnichts, nicht mal Debug-Wire. 2. Hier im Artikel zum Thema DebugWire steht dass der Reset-Pin keine kapazitiven lasten bekommen darf. Bedeutet das, dass ich zwar weiterhin den 10k pull-up drinlassen muss aber den Kerko zur Masse hin rausnehmen muss? 3. Ich habe gelesen dass DebugWire wohl sehr umständlich sein soll und man lieber sein Projekt erstmal auf nem Dickeren µC machen soll um ordentlich debuggen zu können und dann alles auf den kleinen µC umbauen soll. Stimmt das? und warum? 4. Ich bin ein Fan von tutorials, da kann man sich einlesen und alles ausprobieren und lernt viel....Und man braucht nicht dumm fragen. Leider habe ich zu dem Thema leider nichts gefunden oder wenn dann nur auf English, aber die dann auch teilweise sehr unverständlich. Kennt da einer ein Gutes Tutorial oder ne Gute Anleitung?
Hi >1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie >Debuggen kann? Datenblatt >und gibt es auch µCs die ich nicht richtig Debuggen kann? Ja. ATMega8 >2. Hier im Artikel zum Thema DebugWire steht dass der Reset-Pin keine >kapazitiven lasten bekommen darf. Bedeutet das, dass ich zwar weiterhin >den 10k pull-up drinlassen muss aber den Kerko zur Masse hin rausnehmen >muss? Dazu gibt es Angaben in der Beschreibung deines Debuggers >3. Ich habe gelesen dass DebugWire wohl sehr umständlich sein soll und >man lieber sein Projekt erstmal auf nem Dickeren µC machen soll um >ordentlich debuggen zu können und dann alles auf den kleinen µC umbauen >soll. Stimmt das? und warum? Der AVR Dragon benimmt sich manchmal etwas zickig. DEn ICE habe ich auch, aber Debugwire noch nict getested. MfG Spess
spess53 schrieb: > Hi > >>1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie >>Debuggen kann? > > Datenblatt So schlau bin ich auch :D aber ich finde es nicht. Hier im Artikel zur Debug-Wire steht zum Beispiel das der Atmega88 DebugWire kann, aber ich finde das im Datenblatt nicht
Hi S.334 im aktuellen Dateblatt: 29. DBG - debugWIRE On-chip Debug System MfG Spess
Oh man -.- ich sollte mir ne brille kaufen, alles klar danke :D
Gobbel schrieb: > 1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie > Debuggen kann? Daran, dass er lt. Datenblatt eine debugfähige Schnittstelle besitzt. Da es davon nicht bei den AVRs nicht so furchtbar viele gibt, ist das schnell abgeklärt... Allerdings wird die Nützlichkeit von HW-Debug von Anfängern sowieso massiv überschätzt. Tatsache ist: das bringt eigentlich fast garnix. Tatsächlich ist es nämlich so, das man ein Programm im Simulator viel besser debuggen kann. Hier hat man nämlich die Möglichkeit, Situationen gezielt beliebig oft zu reproduzieren. Erst das ermöglicht es, sich von dem Punkt, an dem der Fehler irgendwie "sichtbar" wird, zu dem Punkt zurück zu arbeiten, an dem seine eigentliche Ursache liegt. Das ist mit einem HW-Debugger praktisch unmöglich. Und er taugt auch nicht dazu, die Daten aufzuzeichnen, die zur Fehlersituation führen. Also: HW-Debugger sind eigentlich ziemlich überflüssig...
c-hater schrieb: > Also: HW-Debugger sind eigentlich ziemlich überflüssig... Dein Geschwätz ist überflüssig.
Gobbel schrieb: > 3. Ich habe gelesen dass DebugWire wohl sehr umständlich sein soll und > man lieber sein Projekt erstmal auf nem Dickeren µC machen soll um > ordentlich debuggen zu können und dann alles auf den kleinen µC umbauen > soll. Stimmt das? und warum? Beim Atmega168 und 328 dauert der Upload schon arg lange, wenn der Flash am Anschlag ist. Bei den kleineren Tiny ist das eigentlich kein Problem. Ein großer Vorteil ist, daß die 3 SPI-Pins im DW frei sind. Gerade bei 8-Pinnern, wo die Leitungen fast immer für etwas anderes benötigt werden. Zumindest mit dem Jtagice. Der Dragon hat da Pullups drauf, das stört bzw. irritiert manchmal.
1) Zum Debuggen brauchst du je nach Controller eine JTAG oder Debug Wire Schnittstelle. Manche haben haben keine Debug Schnittstelle. 2) Der externe Pull-Up Widerstand ist optional. Beim Debuggen stört er nicht. Aber Kondensatoren musst du ab machen, da der Reset Pin beim Debuggen der "Debug Wire" ist und serielle Daten überträgt. Das gilt nicht für JTAG! 3) Ich habe bisher JTAG noch nicht verwendet, nur Debug Wire. Was mir unangenehm aufgefallen ist: Jedes mal wenn amn einen Unterbrechungspunkt setzt, muss der Flash Speicher geändert werden. Schlimmer ist es, wen man das Programm im Einzel-Schritt Verfahren ausführt. Dann wird der Falsh bei jedem Tastendruck geändert, und dann nervt es schon, daß das jedes mal ca. 1 Sekunde dauert. Ich gehe davon aus, daß man durch das Debuggen ziemlich schnell den Speicher verschleißt. Außerdem muss man beim Lesen einiger Register aufpassen. Wenn du zum Beispiel das Daten-Register vom Seriellen Port liest, schnappst du damit dem Programm ein Zeichen weg. > man lieber sein Projekt erstmal auf nem Dickeren µC machen soll > um ordentlich debuggen zu können Da wirst du sehr unterschiedliche Meinungen finden. Ich habe das Programmieren von µC gelernt, als es noch gar keine Debug Schnittstellen gab. Ich bin damit vertraut, den Programmablauf mit Hilfe von LED's, Textausgaben auf einem Display oder auf einem seriellen Port zu untersuchen. Den Debugger hole ich nur selten aus der Kiste. Wer mit Arduino arbeitet, oder den hier so oft gelobten ESP8266 programmiert, hat in der Regel auch keinen Debugger zur Verfügung. Manchmal, wenn ein kleines bereits isoliertes Stück Code amok läuft, schreibe ich ein Testprogramm und führe es im Simulator aus. > Kennt da einer ein Gutes Tutorial oder ne Gute Anleitung? Zum Debuggen kenne ich keins. Da klickt man sich einfach in der GUI durch. Die ändert sich ja auch von Version zu Version. > Beim Atmega168 und 328 dauert der Upload schon arg lange, > wenn der Flash am Anschlag ist. Ich bin es gewohnt, per ISP zu flashen und danach per Debug Wire zu debuggen. Das geht schneller, als alles per Debug Wire zu machen. Im Prinzip stimme ich aber zu, Debug Wire ist recht lahm. Aber für Leute, die zuvor viele Jahre ganz ohne Debugger auskommen mussten, ist es trotzdem eine großartige Erfindung. Eins solltest du immer bedenken: Wenn du das Programm im Debugger anhälst, beibt es stehen! Mit allen sich daraus ergebenden Konsequenzen. Meine Waschamschine würde ich nicht anhalten wollen während sie gerade Wasser einlaufen lässt. Und mein Modellauto würde ich nicht auf der Straße debuggen wollen, wenn es gerade auf den nächsten Baum zufährt. Zumindest bei Debug Wire muss man den Controller aber zum Debuggen anhalten, denn nur im Haltezustand hat man Zugriff auf Speicher und Register. Wie ist das bei JTAG, kann man da Variablen und Register auslesen, während das Programm läuft? Was ist mit der Überwachung von Variablen? Ich nutze dieses Feature unter Java auf der Arbeit (nix mit µC). Debug Wire kann nicht melden, wenn eine Variable verändert wird. Kann JTAG das?
Stefan U. schrieb: > 1) Zum Debuggen brauchst du je nach Controller eine JTAG oder Debug Wire > Schnittstelle. Manche haben haben keine Debug Schnittstelle. Ja, was jetzt- braucht es oder braucht es nicht? > Da wirst du sehr unterschiedliche Meinungen finden. Ich habe das > Programmieren von µC gelernt, als es noch gar keine Debug Schnittstellen > gab. Ich bin damit vertraut, den Programmablauf mit Hilfe von LED's, > Textausgaben auf einem Display oder auf einem seriellen Port zu > untersuchen. Den Debugger hole ich nur selten aus der Kiste. Man sollte vielleicht mal klären, was der TO unter Debuggen versteht. Dann wird klar warum man zum Debugging keinen Debugger braucht, er aber helfen kann. Dann könnte man ihm die richtigen Stichworte für Google nennen und dann kann er sich auch selber helfen. Nach meinem Verständniss sollte der TO mal in die Richtung Software Test schauen. Auch wenn der Ansatz (Zeigen das programmiert was gefordert) beim Test ein andere als beim Debugging (Fehler lokalisieren/Beseitigen) sollte ihn das besser weiterhelfen als ein 0815 Debuggertutorial. Immer lesenswert dafür ist ISBN 978-3897215672 und oft hilft es die Bugs statt im real life im Simulator zu jagen: https://www.mikrocontroller.net/articles/AVR-Simulation
Effizientes Debuggen hängt nur sehr wenig vom Debugtool ab, sondern hauptsächlich vom Nachdenken. Planloses Debuggen kostet viel Zeit und bringt nur Ratlosigkeit und Verzweiflung. Viele erfahrene Programmierer nehmen einfach nur printf. Das läuft auf jeder Maschine, die Applikation wird nicht angehalten und man kann beliebige Filterregeln hinschreiben. Selbst auf dem kleinen ATtiny85 hat man schnell mit Bit-Banging ein UART-putchar zusammen gezimmert. Man muß auch nicht das große printf (~1kB) nehmen, sondern kann sich was kleines aus itoa und puts basteln. Ohne Hardwareinteraktion kann man auch simulieren. Aber z.B. einen PID-Regler wird man nur schwer simulieren können. Der braucht den realen Regelkreis und darf auch nicht beim Debuggen anhalten.
Ich wuerd auch Onchip debuggen vergessen. Denn der Prozess ist dann kaputt. Heisst, wenn man nicht grad am Ansteuern eines Displays ist, hat man externe Hardware mit einem eigenen Prozess dran haengen. Dieser Prozess laeuft dann weiter waehrend der Code nicht weiter laeuft. Das geht in den meisten Faellen nicht gut. Wie schon erwaehnt .. der Code schaltet eine Heizung ein, und stoppt dann. Wenn der code dann weitermacht, ist alles schon verdampft, resp die Messwerte beziehen sich dann auf einen Fall, der eigentlich gar nicht auftritt, Ueberhitzung. Von den Tinies sollte man die Finger lassen, die haben fast alle kein UART, und die Kostenersparniss von ein paar Cents ist fuer Kleinserien undwichtig. Also besser einen Mega verwenden. Die Megas habe alle serielle Schnittstellen. Dann muss man sich einmal einen robusten Treiber schreiben, und kann dann immer waehrend eines Prozesses debuggen. Dh die Prozessvariablen. Wenn der Prozess schneller ist als die Kommunikation legt man sich eben einen Tracebuffer an, den man auf irgend ein Signal hin, intern, oder extern, fuellt. Und nachher per Seriell ausliest. Allenfalls baut man sich einen Addon-Print, der einen oder mehrere 8 fach DACs einthaelt, auf die man dann Prozessvariablen schreibt, und mit einem Oszilloskop verfolgen kann.
:
Bearbeitet durch User
Sapperlot W. schrieb: > Ich wuerd auch Onchip debuggen vergessen. Denn der Prozess ist dann > kaputt. Heisst, wenn man nicht grad am Ansteuern eines Displays ist, hat > man externe Hardware mit einem eigenen Prozess dran haengen. Dieser > Prozess laeuft dann weiter waehrend der Code nicht weiter laeuft. Das > geht in den meisten Faellen nicht gut. Sagt wer? Es gibt reichlich Anwendungen wo HW-Debugging hervorragend funktioniert. Ich nutzte rund 70%HW Debugging und 30% SW-Debugging, nachdem das meiste was ich mache sehr HW-nah ist. Mit solchen absoluten Statements wär ich mal vorsichtig, wenn man nicht weiß was der andere vor hat. > Von den Tinies sollte man die Finger lassen, die haben fast alle kein > UART, und die Kostenersparniss von ein paar Cents ist fuer Kleinserien > undwichtig. Also besser einen Mega verwenden. Die Megas habe alle > serielle Schnittstellen. Voll dabei. Für den Hobby Bastler spielen weder 1-2€/chip noch die paar extra mm² eine nennenswerte Rolle. Warum sich so viele den Stress beim programmieren antun ist mir schleierhaft. ich nehm auch in der Regel lieber 32-Bit oder ARM-Prozessoren, weil man sich dann viel weniger Kopf um Datentypen oder mathematische Berechnungen machen muss. > Dann muss man sich einmal einen robusten Treiber schreiben, und kann > dann immer waehrend eines Prozesses debuggen. Muss man nicht. Treiber für UART gibts schon fertig im Software Framework von Atmel. Klickt man sich auf Atmel START die Treiber zusammen die man braucht und generiert sich den Code, fertig. Schon kann man mit dem eigentlichen Programm loslegen, ohne sich um die Zicken der HW kümmern zu müssen. Es gibt auch einen Treiber um die Stio auf UART umzuleiten. Dann wird printf automatisch auf UART gesendet. Wenn man ein Eval-board verwendet läuft was auch komplett ohne ext. verdrahtung. Ich schreibe den Code eigentlich inzwischen nur noch auf Eval-Boards und flash dann nur für den finalen Test auf die Produkt-HW. Die Eval Boards kosten 20-40€ und bieten eine Menge Tools zum effektiven Debugging. Der HW-Debugger ist sogar mit auf dem Eval Board. Man muss nur USB anschließen, fertig. Hier gibts ein ganz gutes Video für Anfänger von Atmel: https://www.youtube.com/watch?v=ZspmSNvIs80&list=PLtQdQmNK_0DS3K9jIyPPMc9m6Tjobtj3d Die benutzen dieses Eval-Board: http://www.mouser.de/ProductDetail/Microchip-Technology-Atmel/ATSAMD21-XPRO/?qs=sGAEpiMZZMsn4IaorHFpMP%2fArXsMMWNXI3mJBNZTqeI%3d > Wenn der Prozess schneller ist als die Kommunikation legt man sich eben > einen Tracebuffer an, den man auf irgend ein Signal hin, intern, oder > extern, fuellt. Und nachher per Seriell ausliest. > Allenfalls baut man sich einen Addon-Print, der einen oder mehrere 8 > fach DACs einthaelt, auf die man dann Prozessvariablen schreibt, und mit > einem Oszilloskop verfolgen kann. Dafür gibt es den Data Visualizer. Der kann einem über diverse Kanäle (Dig IO, SPI, i2C) Daten aus der SW ins Atmel Studio bringen.
Hi >ich nehm auch in der Regel lieber 32-Bit oder ARM-Prozessoren,... Du schweifst massiv vom Thema ab: Der TO Schrieb >1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie >Debuggen kann? ... Es geht hier eindeutig um AVRs. MfG Spess
spess53 schrieb: > Hi > >>ich nehm auch in der Regel lieber 32-Bit oder ARM-Prozessoren,... > > Du schweifst massiv vom Thema ab: Fragen TO: >"3. Ich habe gelesen dass DebugWire wohl sehr umständlich sein soll und >man lieber sein Projekt erstmal auf nem Dickeren µC machen soll um >ordentlich debuggen zu können und dann alles auf den kleinen µC umbauen >soll. Stimmt das? und warum?" Genau deswegen nehm ich keine kleinen 8-Bitter wenn ich nicht muss. Ich weiß es gibt Leute die aus Ergeiz/Herausforderung oder was auch immer einen möglichst komplexen Code auf einen möglichst kleinen µC stopfen wollen, aber nicht alle Teilen diese Leidenschaft. Ich will für meinen Teil z.B. das der Code mit minimal möglichen Entwicklungsaufwand das tut, was ich brauche. Ich hab zu wenig Zeit um um einzelne Bytes Ram zu feilschen, wenn ich für 0,50€ einfach doppelt so viel kaufen kann. >"4. Ich bin ein Fan von tutorials, da kann man sich einlesen und alles >ausprobieren und lernt viel....Und man braucht nicht dumm fragen. Leider >habe ich zu dem Thema leider nichts gefunden oder wenn dann nur auf >English, aber die dann auch teilweise sehr unverständlich. Kennt da >einer ein Gutes Tutorial oder ne Gute Anleitung?" Zu dem Prozessor gibts numal ein gutes Tutorial-Video. > > Der TO Schrieb > >>1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie >>Debuggen kann? ... > > Es geht hier eindeutig um AVRs. Ja ich weiß die AVR-Fanatiker reagieren algerisch auf ARM, PIC, STM usw. Ein offensichtlicher Neuling muss aber nicht unbedingt in der Steinzeit anfangen. Gibt viele gute Alternativen. Neulinge landen nur eben immer bei AVR, weil die ersten 100 Ergbnisseiten bei google nix anderes kennen. Es gibt auch eine Handvoll Eval-boards für AVR mit dem embedded Debugger, aber wenn man das Tutorial 1:1 nachmachen möchte sollte man vielleicht eine ähnliche Platform nehmen.
:
Bearbeitet durch User
Fabian F. schrieb: > Ich > weiß es gibt Leute die aus Ergeiz/Herausforderung oder was auch immer > einen möglichst komplexen Code auf einen möglichst kleinen µC stopfen > wollen Das dürften nur absolute Einzelfälle sein. Vielmehr sind folgende Gründe ausschlaggebend. 1. Man hat eine Idee und will damit nicht erst warten, bis die Platine geroutet, geätzt, gebohrt und bestückt ist. Sondern man greift sich ne Rasterplatine und pappt den DIP-8,-14 oder -28 Sockel drauf und die geplante Peripherie. Und wenn man Fehler entdeckt (was die Regel ist) lötet man die entsprechenden Schaltungsteile einfach um. Da ist es auch kein Problem, wenn der neue IC eine völlig andere Pinbelegung hat und eine andere Außenbeschaltung braucht. 2. Man hat mit einer Toolchain bereits Erfahrung und will sich zusätzliche Einarbeitungszeit für eine neue Toolchain sparen. Und auch die Zeit, um die Fallgruben der neuen MC-Familie kennen zu lernen. 3. Manche fühlen sich aber einfach nur von den vielen Modies und Einstellungen der 32Bit-Boliden wie erschlagen. Oftmals hat man bei denen auch nicht alle Informationen in einer einzigen Datasheet, wie bei den AVRs. Sondern man hat zusätzliche Manuals, die aber viele Derivate abdecken, d.h. die Sachen enthalten, die auf das konkrete Derivat nicht zutreffen.
Peter D. schrieb: > 1. > Man hat eine Idee und will damit nicht erst warten, bis die Platine > geroutet, geätzt, gebohrt und bestückt ist. Ich bin inzwischen dazu übergegangen für so was Eval-Boards zu nutzen. Das Board an dem ich grad arbeite hat 3 20-Polige Header an denen Diverse IO nach außen geführt ist. Außerdem ist oben noch ein Arduino-Shield-kompatibler Header drauf. Da kann man sich dann als Sandwich oben einfach eine Lochraster-platine drauf machen. Hat den Vorteil, das man sich nicht jedes mal von neuem mit Vcc, ARef, Ozillator & Co rumärgern muss. Wenn ich ein anderes Projekt angehe, Steck ich die Lochraster-Platine wieder ab und mach eine andere drauf. > 2. > Man hat mit einer Toolchain bereits Erfahrung und will sich zusätzliche > Einarbeitungszeit für eine neue Toolchain sparen. Und auch die Zeit, um > die Fallgruben der neuen MC-Familie kennen zu lernen. Macht zu einem Gewissen grad Sinn bei einer bekannten Platform zu bleiben. Bis zum Sankt Nimmerleinstag dort zu verharren und alle Neuerungen zu ignorieren ist aber auch nicht was Wahre. Ich hab Jahrelang mit diversen 8-Bittern von Atmel oder PIC gearbeitet. Der erste Schritt zu HW mit HW-treibern war auch schwierig, wenn man in Projekten die Zeit im Nacken hat, aber als ich mich dann privat mal 2 Tage damit beschäftigt habe ist mir aufgefallen, dass es eigentlich nicht komplizierter ist (Im Fall vom CAN& Ethernet sogar viel einfacher). Außerdem ist es durch die Astraktion von HW über genertische IO-Zugriffe super einfach Programme in Teilen oder als ganzes von einer Platform zur anderen zu portieren. > 3. > Manche fühlen sich aber einfach nur von den vielen Modies und > Einstellungen der 32Bit-Boliden wie erschlagen. > Oftmals hat man bei denen auch nicht alle Informationen in einer > einzigen Datasheet, wie bei den AVRs. Sondern man hat zusätzliche > Manuals, die aber viele Derivate abdecken, d.h. die Sachen enthalten, > die auf das konkrete Derivat nicht zutreffen. Es gibt auch "kleine" ARMs und 32-Bitter (z.B. SAMD10) mit einer sehr übersichtlichen IO. Da Passen alle Informationen in 100 Seiten. Außerdem muss man sich wg. der HW-Treiber ohnehin kaum mit den Registern&Co des µC beschäftigen.
:
Bearbeitet durch User
Thomas E. schrieb: > Dein Geschwätz ist überflüssig. Naja, so galant kann man natürlich auch ausdrücken, dass man noch Anfänger ist... Wenn es dir vorkommt, als wäre ein HW-Debugger nützlich, hast du noch nie die AVRs richtig ausgenutzt, sondern nur Kinderkram damit gespielt. Und solchen Kinderkram kann man, wie schon gesagt, viel besser, einfacher und komfortabler im Simulator debuggen. Mit ein bissel eigenem Einsatz (nämlich der Bereitstellung entsprechender Stimuli-Dateien) kann man im Simulator aber sogar noch sehr viel mehr tun. Genau das macht ihn so unendlich viel mächtiger als einen HW-Debugger. Damit kann man dann sogar komplexe Echtzeit-Routinen sinnvoll debuggen, z.B. auch die von P.Dannegger hier im Thread (vollkommen zu Recht) als ziemlich problematisch angeführten Regler. Ganz allgemein: alle Hardware, die mit der Software in Form einer geschlossenen Schleife interagiert (besonders, wenn das auch noch sehr schnell passiert). Dabei hilft einem ein HW-Debugger nämlich exakt garnix. Das Problem ist, zu den Stimuli-Dateien zu kommen. Und auch da hilft leider ein HW-Debugger kein bissel, das muss man selbst mittels entsprechend abgeänderter Programmversionen erledigen, die die Daten der Fehlversuche erstmal irgendwie Richtung PC ausleiten. Bei richtig schnellen Anwendungen an der Leistungsgrenze der AVRs ist aber sogar allein das schon ein erhebliches Problem, aber meistens doch noch irgendwie realisierbar, notfalls, indem man andere Teile der Anwendung dafür lahmlegt. Naja, das sind halt so Sachen, die Leute machen, die eben keine Anfänger mehr sind. Und die wissen dann auch, dass so ein HW-Debugger bei allen wirklich schwierigen Problemen de facto vollkommen nutzlos ist...
c-hater schrieb: > Naja, das sind halt so Sachen, die Leute machen, die eben keine Anfänger > mehr sind. Und die wissen dann auch, dass so ein HW-Debugger bei allen > wirklich schwierigen Problemen de facto vollkommen nutzlos ist... Ja, aber meiner ist länger als deiner.
c-hater schrieb: > Thomas E. schrieb: > >> Dein Geschwätz ist überflüssig. > Wenn es dir vorkommt, als wäre ein HW-Debugger nützlich, hast du noch > nie die AVRs richtig ausgenutzt, sondern nur Kinderkram damit gespielt. Oder man hat schonmal mit Prozessoren gearbeitet die keine AVRs sind. Von den meisten high-Power-µCs gibts keine Simulatoren. > Das Problem ist, zu den Stimuli-Dateien zu kommen. Und auch da hilft > leider ein HW-Debugger kein bissel, das muss man selbst mittels > entsprechend abgeänderter Programmversionen erledigen, die die Daten der > Fehlversuche erstmal irgendwie Richtung PC ausleiten. Ja ich ich kann mir stundenland duzende von printfs in den Code packen und dann einen kompletten Fahzeugbus in Software nachprogrammieren, oder ich kann einfach an ein paar kritischen Punkten (z.B. Rx-Interrupt, watchdog interrupt, Counter-wert) ein paar Breakpoints setzen und seh in wenigen Sekunden wo es hängt...
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.