Moin moin zusammen, ich würde gerne etwas debugging mit meinem ATmega16 betreiben zusammen mit dem AVR Studio. So, erstes Problem ist dass ich zwar mit meinem Ponyprog ja flashen kann, über RS232 COM1 etc., also eine Verbindung aufbauen kann, aber mit dem AVR Studio keine Verbindung aufbauen kann. Ähm, geht das überhaupt dass man sich mit dem Controller verbindet und Register ausliest etc.? Oder wird einfach nur der Code simuliert und ich kann Schritt für Schritt den Code debuggen? Zweite Frage, bei der Prozessor-Frequenz kann ich nur maximal 8 MHz einstellen?! Der Proz. taktet auf 16MHz, ist auch im Makefile so richtig eingetragen. Drittes Problem, die Funktion AutoStep läuft etwas schnell ab, hier kann man nirgendswo etwas umstellen dass dies langsamer abläuft? Gruß, MG
Marten Mcgonahy schrieb: > > So, erstes Problem ist dass ich zwar mit meinem Ponyprog ja flashen > kann, über RS232 COM1 etc., also eine Verbindung aufbauen kann, aber mit > dem AVR Studio keine Verbindung aufbauen kann. Vermutlich hast du keinen Programmer (da RS232) der mit AVR-Studio zusammenarbeitet. Dafür müsstest du dann z.B. AVRISP, AVR JTAG ICE, Dragon o.Ä. haben > Ähm, geht das überhaupt > dass man sich mit dem Controller verbindet und Register ausliest etc.? Ja das geht, aber nur mit JTAG > Zweite Frage, bei der Prozessor-Frequenz kann ich nur maximal 8 MHz > einstellen?! Der Proz. taktet auf 16MHz, ist auch im Makefile so richtig > eingetragen. Wo kannst du nur 8 MHz einstellen? Der AVR hat einen internen Oszillator der bis 8 MHz geht und extern kannst du bis 16 MHz anschließen, aber du musst in den Fuses auch einstellen, dass er nen externen Quarz verwenden soll
Marten Mcgonahy schrieb: > Drittes Problem, die Funktion AutoStep läuft etwas schnell ab, hier kann > man nirgendswo etwas umstellen dass dies langsamer abläuft? Dafür gibt es Break Points. Die runden Symbole oben rechts. Da stoppt der automatische Progammlauf. Dann kann man sich die Variablen etc. anschauen und weiter gehts mit Auto Run zum nächsten Break Point. Axel
Timmo H. schrieb: >> So, erstes Problem ist dass ich zwar mit meinem Ponyprog ja flashen >> kann, über RS232 COM1 etc., also eine Verbindung aufbauen kann, aber mit >> dem AVR Studio keine Verbindung aufbauen kann. > Vermutlich hast du keinen Programmer (da RS232) der mit AVR-Studio > zusammenarbeitet. Dafür müsstest du dann z.B. AVRISP, AVR JTAG ICE, > Dragon o.Ä. haben > >> Ähm, geht das überhaupt >> dass man sich mit dem Controller verbindet und Register ausliest etc.? > Ja das geht, aber nur mit JTAG Ok, hab verstanden, das Ganze funzt also nur mit zusätzlichem Aufwand. Timmo H. schrieb: > Wo kannst du nur 8 MHz einstellen? Der AVR hat einen internen Oszillator > der bis 8 MHz geht und extern kannst du bis 16 MHz anschließen, aber du > musst in den Fuses auch einstellen, dass er nen externen Quarz verwenden > soll 8 MHz in der Simulatin von AVR Studio. Sprich die ganzen Zeiten passen ja nicht mit den realen Zeiten zusammen?! Die Fuses im Controller sind richtig gesetzt, aber das ist ja unabhängig von AVR-Studio, da sie hardwaretechnisch nicht miteinander sprechen. Ich müsste also im Studio auf 16MHz einstellen können, um die richtigen Zeiten etc. zu sehen?!
Düsendieb schrieb: > Marten Mcgonahy schrieb: >> Drittes Problem, die Funktion AutoStep läuft etwas schnell ab, hier kann >> man nirgendswo etwas umstellen dass dies langsamer abläuft? > > Dafür gibt es Break Points. Die runden Symbole oben rechts. > > Da stoppt der automatische Progammlauf. Dann kann man sich die Variablen > etc. anschauen und weiter gehts mit Auto Run zum nächsten Break Point. Ok, danke... Eigentlich genau so wie bei Visual Studio, da hatte ich mal was getan vor langer Zeit...
Marten Mcgonahy schrieb: > 8 MHz in der Simulatin von AVR Studio. Sprich die ganzen Zeiten passen > ja nicht mit den realen Zeiten zusammen?! Die Fuses im Controller sind > richtig gesetzt, aber das ist ja unabhängig von AVR-Studio, da sie > hardwaretechnisch nicht miteinander sprechen. Ich müsste also im Studio > auf 16MHz einstellen können, um die richtigen Zeiten etc. zu sehen?! Das wäre dann eine "Emulation" und würde entsprechend teurer verkauft werden. Du hast mit dem AVRStudio nur einen Simulator bekommen. Dafür aber auch umsonst.
Huch schrieb: >> 8 MHz in der Simulatin von AVR Studio. Sprich die ganzen Zeiten passen >> ja nicht mit den realen Zeiten zusammen?! Die Fuses im Controller sind >> richtig gesetzt, aber das ist ja unabhängig von AVR-Studio, da sie >> hardwaretechnisch nicht miteinander sprechen. Ich müsste also im Studio >> auf 16MHz einstellen können, um die richtigen Zeiten etc. zu sehen?! > > Das wäre dann eine "Emulation" und würde entsprechend teurer verkauft > werden. > Du hast mit dem AVRStudio nur einen Simulator bekommen. Dafür aber auch > umsonst. Ok, ich habs verstanden, Simulator ok ohne großen Aufwand, wirkliche echte Zustände bekomm ich nur mit zusätzlicher Hardware und Kosten. Ich versuch mir gerade heraus zu rechnen, wie oft er in meine ISR reinspringt, rechnerisch und durch die Beobachtung der Simulation. Das stimmt nicht wirklich überein: Theorie: Ich hab einen 8Bit Zähler und der Prozessor taktet mit 8MHz, sprich (8MHz/256)^(-1) wäre dann die Zeit wo der Interupt ausgelöst wird. Also 32us theoretisch. In der Simulation sind die Zeiten jedoch etwas anders. Für die Zeit in der Simulation, ist hier wichtig wann er zur ISR springt, oder wann das I-Bit im SREG gesetzt wird? Beispiel, das I-Bit wird gesetzt, dann spring der Ablauf in die ISR, arbeitet ab, dann nach XXX us wird wieder I-Bit gesetzt...
> In der Simulation sind die Zeiten jedoch etwas anders. Da müsste man mal genau klarstellen, wie Du das Auslösen des Interrupts definierst und/oder in der Simulation feststellst. Ich nehme an Du setzt einen Breakpoint auf den ISR-Vektor. Das wäre der früheste Zeitpunkt wo der Simulator eingreifen kann. Ich bin mir nicht sicher ob das bei allen AVRs gleich ist, habe aber gerade heute morgen beim 644P gelesen, das minimal 5 Taktzyklen vergehen, bis der Interruptvektor angesprungen wird. Falls beim Eintreten des auslösenden Ereignisses ein Doppel-Wort-Befehl ausgeführt wird, noch zwei Zyklen mehr. So gibt es eine Reihe von Faktoren, die beeinflussen wieviel Zeit zwischen dem Eintreten des Ereignisses und dem anspringen des Interrupt-Vektors vergeht. Z.b. werden manche externe Auslöser noch gesampelt und zwischengespeichert. Bitte lies das im Datenblatt nach. Ausserdem ist die Simulation gerade, aber nicht nur, in dieser Hinsicht mit Vorsicht zu geniessen. Gerade weil, sowieso keine Echtzeitkopplung möglich ist, hat es den Autoren wahrscheinlich gereicht, dass das meiste "im Prinzip" geht aber es musste nicht den wirklichen Verhältnissen beim realen Prozessor 1 zu 1 entsprechen.
Nach meinen Kenntnissen werden die Takte richtig simuliert, nur eben nicht die Zeit, die zwischen 2 Takten vergeht. D.h. wenn du also z.B einen Zähler mit 8Mhz taktest und dieser teilt durch 255 so wird dieser nach 8.000.000 /255 Takten seinen IRQ in der simulation auslösen. Du müsstest dann die Anzahl der vergangenen Takte wieder in die reale Zeit umrechnen, die hast du ja durch den 8 Mhz Takt vorgegeben.
rogie schrieb: > Nach meinen Kenntnissen werden die Takte richtig simuliert, nur eben > nicht die Zeit, die zwischen 2 Takten vergeht. D.h. wenn du also z.B > einen Zähler mit 8Mhz taktest und dieser teilt durch 255 so wird dieser > nach 8.000.000 /255 Takten seinen IRQ in der simulation auslösen. > > Du müsstest dann die Anzahl der vergangenen Takte wieder in die reale > Zeit umrechnen, die hast du ja durch den 8 Mhz Takt vorgegeben. Die Taktanzahl mit der Taktzeit (1/8MHz) entspricht der angezeigten Zeit, also man muss es nicht extra berechnen, wenn du das meinst?! @Huch, ja irgendwie ist das ganze Thema mit den Zeiten etwas ausschweifender, ich dachte man kann es mal "schnell schnell" sich anschauen ob das so passt was man ausrechnet. Also bleib ich bei der Daumenformel, der Interrupt wird bei einem 8-Bit Counter ohne Vorteilung alle 32us ausgelöst...fertig. Zu gern hätt ich das ganze mit der Simulation nachvollzogen :-(
rogies Antwort läßt mich zweifeln ob ich Deine Frage richtig verstanden habe, Marten. > Für die Zeit in der Simulation, ist hier wichtig wann er > zur ISR springt, oder wann das I-Bit im SREG gesetzt wird? Beispiel, das > I-Bit wird gesetzt, dann spring der Ablauf in die ISR, arbeitet ab, dann > nach XXX us wird wieder I-Bit gesetzt Die Simulation hat ja, wie Du vielleicht schon gesehen hast einen Taktzähler und auch eine Zeitanzeige. Die Simulation ist langsamer als unsere Zeitskala. Wenn bei uns 1 Sekunde vergangen ist, dann ist im Simulator erst eine halbe vergangen (ich weiss den Faktor nicht mal, jedenfalls langsamer). Wahrscheinlich ist Dir das klar, aber ich bin eben nicht sicher ob ich verstehe wonach Du fragst. Wichtig ist für die Simulation garnichts. Sie tut einfach. Schritt für Schritt. Ob hingegen wir die Reaktion auf ein Ereignis dann als gegeben nehmen wenn das Flag gesetzt ist oder wenn die ISR angesprungen wird ist reine Definitionssache. Die Simulation ist (mit den schon oben genannten Einschränkungen) folgerichtig und stetig. Erst kommt das Ereignis, dann die "Kenntnisnahme", dann die Reaktion.
Hi >Zweite Frage, bei der Prozessor-Frequenz kann ich nur maximal 8 MHz >einstellen?! Der Proz. taktet auf 16MHz, ist auch im Makefile so richtig >eingetragen. Für den Takt kannst du im AVR-Studio jeden manuell Wert eintragen. MfG Spess
Marten Mcgonahy schrieb: > Zu gern hätt ich > das ganze mit der Simulation nachvollzogen :-( Ich denke das geht: 1. Setze einen Breakpoint auf den Interrupt-Vektor. 2. Lass die Simulation laufen bis das erste Mal unterbrochen wird. 3. Notiere Dir die Zeit (und evtl. die Anzahl der Taktzyklen) 4. Lass das Programm weiterlaufen bis wieder unterbrochen wird. 5. Bilde jetzt die Differenz der Zeit bzw. der Taktzyklen. Das Ergebnis sollte den 32us entsprechen. Allerdings sind, wie schon gesagt, gewisse Abweichungen möglich, wegen evtl. 2-Wort-Befehle.
Ohje, ich hoffe ich habe da nichs verwurstelt. Ich dachte Du meinst, Du könntest in Echtzeit simulieren. Deswegen: " Sprich die ganzen Zeiten passen ja nicht mit den realen Zeiten zusammen?!" Aber Du hast nur das Problem gehabt, wie Du 16MHz in der Simulation einstellen kannst. Mit "real" meintest Du die Zeiten bei 16MHz die Du aber nicht simulieren konntest, weil die Frequenz im Simulator auf 8MHz eingestellt war. Richtig?
Puh...ja nicht dass wir hier aneinander vorbeireden... spess53 schrieb: > Hi > >>Zweite Frage, bei der Prozessor-Frequenz kann ich nur maximal 8 MHz >>einstellen?! Der Proz. taktet auf 16MHz, ist auch im Makefile so richtig >>eingetragen. > > Für den Takt kannst du im AVR-Studio jeden manuell Wert eintragen. > > MfG Spess Ahhhh...ok, ich merks erst jetzt, man kann es manuell einstellen...super, danke! Huch schrieb: > Ich denke das geht: > > 1. Setze einen Breakpoint auf den Interrupt-Vektor. > 2. Lass die Simulation laufen bis das erste Mal unterbrochen wird. > 3. Notiere Dir die Zeit (und evtl. die Anzahl der Taktzyklen) > 4. Lass das Programm weiterlaufen bis wieder unterbrochen wird. > 5. Bilde jetzt die Differenz der Zeit bzw. der Taktzyklen. > > Das Ergebnis sollte den 32us entsprechen. Allerdings sind, wie schon > gesagt, gewisse Abweichungen möglich, wegen evtl. 2-Wort-Befehle. Ok, ja so hätte ich es mir ja auch vorgestellt und gemacht, wobei, bei Interrupt-Vektor meinst du den Routine in der die Anweisungen stehen, also Bsp. "ISR(TIMER1_COMPA_vect) {Anweisungen...}"? Das is die eine Möglichkeit. Zur Info, den "Stop Watch" kann man auf 0 setzen seh ich grad :-) Was ist jedoch mit dem Bit "I" im SREG, kann man auch nach diesem gehen, also Zeit auf t=0us stellen wenn Interrupt-Bit gesetzt, dann bis zum nächsten Setzen warten und Zeit ablesen?! Oder hat das Statusbit hier nix mit zu tun?
Huch schrieb: > Ohje, ich hoffe ich habe da nichs verwurstelt. > > Ich dachte Du meinst, Du könntest in Echtzeit simulieren. Deswegen: " > Sprich die ganzen Zeiten passen ja nicht mit den realen Zeiten > zusammen?!" > > Aber Du hast nur das Problem gehabt, wie Du 16MHz in der Simulation > einstellen kannst. Mit "real" meintest Du die Zeiten bei 16MHz die Du > aber nicht simulieren konntest, weil die Frequenz im Simulator auf 8MHz > eingestellt war. > > Richtig? Ja das war nur ein Problem, aber das andere besteh weiterhin :-)
>wobei, bei >Interrupt-Vektor meinst du den Routine in der die Anweisungen stehen, >also Bsp. "ISR(TIMER1_COMPA_vect) {Anweisungen...}"? Das is die eine >Möglichkeit. Hmmm. Bei sowas würde ich immer auf Assembler Ebene einen Breakpoint setzen. Aber gut. Theoretisch sollte das so gehen. >Zur Info, den "Stop Watch" kann man auf 0 setzen seh ich grad Ach! ;-) >Was ist jedoch mit dem Bit "I" im SREG, kann man auch nach diesem gehen, >also Zeit auf t=0us stellen wenn Interrupt-Bit gesetzt, dann bis zum >nächsten Setzen warten und Zeit ablesen?! Oder hat das Statusbit hier >nix mit zu tun? Das I-Bit im SREG erlaubt bzw. verbietet Interrupts. Es wird nicht gesetzt oder gelöscht, wenn ein Interrupt auftritt. Aber Du meinst wahrscheinlich die entsprechenden Bits in den Interrupt-Quellen (Timer, UART etc.). Im Grunde ist es egal ob Du einen Programmbreakpoint nimmst oder eine Interrupt-Flag-Aenderung. Hauptsache Du nimmst zweimal das selbe Kriterium.
Huch schrieb: > Das wäre dann eine "Emulation" und würde entsprechend teurer verkauft > werden. Es gibt VMLAB. Das ist nicht perfekt, aber dafür kostenlos, und wenn man es einmal vertanden hat, liefert es unerreichte Einblicke in den Ablauf eines Programms. Gerade die Darstellung von zeitlichen Abläufen mit ISR's usw. geht damit hervorragend. Oliver
Oliver schrieb: > Huch schrieb: >> Das wäre dann eine "Emulation" und würde entsprechend teurer verkauft >> werden. > > Es gibt VMLAB. VMLAB ist kein Emulator sondern ein Simulator.
Huch schrieb: > Hmmm. Bei sowas würde ich immer auf Assembler Ebene einen Breakpoint > setzen. > Aber gut. Theoretisch sollte das so gehen. Ja ich arbeite auf Programmebene in C, ich hatte ja mal Assembler Programmierung mit einem C167, möchte mich jedoch Privat mal an C-Programmierung hinschtlich uC gewöhnen. Oliver schrieb: > Es gibt VMLAB. Das ist nicht perfekt, aber dafür kostenlos, und wenn man > es einmal vertanden hat, liefert es unerreichte Einblicke in den Ablauf > eines Programms. Gerade die Darstellung von zeitlichen Abläufen mit > ISR's usw. geht damit hervorragend. > > Oliver Muss ich mir bei Gelegenheit mal anschauen. Es ist jetzt nicht so dass es ultrawichtig für ein Projekt ist, aber um es zu verstehen und die Zeiten nachvollziehen zu können schadet es sicher nicht, speziell wenn ich mal wirklich bei zeitkritischen Programmen dran hänge. ICh hab mich jetzt überhaupt erst mal mit dem AVR STudio beschäftigt, weil es probleme mit einem Programm gibt, wo ein LCD dran hängt, aber ich kein Oszi hab.
Marten Mcgonahy schrieb: > Huch schrieb: >> Hmmm. Bei sowas würde ich immer auf Assembler Ebene einen Breakpoint >> setzen. >> Aber gut. Theoretisch sollte das so gehen. > > Ja ich arbeite auf Programmebene in C, ich hatte ja mal Assembler > Programmierung mit einem C167, möchte mich jedoch Privat mal an > C-Programmierung hinschtlich uC gewöhnen. Du kanns ruhig weiter in C programmieren. Nur im AVRStudio-Simulator debugged es sich oft leichter, wenn man in den Disassembler-View wechselt (das viereckige Fenster Icon mit der Lupe; oder über das 'View'-Menü). Da hat man dann den C-Code gemixed mit dem daraus entstandenen Maschinencode.
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.