Bisher habe ich mit dem zugegebenermaßen veralteten AVR Studio 4.18 gearbeitet und war eigentlich auch ganz zufrieden. Der original JTAGICEmkII funktioniert damit ganz hervorragend - gleichzeitig zum Programmieren und Debuggen. Nun ergab sich die Programmieraufgabe bei einem ATMega128 mit dem 16Bit-Timer/Counter2 ein wenig herum zu experimentieren - in Assembler. Dabei ist mir aufgefallen, dass z.B. Ladebefehle mit "sts OCR3AH, wertH" und gleich darauf folgend "sts OCR3AL, wertL" zwar ausgeführt, aber beim Debuggen mit dem Simulator nicht angezeigt werden, bzw. erst merkwürdigerweise nach dem Eintritt in eine damit zusammenhängende ISR. Da der Code beim Compilieren nicht bemeckert wurde, gehe ich von einer exakten Ausführung aus. Eine Überprüfung mit der Debuggerfunktion des JTAGICEmkII an einem Test-Board ergab jedoch das gleiche Ergebnis, wobei ich dabei davon ausgehe, dass durch die JTAG-Funktion die wahren Registerinhalte angezeigt werden. In einigen früheren Forenbeiträgen wurde schon von diversen Bugs im AVR-Studio berichtet, so dass ich mir jetzt nicht so recht sicher bin, was ich von diesem Effekt halten soll, bzw. wie ich das Problem umgehen kann. Eine mögliche Abhilfe sehe ich im Umstieg auf das neueste AVR-Studio V6.1, wo doch dann alle diese Bugs beseitigt sein sollten - oder? Andererseits habe ich nun auch wieder gelesen, dass es damit diverse andere Probleme gibt - auch im Zusammenhang mit dem JTAGICEmkII. Ist es eigentlich möglich beide Versionen auf einem PC (32er XP) parallel installiert zu betreiben, oder "beharken" die sich gegenseitig? Was müßte ich sonst noch bedenken/beachten? Grüsse aus Berlin PSblnkd
Niemand eine Meinung dazu? Ich hoffe doch nicht, dass mein Ansinnen zu abwägig ist, oder dass sich noch niemand mit gleichen oder ähnlichen Problemen rumgeschlagen hat... Grüsse aus Berlin PSblnkd
Hi, PSblnkd schrieb: > Ist es eigentlich möglich beide Versionen auf einem PC (32er XP) > parallel installiert zu betreiben, oder "beharken" die sich gegenseitig? > Was müßte ich sonst noch bedenken/beachten? die 6.1er und 4.x beißen sich nach meinen Erfahrungen nicht. Wie der Simulator in 6.1 im Vergleich zu 4.x ist weiß ich nicht, weil ich sie nur äußerst selten nutze. Der Umstieg auf Atmel Studio > 4 lohnt sich für C-Programmierer auf jeden Fall, da die Programmierunterstützung deutlich besser als im alten ist - bei Assembler sieht es allerdings ähnlich wie im 4er aus, Syntax highlighting ja, Vervollständigung nein. HTH
PSblnkd schrieb: > Nun ergab sich die Programmieraufgabe bei einem ATMega128 mit dem > 16Bit-Timer/Counter2 ein wenig herum zu experimentieren - in Assembler. > Dabei ist mir aufgefallen, dass z.B. Ladebefehle mit "sts OCR3AH, wertH" > und gleich darauf folgend "sts OCR3AL, wertL" zwar ausgeführt, aber beim > Debuggen mit dem Simulator nicht angezeigt werden, bzw. erst > merkwürdigerweise nach dem Eintritt in eine damit zusammenhängende ISR. > Da der Code beim Compilieren nicht bemeckert wurde, gehe ich von einer > exakten Ausführung aus. > Eine Überprüfung mit der Debuggerfunktion des JTAGICEmkII an einem > Test-Board ergab jedoch das gleiche Ergebnis, wobei ich dabei davon > ausgehe, dass durch die JTAG-Funktion die wahren Registerinhalte > angezeigt werden. Dann läuft dein Timer wohl in einem PWM-Modus. PSblnkd schrieb: > In einigen früheren Forenbeiträgen wurde schon von diversen Bugs im > AVR-Studio berichtet, so dass ich mir jetzt nicht so recht sicher bin, > was ich von diesem Effekt halten soll, bzw. wie ich das Problem umgehen > kann. Das ist weder ein "Bug", noch sonst irgendwie ein "Problem", sondern ein gewolltes Feature der Hardware. Datenblatt lesen hilft hier weiter.
Hi >Nun ergab sich die Programmieraufgabe bei einem ATMega128 mit dem >16Bit-Timer/Counter2 ein wenig herum zu experimentieren - in Assembler. >Dabei ist mir aufgefallen, dass z.B. Ladebefehle mit "sts OCR3AH, wertH" >und gleich darauf folgend "sts OCR3AL, wertL" zwar ausgeführt, aber beim >Debuggen mit dem Simulator nicht angezeigt werden, Scheint ein Fehler im Simulator2 zu sein. Im Simulator funktioniert es. >Eine mögliche Abhilfe sehe ich im Umstieg auf das neueste AVR-Studio >V6.1, wo doch dann alle diese Bugs beseitigt sein sollten - oder? Dieser Bug ist behoben. >Ist es eigentlich möglich beide Versionen auf einem PC (32er XP) >parallel installiert zu betreiben, Du kannst sogar beide Studios gleichzeitig laufen lassen. >oder "beharken" die sich gegenseitig? Nein. MfG Spess
Hi, Du kannst zwar beide installiert haben und auch nutzen, aber: Um damit Deinen JTAG ICE mkII benutzen zu können musst beim jedem Wechsel zwischen beiden Versionen ein Firmware-Update / -Downgrade durchführen. AVRStudio 6 benötigt eine aktuelle Firmware, AVRStudio 4 funktioniert nur mit einer älteren Version... Gruß Chris PS: AFAIK ist AVRStudion 4.19 b730 die letzte/aktuelle Version - vllt. ist da ja schon der Fehler behoben worden.
Hi >AFAIK ist AVRStudion 4.19 b730 die letzte/aktuelle Version - vllt. ist >da ja schon der Fehler behoben worden. Nein, damit habe ich das getestet. AVR Studio 4.19 ist mW. AVR Studio 4.18 + Service Packs. MfG Spess
Danke für Eure wertvollen Hinweise! @Stefan Ernst Ja, das ist richtig - im Modus 11. Aber bitte wo steht das mit dem "gewollten Feature der Hardware"? Bei der Kompliziertheit der 16Bit-Timer/Counter des ATmega128 bin ich mir eben auch nicht ganz sicher, ob ich da was übersehen habe. @spess53 Richtig - im 1. Simulator werden die Einträge angezeigt, aber da funktioniert wieder Anderes nicht (Interupts) und ATMEL empfiehlt immer den Simulator2. @Christoph H. Das mit den inkompatiblen Firmware-Updates/Downgrades zum JTAGICEmkII ist sehr ärgerlich. Außerdem kommt wohl noch hinzu, dass einmal im Studio 6 compilierte Projekte nicht mehr zurück ins Studio 4 geladen werden können - habe ich irgendwo gelesen... Der erste Versuch zur 6er Version AVR-Studio zu kommen ist schon mal fehlgeschlagen. Obwohl ich die Firmen-eMail-Adresse benutzt habe, konnte die Verifizierung des myATMEL-Accounts nicht abgeschlossen werden, da der automatisch zugeschickte Link nicht gültig ist. Eine diesbzügliche Nachfrage beim webmaster@atmel.com blieb bisher ohne Antwort... Werde es nochmal mit einer anderen eMail-Adresse versuchen. Grüsse aus Berlin PSblnkd
PSblnkd schrieb: > Ja, das ist richtig - im Modus 11. > Aber bitte wo steht das mit dem "gewollten Feature der Hardware"?
1 | The OCRnx Register is double buffered when using any of the twelve Pulse Width Modulation |
2 | (PWM) modes. For the normal and Clear Timer on Compare (CTC) modes of operation, the double |
3 | buffering is disabled. The double buffering synchronizes the update of the OCRnx Compare |
4 | Register to either TOP or BOTTOM of the counting sequence. The synchronization prevents the |
5 | occurrence of odd-length, non-symmetrical PWM pulses, thereby making the output glitch-free. |
PSblnkd schrieb: > Richtig - im 1. Simulator werden die Einträge angezeigt Es geht nicht um ja/nein (angezeigt), sondern um das WANN. Wenn du sofort nach dem Schreiben der Werte diese in der Registeransicht siehst, dann ist das falsch (ein Bug). PSblnkd schrieb: > und ATMEL empfiehlt immer > den Simulator2. Der liegt ja auch in diesem Fall richtig.
Hi >Es geht nicht um ja/nein (angezeigt), sondern um das WANN. Wenn du >sofort nach dem Schreiben der Werte diese in der Registeransicht siehst, >dann ist das falsch (ein Bug) Das passt schon. Der Wert taucht erst nach Beschreiben des L-Registers auf. MfG Spess
spess53 schrieb: > Das passt schon. Der Wert taucht erst nach Beschreiben des L-Registers > auf. Nein, passt eben nicht. Er darf erst auftauchen, wenn der Timer das nächste mal TOP erreicht.
Hi >Nein, passt eben nicht. Er darf erst auftauchen, wenn der Timer das >nächste mal TOP erreicht. Entschuldige. Den PWM-Mode 11 hatte ich verdrängt. Das bezog sich auf Mode0 Mal getestet: Simulator2, PWM-Mode11, Prescaler 64 Der Wert für OCR3A wird 64 Takte nach Start des Timers übernommen (1.Overflow da OCR3A=0). Danach läuft der Timer mit dem OCR-Wert. Das passt auch. MfG Spess
Zur Erklärung muss ich noch etwas dazufügen. Der TIMER_COUNTER_3 läuft mit Extern-Taktung auf der fallenden Flanke. Hier die Initial-Sequenz:
1 | ldi r26, TCCR3A |
2 | ldi r16, 0b00000011 ; WGM31 = 1, WGM30 = 1 |
3 | st X, r16 |
4 | ldi r26, TCCR3B |
5 | ldi r16, 0b00010110 ; WGM33 = 1, WGM32 = 0, CS32:30 = 110 |
6 | st X, r16 |
7 | ; |
8 | ldi r26, OCR3AH ; OCR3AH-Adresse laden, High-Teil bleibt |
9 | ldi r16, 0b00000011 ; OCR3AL mit "3" vorladen |
10 | clr r17 |
11 | st X, r17 ; 1.: R17 (High-Byte) auf OCR3AH (Adr 87) laden |
12 | st -X, r16 ; 2.: R16 (Low-Byte) auf OCR3AL (Adr 86) laden |
13 | ; |
14 | ldi r26, ETIMSK ; erweitertes Timer-Maskenregister |
15 | ld r16, X |
16 | ori r16, 0b00100000 ; Bit5: TICIE3 setzen |
17 | st X, r16 ; TCE3 freigegeben |
18 | ; |
19 | sei ; globale Interrupt-Freigabe |
20 | ; |
21 | endlos: nop |
22 | nop |
23 | nop |
24 | nop |
25 | rjmp endlos |
@Stephan Ernst Aus dem Datenblatt-Text konnte ich das nicht eindeutig herauslesen, dass die Daten-Übertragung in das Doppelregister OCR3AL/H erst beim Zählerstand TOP bzw. BOTTUM erfolgt. Meine Übersetzung (die ich mir vorsorglich schon vor langer Zeit mal für den Großteil des ATmega1128-Datenblatts gemacht hatte) lautet zu diesem Teil: "Das OCRnx-Register ist doppelt gepuffert, wenn eines der zwölf Pulse Width Modulation-Modi (PWM) verwendet wird. Für den Normal- und den Clear Timer Compare (CTC) Betriebs-Modi, ist die Doppelpufferung deaktiviert. Die Doppelpufferung synchronisiert die Aktualisierung des OCRnx Vergleich-Registers für beide Fälle, TOP- oder BOTTOM der Zähl-Sequenzen. Die Synchronisation verhindert, dass es beim Auftreten einer ungeraden Länge zu nicht-symmetrische PWM-Impulsen kommt, wodurch die Ausgabe glitch-frei wird." Vielleicht ist die Übersetzung ja nicht ganz korrekt, bzw. ich habe das nicht richtig verstanden, weil es im technischen Englisch häufig an einer präzisen Formulierung mangelt. Nun kommt noch die Betriebsart "Externe Taktung" dazu - welche Effekte sich daraus ergeben, kann man nur Rätselraten und deshalb wollte ich das ergründen. Das Vorladen des OCR3AL/H mit "3" ist eine Datenblatt-Empfehlung. Der Wert wird aber solange sich das Programm in der Endlosschleife befindet nicht angezeigt - sondern erst, wenn mit einem TC3_Capture-Interupt in die betreffende ISR gesprungen wird. Dass ich den "uralten" ATmega128 verwende, hängt einfach mit dem EvoBoard http://www.ps-blnkd.de/AVR_Development_System.pdf zusammen, was ich hierzu als Testobjekt verwende. Sicherlich wäre es noch interessanter, sich mit den XMegas zu beschäftigen - kommt noch... Ich werde nochmal einen Versuch machen, das Zähler-Doppelregister TCNT3 mit "1" vorzuladen. Dann wäre das ja außerhalb von BOTTUM (= 0) und TOP (= 3) wäre noch nicht erreicht. Der Versuch jedoch erst mit dem AS6, was ich jetzt dank einer Direkt-Downloadadresse doch noch herunterladen konnte. Grüsse aus Berlin PSblnkd
Hi > ldi r26, TCCR3A > ldi r16, 0b00000011 ; WGM31 = 1, WGM30 = 1 > st X, r16 Hat die Benutzung von X bei der Initialisierung einen tieferen Sinn? >Dass ich den "uralten" ATmega128 verwende, hängt einfach mit dem >EvoBoard http://www.ps-blnkd.de/AVR_Development_System.pdf zusammen, was >ich hierzu als Testobjekt verwende. Der ATMega1281 ist moderner und pinkompatibel zu ATMega128. MfG Spess
@ spess53 Danke für Dein Interesse an meinem Problem. Da TCCR3A beim ATmega128 im extented IO-Bereich liegt (>60H), geht das nicht über die sonst üblichen in/out-Befehle, sondern nur mit indirekter Adressierung - nahm ich bisher an. Allerdings habe ich nun festgestellt, dass auch mit den sts/lds-Befehlen solches möglich ist. AS6.1 ist nun downgeloadet - ohne das Anmeldeprozedere - direkt von der Direktdownload-Adresse und installiert. Obwohl ich hier schon das MS-Studio drauf habe und dementspreched die Variante "ohne" genommen hatte, wollte das Installations-Programm aber dennoch zusätzlich die "MS-Studio-Shell 10" und ATMEL-USB-Treiber nachladen. So sind aus den urspünglichen ca. 800MB insgesamt weit über 2GB (!) geworden. Das sollte man bei der Installation von AS6.1 beachten. Nun heisst es sich wieder in eine neue IDE einzuarbeiten und die bisherigen Projekte des AVR-Studio 4.18 zu transferieren. Da es zurück ja wohl keinen Weg geben soll, werde ich die bisherigen (4.18) nicht überschreiben, sondern die transferierten in separaten Ordnern "AS6.1" verwalten. Grüsse aus Berlin PSblnkd
So, nachdem das AS6.1 nun installiert ist, habe ich auch schon mal ein wenig darin "rumgestochert", ohne jedoch bereits mit einem Projekt zu beginnen. Zunächst dauert der Startvorgang im Vergleich zum AVR-Studio4 wesentlich länger und wenn man nicht die Festplatte rödeln hört, oder den Tastmanager bemüht, könnte die Annahme bestehen, dass sich der PC aufgehängt hat. Ein Fortschrittsbalken im Startbild wäre hier von Vorteil. Bedingt durch den Anspruch alle µC-Produkte von ATMEL zu unterstützen - egal ob ein kleiner ATtiny oder ein hochkarätiger ARM - ist die IDE doch sehr umfangreich und damit unübersichtlich geworden. Von den bekannten und liebgewonnenen Menüs aus dem AVRStudio ist nur wenig übriggeblieben, aber vieles dazugekommen, wobei vielfach wiederum Einiges deaktiviert ist. Warum das so ist, muss man sich dann erst mal wieder mühsam und zeitaufwändig erarbeiten. AVR-Studio4-Projekte lassen sich nicht direkt laden, jedoch offensichtlich importieren. Ein Zurück gibt es dann nicht mehr. Tatsächlich scheint es auch so, dass sich AS6.1 und AVR-Studio4.18 gegenseitig nicht beeinflussen. Aber der Schein trügt! Während sich beide IDEs anstandslos laden lassen, funktionierte jedoch anschließend die Kommunikation des JTAGICEmkII mit dem AVR-Studio4.18 nicht mehr. Offensichtlich wurde der Jungo-Treiber des AVR-Studios4.18 durch den neueren vom AS6.1 ersetzt, welcher aber nicht mit dem alten AVR-Studio4.18 funktioniert. Da ich nicht die Absicht habe den JTAGICEmkII mit den AS6.1 zu betreiben - da wäre auch wieder eine neue Firmware notwendig und wer weiss, ob das rückgängig gemacht werden kann... - habe ich versucht den alten Jungo-Treiber wieder zu aktivieren, d.h. neu zu installieren. Nur zum Betrieb am AS6.1 wollte ich mir dann den einigermaßen preiswerten JTAGICE3 zulegen. Zur Neuinstallation des alten Jungo-Treibers wurde die letzte Version des AVR-Studios4, AVR-Studio4.19 verwendet - auch in der Hoffnung, dass dort alle Bugs beseitigt sind (s.o.). Die Installation funktionierte einwandfrei, bis auf den Teil der USB-Treiber (Jungo). Dieser Teil wurde übersprungen, weil festgestellt wurde, dass bereits eine neuere Version installiert sei und deshalb diese erst zu deinstalliern wäre. Um den JTAGICEmkII am AVR-Studio4.19 wieder nutzen zu können, musste also der neue Jungo-Treiber von AS6.1 wieder deinstalliert werden. Damit ist natürlich ein Parallelbetrieb beider IDEs nur eingeschränkt möglich, d.h. ich sehe bisher noch keinen Weg dies zu ändern. Vielleicht ist es anderen Usern auch schon so ergangen und jemand weiss eine Ausweg... Übrigens besteht das o.g. Problem mit dem Laden von Festwerten in das OCR3A-Register immer noch, d.h. die Darstellung im Simulator oder unter JTAG erfolgt immer noch nicht. Ob das nun weiterhin ein Bug des AVR-Studio4.19 ist, oder ich das Wirkprinzip immer noch nicht verstanden habe, ist weiterhin offen. Den Simulator im AS6.1 muss ich noch erproben... Grüsse aus Berlin PSblnkd
Danke für Deine Ausführungen. Da ich AVR-Studio 4.18 nur gelegentlich brauche, erspare ich mir den weiteren Aufwand. Bislang war ich soweit gekommen, die 6.1 zweimal herunterzuladen, da die erste Datei defekt war. Danach brauchte ich noch irgendein Update von MS, um wieder von vorne zu installieren (.NET oder so). Dann sollte ich zu XP nach das SP3 installieren, und das wurde mir dann alles zu bunt. Grüße nach Berlin :-)
PSblnkd schrieb: > Übrigens besteht das o.g. Problem mit dem Laden von Festwerten in das > OCR3A-Register immer noch, d.h. die Darstellung im Simulator oder unter > JTAG erfolgt immer noch nicht. Und wieder lässt du das wichtigste Detail einfach weg, nämlich das WANN. Wann "erfolgt die Darstellung nicht"? Direkt nach dem Schreiben? Das ist OK (siehe oben). Oder dann, wenn die Werte dort auftauchen sollten, nämlich wenn der Timer TOP erreicht?
PSblnkd schrieb: > Der erste Versuch zur 6er Version AVR-Studio zu kommen ist schon mal > fehlgeschlagen. Obwohl ich die Firmen-eMail-Adresse benutzt habe, konnte Schon mal hier versucht? Da sollte etwas dabei sein ;-) http://www.mikrocontroller.net/articles/Atmel_Studio
@DirkZ Wie ich bereits schrieb, habe ich mir über eine Direkt-Downloadadresse das AS6.1 "besorgt", auch die Installation erfolgte - wenn auch recht zeitaufwändig - dann doch problemlos und relativ unabhängig von meiner bisherigen Version AVR-Studio4.18. Lediglich das aufgeblähte Installationsvolumen von weit über 2GB stimmte mich doch sehr bedenklich. Leider haben die ATMEL-Programmierer vergessen wenigstens einen Hinweis darauf zu geben, dass bei der Installation des neuen Jungo-Treiber für USB dann ältere Jungu-Treiber nicht mehr wirksam sind und somit früheren Versionen des ATMEL-Studios keine Kommunikation mehr mit peripheren Geräte via USB möglich ist. @Stefan Ernst Das Laden des OCR3A-Register bzw. die diesbezügliche Anzeige im Simulator2 und im JTAGICEmkII-Debugger erfolgt bei meiner Betriebsart leider gar nicht. Das hängt womöglich mit der externen Taktung zusammen. Wenn eine interne Taktung gewählt wird, scheint es zu funktionieren. Ärgerlich ist auch, dass deshalb ein Zählen in der Betriebsart 11 von "0" an nicht möglich ist, weil TCN3 stets im Vergleich mit dem OCR3A - Inhalt ebenfalls "0" - verharrt. Leider habe ich im Moment wenig Zeit, mich weiterhin eingehender mit diesen undokumentierten Eigenheiten des ATMega128 zu beschäftigen. Die Untersuchung mit dem AS6.1-Simulator brachte übrigens die gleichen Ergebnisse, so dass von eine Simulator-Bug nun nicht mehr auszugehen ist. Weniger erfreulich ist auch die Tatsache, dass im AS6.1 Assembler-Entwicklungen auf die 8Bit-AVRs beschränkt sind. Für die hochkarätigeren µC gibt es keine Assembler-Unterstützung, sondern nur noch "C", bzw. "C++" - aber wer will schon einen 32Bit-µC in Assembler programmieren - oder? Rein zur Verständnis-Findung wäre es m.E. doch angenehm - noch dazu, weil es das doch schon gegeben hatte. Grüse aus Berlin PSblnkd
PSblnkd schrieb: > wesentlich länger und wenn man nicht die Festplatte rödeln hört, oder > den Tastmanager bemüht, könnte die Annahme bestehen, dass sich der PC > aufgehängt hat. Ein Fortschrittsbalken im Startbild wäre hier von > Vorteil. Auf einem modernen PC mit SSD startet AS6.1 in wenigen Sekunden...
gustl schrieb: > Auf einem modernen PC mit SSD startet AS6.1 in wenigen Sekunden... Gääähn ... AVR Studio 4.19 braucht dann nur ein paarhundert Millisekunden.
@gustl & Wolfgang ...ja, ja ich weiss - und der Arduino ist tausendmal besser als jeder blöde AVR. Alles das hilft mir allerdings nicht weiter bei meinem Problem mit den OCR3A-Registern im TimerCounter3 vom ATMega128, wenn dieser extern getakte wird (s.o.). In der Hoffnung, dass sich andere User ebenfalls schon damit rumgeplagt haben... Grüsse aus Berlin PSblnkd
PSblnkd schrieb: > Alles das hilft mir allerdings nicht weiter bei meinem Problem mit den > OCR3A-Registern im TimerCounter3 vom ATMega128, wenn dieser extern > getakte wird (s.o.). Nur mal so als Frage meinerseits, kenne mich mit dem AVR Studio überhaupt nicht aus. Ich habe die Posts auch nur kurz überflogen, aber Du willst den Code doch im Simulator testen. Woher soll er (der Simulator) wissen welcher externe Takt anliegt? Kann man das irgendwie in der Konfiguration angeben? Gruß, Steffen
Hi >Alles das hilft mir allerdings nicht weiter bei meinem Problem mit den >OCR3A-Registern im TimerCounter3 vom ATMega128, Welches Problem? Wenn du willst, das sich die OC-Register 'normal' verhalten, dann musst du sie vor den TCC-Registern konfigurieren. Wenn du sie danach konfigurierst verhalten sie sich dem Timer/PWM-Mode entsprechend. Ist das so schwer zu vestehen? >wenn dieser extern getakte wird (s.o.). Was hat das mit einem externem Takt zu tun? MfG Spess
@ spess53 Danke! - Das war der entscheidende Tipp! Hab`s gleich ausprobiert... Es ist offensichtlich so, dass - solange sich der TC_3 im Modus 11 befindet (wie das in den anderen Modi ist, wäre noch zu untersuchen) und - nach entsprechender Konfiguration im TCCR3B-Register - extern getaktet wird, kein neuer Wert in OCR3A geschrieben werden kann. Möglicherweise wird das auch bei OCR3B und OCR3C so sein - wäre ebenfalls noch zu untersuchen. Das braucht man dann nur in der Reihenfolge bei der Initialisierung zu berücksichten. Aber leider verkompliziert sich somit auch eine ISR, wenn dort aus Event-relevanten Gründen ein anderer OCR3-Wert eingetragen werden soll. Dazu muss dann jedes Mal in den "Normal"-Mode 0 umgeschaltet werden, dann der neue Eintrag in`s OCR3x-Register geladen und dann wieder zurück in den Spezial-Modus 11 (z.B.) - hoffe ich jedenfalls, dass es so funktioniert. Meine Erfahrungen bei der AVR-Programmierung sind alle dokumentiert und die werde ich zu gegebener Zeit auch als eBook veröffentlichen. Grüsse aus Berlin PSblnkd
Hi >Aber leider verkompliziert sich somit auch eine ISR, wenn >dort aus Event-relevanten Gründen ein anderer OCR3-Wert eingetragen >werden soll. Dazu muss dann jedes Mal in den "Normal"-Mode 0 >umgeschaltet werden, dann der neue Eintrag in`s OCR3x-Register geladen >und dann wieder zurück in den Spezial-Modus 11 (z.B.) - hoffe ich >jedenfalls, dass es so funktioniert. Hast du einen konkreten Fall oder ist das fiktiv? Weil praktisch interessiert das in 99,999...% aller Fälle den Gasmann. Und für Phase/Phase and Frequency Correct PWM habe ich in 15 Jahren AVR noch keine sinvolle Anwendung gehabt. >Meine Erfahrungen bei der AVR-Programmierung sind alle dokumentiert und >die werde ich zu gegebener Zeit auch als eBook veröffentlichen. Atmel hat recht gute Datenblätter und viele Appnotes das reicht mir. Und für Assembler kommst du mindestens 10 Jahre zu spät. Also wundere dich nicht, wenn das Interesse, gelinde gasagt, verhalten ausfällt. MfG Spess
@ spess53 Natürlich gibt's da eine konkrete Anwendung: Ein Up/Down-Zähler, der automatisch bei einem variabel programmmierbaren Zählerstand ein Signal generiert, was weiter verarbeitet werden kann. Dazu sollte sich der 16Bit-Up/Down TimerCounter_3 des ATmega(128) eigentlich eignen - jedenfalls kam ich zu dieser Erkenntnis nach ausführlichem Studium des betreffendenden Datenblattes. Wenn im Datenblatt wirklich a l l e s beschrieben wäre, müßte ich nicht Rätselraten, bzw. langwierige Eigenversuche veranstalten. Sicherlich gibt es auch eine Menge AppNotes, aber immer nur zu den Hauptanwendungsgebieten - ist ja auch verständlich. Ob ich nun in Assembler oder in C programmiere, ist eigentlich völlig egal. Allerdings liegt mir bei Assembler das Hardware-Verständnis doch viel näher, als bei C und dann kommt dann immer noch die Ungewissheit hinzu, ob und wie C das letztendlich in die "richtige" Maschinensprache übersetzt. Wenn ich neue Erkenntnisse habe, dann hier ... Grüsse aus Berlin PSblnkd
PSblnkd schrieb: > und dann kommt dann immer noch die Ungewissheit > hinzu, ob und wie C das letztendlich in die "richtige" Maschinensprache > übersetzt. Die Listing-Datei (.lss) hilft hier weiter.
Moin moin, so habs jetzt mal getestet mit dem AVR Studio4.19build 716 in SIMULATOR1 das wenn CS20-CS22 die bits auf externe Quelle gestellt sind und man an PinD7 das bit händisch setzt/löscht zählt der Timer2 hoch. Selbiges mit timer3 CS30-CS31 auf externe Quelle und an PinE6 bit händisch setzt/löscht (immernoch im SIMULATOR1) und es geht nicht ABER wenn man unter DEBUG/Select Platform and Device/ SIMULATOR2 einstellt geht es auch mit den TIMER3. als kleinen anhang mal ne include als bessere übersicht Idee kamm mir auch erst dieses Jahr.... aber auf entsprechenden TimerX erweitern.... hoffe das man dir helfen konnte
@ Little Helper Listing-Datei (.lss) - ??? - Kannst Du das bitte mal etwas detaillierter erläutern... @ chris Danke für Deine Code-Bibliothek. Ist aber so umfangreich, dass ich das momentan nicht verifizieren kann. Dass die Darstellung der TimerCounter_3-Funktion im Simulator1 scheinbar so erfolgt, wie man es eigentlich erwartet, hatte ich schon weiter oben beschrieben und auch das ATMEL den Simulator1 nicht mehr empfiehlt (Bugs ?). Das mit dem händischen Setzen/Löschen des PINE am PortE6 habe ich auch so gemacht, aber ein Hochzählen von "0" an konnte ich damit nicht erreichen. Das funktioniert erst, wenn TCN3 mit wenigstens "1" vorgeladen wird, was wiederum verständlich ist, weil sich TCN3 ständig mit OCRA3 im Vergleich befindet. Wenn nun OCRA3 auf "0" steht (Initialisierung), ist TCN3 im Modus 11 stets beim Wechseln der Zählrichtung und kommt da nicht mehr raus. Im Datenblatt steht deshalb auch was von "OCRA3 mindestens mit "3" vorladen". Wenn ich neue Erkenntnisse habe, dann hier ... Grüsse aus Berlin PSblnkd
moin moin,
so i habe mi nochmals hingesetzt um dein problem zu verstehen aber ich
glaube das problem liegt bei dir denn i habe den TIMER3 im MODe11 mit
externen TAKT im Simulator2 getestet und er macht es so wie du es
eigentlich ahben willst.
mal ne frage auf welchen wert setzt du dein OCR3A-register auf !=0??
dann ist mein folgender text einfach fürn arsch oder aber
dein OCR3A-register ist auf 0:
dann ist auch klar warum du am PinE6 extern takten kannst was willst
weil wenn er nur von 0 bis 0 zählt wird er nie mehr als 0 zählen weil
sein BEGRENZUNGSWERT, der durch OCR3A festgelegt wird, immer sofort
erreicht ist.
DB S.133 Spalte TOP das ist entspr. Register welches vorgibt wie weit
gezählt werden soll.
.cseg ;
.org $0000 ;
rjmp stack
stack:
ldi r16,high(ramend) ;Stackpointer festlegen
out sph,r16
ldi temp1,low(ramend) ;Stackpointer festlegen
out spl, temp1
clr r16
sts OCR3AH,r16
ldi r16,$0a ;zählt bis 10 und dann wieder runter
sts OCR3AL,r16 ;<<<<<<<<<<<<< Das ist die ZÄHLERBEGRENZUNG ;-)
ldi r16,(1<<WGM31|1<<WGM30)
sts TCCR3A,r16
ldi r16,(1<<WGM33|0<<WGM32|1<<CS32|1<<CS31|0<<CS30) ;falling edge
sts TCCR3B,r16
start:
rjmp start
PSblnkd schrieb:
>> (wie das in den anderen Modi ist, wäre noch zu untersuchen) und
>> - nach entsprechender Konfiguration im TCCR3B-Register - extern
>> getaktet
>> wird, kein neuer Wert in OCR3A geschrieben werden kann
doch wird er schon nur muss man das doppelte an Zeit abwarten im
Simulator sprich man muss in diesen Bsp 2x mal bis 10 hochzählen lassen
dann steht im OCR3H:L $0080 drin...
PinE6 externer TAKT
.cseg ;<<
.org $0000 ;<<<<QUICK&DIRTY
rjmp stack ;<<< die anderen Vectoren wegzulassen
.org $0038 ;<<<<
rjmp ISR_OCR3A ;<<
stack:
ldi r16,high(ramend) ;Stackpointer festlegen
out sph,r16
ldi temp1,low(ramend) ;Stackpointer festlegen
out spl, temp1
;***NEU ANFANG
sei ;GloabalIntfreigabe
ldi r16,(1<<OCIE3A)
sts ETIMSK,r16 ;INT OCR3A
;***NEU ENDE
clr r16
sts OCR3AH,r16
ldi r16,$0a ;zählt bis 10 und dann wieder runter
sts OCR3AL,r16 ;<<<<<<<<<<<<< Das ist die ZÄHLERBEGRENZUNG ;-)
ldi r16,(1<<WGM31|1<<WGM30)
sts TCCR3A,r16
ldi r16,(1<<WGM33|0<<WGM32|1<<CS32|1<<CS31|0<<CS30) ;falling edge
sts TCCR3B,r16
start:
rjmp start
ISR_OCR3A:
ldi r16,$80 ;zählt bis 128 und dann wieder runter
sts OCR3AL,r16 ;<<<<<<<<<<<<< Das ist die ZÄHLERBEGRENZUNG ;-)
clr r16
sts OCR3AH,r16
reti
Warum die aktualisierung erst beim 2ten mal passiert weiß i selbst uch
net bin aber der meinung i das schn mal irgendwo gelesen habe aber bevor
ich müll erzähle vielleicht weiß das der ein oder andere ja....
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.