mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR Studio 4 v4.18


Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Düsendieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: rogie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marten Mcgonahy (mcgonahy148)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.