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
@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?
@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....
