Statt dessen bleibt der Pin PD5 hartnäckig auf 0 und rührt sich nicht. Die Initialisierung: ■ TCA0 WO1-5 Pins alternativ auf PD1-PD5 gelegt via PORTMUX=3 ■ Pin PD5 auf Ausgang gesetzt (=WO5) ■ IN TCA0_SINGLE_CTRLB das Bit CMP0EN=1 und WGMODE=1 gesetzt ■ TCA0_SINGLE_CMP0 mit 20 geladen ■ TCA0_SINGLE_CTRLA mit Vorteiler 64 und ENABLE=1 geladen Mit dem Debugger alles auf Richtigkeit kontrolliert. Nun sollten doch bei 4MHz Takt f= 4000000/(2*64*(20+1)) ca. 1488 Hz am Ausgang erscheinen. Tun sie aber nicht! Sonst läuft bislang auf dem Controller nur eine UART Ausgabe, weshalb ich sicher bin daß mit den ca. 4 MHz Takt alles stimmt.
WO5? Ich hätte WO0 erwartet, auf D0.
Pardon, ich war beim AVR128DA28 - beim ..DB.. geht alternativ-WO0 nicht, bleibt nur A0.
S. Landolt schrieb: > WO5? > Ich hätte WO0 erwartet, auf D0. Es existieren in TCA0_SINGLE_CTRLB ja nur CMP0EN bis CMP2EN... Wo wäre dann die "Freischaltung" für WO5 = PD5, den ich unbedingt nutzen möchte?
Vermutlich 'split-mode' ("corresponding WO[n+3] pin") müsste ich aber
erst ausprobieren.
S. Landolt schrieb: > Vermutlich 'split-mode' ("corresponding WO[n+3] pin") müsste ich > aber erst ausprobieren. Das könnte sein... Muss mir den Mode erst mal zu Gemüte führen. Danke soweit.
Herbert schrieb: > ■ TCA0 WO1-5 Pins alternativ auf PD1-PD5 gelegt via PORTMUX=3 PORTMUX, was soll denn das sein? Es ist kein Register, jedenfalls nicht das Richtige. Richtig ist: PORTMUX.TCAROUTEA = 3; PORTMUX alleine ist effektiv dasselbe wie: PORTMUX.EVSYSROUTEA Dass Einstellungen in diesem Register keine Auswirkung auf das Routing der Signale von TCA0 haben, liegt in der Natur der Sache... Lustig ist übrigens: Dieser Fehler kann in Assembler garnicht erst passieren, da ist nämlich PORTMUX nicht definiert. Da müßte man schon PORTMUX_base hinschreiben, um effektiv denselben Unsinn zu verzapfen.
Dies brint auf PD5 ca. 244 Hz (bei 4 MHz):
1 | puti PORTMUX_TCAROUTEA,0b00_000_011 ; -> PD0..5 |
2 | sbi VPORTD_DIR,5 |
3 | puti TCA0_SPLIT_CTRLB,0b0_1_0_0_0_0_0_0 ; HCMP2EN |
4 | puti TCA0_SPLIT_CTRLD,1 ; SPLITM |
5 | putiw TCA0_SPLIT_HCMP2,20 |
6 | puti TCA0_SPLIT_CTRLA,0b1_000_101_1 ; RUNSTDBY, DIV64, ENABLE |
c-hater schrieb: > PORTMUX, was soll denn das sein? Es ist kein Register, jedenfalls nicht > das Richtige. > Richtig ist: > PORTMUX.TCAROUTEA = 3; Ja war etwas unpräzise ausgedrückt, habs natürlich so im Quelltext. S. Landolt schrieb: > Dies brint auf PD5 ca. 244 Hz (bei 4 MHz): > puti PORTMUX_TCAROUTEA,0b00_000_011 ; -> PD0..5 > sbi VPORTD_DIR,5 > puti TCA0_SPLIT_CTRLB,0b0_1_0_0_0_0_0_0 ; HCMP2EN > puti TCA0_SPLIT_CTRLD,1 ; SPLITM > putiw TCA0_SPLIT_HCMP2,20 > puti TCA0_SPLIT_CTRLA,0b1_000_101_1 ; RUNSTDBY, DIV64, ENABLE Klasse. Problem gelöst. WO3-5 finden also nur für ein 8er Splitregister von TCA0 Verwendung. Stundenlange Fehlersuche beendet ;-)
> Problem gelöst
Ich weiß nicht - der läuft jetzt ja die vollen 2^8=256 durch (deshalb
die 244 Hz), und ich finde erstmal keine Möglichkeit, da was
einzustellen, und den Satz "Waveform Generation: – Single-slope PWM only
(WGMODE = SINGLESLOPE in TCAn.CTRLB)" verstehe ich nicht ganz.
S. Landolt schrieb: > und ich finde erstmal keine Möglichkeit, da was einzustellen Vom Vorteiler abgesehen. Sonst nicht sehr variabel das Ganze. Ich brauche jedoch nur einen Signalton, der mit 16er Vorteiler ist optimal.
S. Landolt schrieb: > puti TCA0_SPLIT_CTRLB,0b0_1_0_0_0_0_0_0 ; HCMP2EN > [...] > puti TCA0_SPLIT_CTRLA,0b1_000_101_1 ; RUNSTDBY, DIV64, ENABLE Das ist ja interessant (die Schreibweise der Binär-Literale). Ist das eine eigene Makro-Magie in puti, die das erlaubt oder kann der Atmel Assembler das von Hause aus?
S. Landolt schrieb: > avrasm2 Danke. Das Feature kannte ich noch gar nicht. Könnte u.U. durchaus mal nützlich sein. Bei solchen Sachen wie im konkreten Fall bevorzuge ich allerdings grundsätzlich die "Langschreibweise" mit den Konstanten aus den den Atmel-Includes. Bei den Includes im XMega-Style ist das ja auch noch deutlich einfacher (und kürzer) geworden, weil es da die *bm- und *gc-Dinger gibt.
> "Langschreibweise"
Hatte ich eine Weile versucht, konnte mich aber nicht daran gewöhnen.
PS: Trotz Zehnfingersystem - für meinen Geschmack hat Atmel/Microchip da in den letzten Jahren etwas übers Ziel hinausgeschossen:
1 | puti EVSYS_USEREVSYSEVOUTD,EVSYS_CHANNEL00_bm |
S. Landolt schrieb: > PS: > > Trotz Zehnfingersystem - für meinen Geschmack hat Atmel/Microchip da in > den letzten Jahren etwas übers Ziel hinausgeschossen: >
1 | > puti EVSYS_USEREVSYSEVOUTD,EVSYS_CHANNEL00_bm |
2 | > |
Nunja. Leider wird der Assembler sehr stiefmütterlich behandelt, weil all diese Leute (Kraftausdruck selbst zensiert und durch was Unverfängliches ersetzt) ja nur in C schreiben. Deswegen gibt's hier von Atmel/MC keine brauchbare Code-Completion für den VS-Editor in Asm und deswegen artet es in Arbeit aus, dort symbolische Konstanten zu benutzen. Da ich aber erstens AVR8-Asm kann und zweitens auch C# und mich obendrein mit dem VS sehr gut auskenne, habe ich mir selber eine sehr gut brauchbare Code-Completion für Asm im Atmel-Studio programmiert. Leider darf ich das aber nicht veröffentlichen. Ist in der von meinem Brötchengeber bezahlten Zeit entstanden, ich bin also zwar der Urheber des Codes, habe aber kein Recht, ihn zu veröffentlichen, so gern ich das auch tun würde.
Hallo, wenn ich helfen darf. Über den komischen Satz bin ich auch gestolpert. Der soll jedoch nichts weiter sagen als das sich die PWM Erzeugung im Spit-Mode so verhält wie im Single Slope Mode. Zumindestens nahezu so ähnlich. Es gibt ein TOP Wert und einen Compare Wert. Das Counter im Splitmode nur "down" zählt spielt erstmal keine Rolle. Ich erkläre das einmal mit meinen Worten. Der Timer teilt sich auf in einen HIGH Byte und einen LOW Byte Strang. LOW Byte Strang. Dazu gehören die normalen WOn 0...2. Das Frequenz bestimmende TOP Register für diese 3 Kanäle ist LPER.
1 | TCA0.SPLIT.LPER = |
Die Pulsweiten bestimmenden Register je Kanal sind LCMP0, LCMP1 und LCMP2.
1 | TCA0.SPLIT.LCMP0 = |
2 | TCA0.SPLIT.LCMP1 = |
3 | TCA0.SPLIT.LCMP2 = |
HIGH Byte Strang. Dazu gehören die normalen WOn 3...5. Das Frequenz bestimmende TOP Register für diese 3 Kanäle ist HPER.
1 | TCA0.SPLIT.HPER = |
Die Pulsweiten bestimmenden Register je Kanal sind HCMP0, HCMP1 und HCMP2.
1 | TCA0.SPLIT.HCMP0 = |
2 | TCA0.SPLIT.HCMP1 = |
3 | TCA0.SPLIT.HCMP2 = |
Das heißt man kann 2 verschiedene Frequenzen erzeugen. Je Strang unterschiedlich. Duty Cycle ist bei allen frei einstellbar. Der Reset ist meiner Meinung nach auch noch wichtig
1 | TCA0.SPLIT.CTRLESET = TCA_SINGLE_CMD_RESET_gc; |
Veit D. schrieb: > Hallo, > wenn ich helfen darf... Manch ein Beitrag hier erklärt das Wesentliche besser als es jedes MicrochipAtmel- Datenblatt könnte 👍 Der Konfigurations- Aufwand der inzwischen betrieben werden muß um einem Pin einen Ton zu entlocken ist jedoch bedenklich. Auch eine vollwertigere Portmux-Einheit, die jedem IO-Pin jede Funktion zuzuweisen vermag könnte wesentlich zur Vereinfachung beitragen. c-hater schrieb: > Bei solchen Sachen wie im konkreten Fall bevorzuge ich allerdings > grundsätzlich die "Langschreibweise" mit den Konstanten aus den den > Atmel-Includes. Bei den Includes im XMega-Style ist das ja auch noch > deutlich einfacher (und kürzer) geworden, weil es da die *bm- und > *gc-Dinger gibt. Vorteil bei Assembler ist doch gerade, es kurz und knackig halten zu können. Ausufernde Register- und Konstantenbezeichnungen tragen gerade nicht dazu bei. Was es zwingend zu erläutern gilt macht man in Kommentaren kenntlich. c-hater schrieb: > Nunja. Leider wird der Assembler sehr stiefmütterlich behandelt, weil > all diese Leute ja nur in C schreiben. Deswegen gibt's hier von > Atmel/MC keine brauchbare Code-Completion für den VS-Editor in Asm und > deswegen artet es in Arbeit aus, dort symbolische Konstanten zu > benutzen. Dem ist wohl so, wobei lange symbolische Konstanten natürlich auch in diesem Falle Code beim Lesen nur unnötig aufblähen. Code-Completion bleibt trotzdem eine gute Idee, wenn sie vor allem auch in der Lage ist, im aktuellen Kontext verwendete, in Equates definierte, im Speicher definierte Variablen, Ausdrücke, Sprungmarken intelligent vorzuschlagen; samt Prüfung der ganzen Codezeile auf syntaktische Richtigkeit, ohne das erst mit einem Build-Durchlauf testen zu müssen.
Veit Devil schrieb:
> Über den komischen Satz bin ich auch gestolpert ...
"• Waveform Generation:
– Single-slope PWM only (WGMODE = SINGLESLOPE in TCAn.CTRLB)"
Soweit schon klar, ich stieß mich nur an zwei Punkten: implizit nahm ich
an, auch die Frequenz einstellen zu können, soll heißen, feiner als es
mit dem Vorteiler möglich ist; und die Klammer ist leicht irreführend,
da gehört ein "corresponds" o.ä. mit hinein.
Veit D. schrieb: > Das Frequenz bestimmende TOP Register für diese 3 Kanäle ist HPER. > TCA0.SPLIT.HPER = Begrenzt, sehr begrenzt. Erst oberhalb von ca. 230 hört man plötzlich etwas und bis 255 ändert sich die Frequenz nur minimal. "Richtig" was bringen tut da nur der Vorteiler- freilich in arg begrenzter Auswahl.
" ... and all it's mystery, he said, is clear as day to me." Danke, Veit Devil! an Herbert: hier Ihre 1488 Hz mit Tastgrad ~0.5:
1 | puti PORTMUX_TCAROUTEA,0b00_000_011 ; -> PD1..5 |
2 | sbi VPORTD_DIR,5 |
3 | puti TCA0_SPLIT_CTRLB,0b0_1_0_0_0_0_0_0 ; HCMP2EN fuer WO5 (=WO2+3) |
4 | puti TCA0_SPLIT_HPER,41 |
5 | puti TCA0_SPLIT_HCMP2,21 |
6 | puti TCA0_SPLIT_CTRLD,1 ; SPLITM |
7 | puti TCA0_SPLIT_CTRLA,0b1_000_101_1 ; RUNSTDBY, DIV64, ENABLE |
S. Landolt schrieb: > an Herbert: > hier Ihre 1488 Hz mit Tastgrad ~0.5: Danke. Ein bischen mehr Frequenz-Variabilität scheint dann doch noch möglich. Die zwei Codes zum Laden von HPER spare ich mir jetzt aber da der gewünschte Signal-Ton auch so recht markant ist. Beim nächsten Layout werde ich dann aber drauf achten einen geeigneteren Pin auszuwählen!
Den einzigen TCA für einen Signalton dranzugeben, das ist eigentlich schade. Bei den drei TCB allerdings ist der Vorteiler arg beschränkt. Nun denn. Ein schönes Wochenende wünsche ich. "Was jüngst mir rätselhaft", sprach er, "Itzt faß' ich's mit Gewinn!"
Hallo, kleine Korrektur meiner Ausdrucksweise. Aber ihr habt mich auch so verstanden. :-) LOW Byte Strang: Dazu gehören die standardmäßigen WOn 0...2. HIGH Byte Strang: Dazu gehören die zusätzlichen WOn 3...5. Allerdings verstehe ich Herberts Antwort nicht. "Die zwei Codes zum Laden von HPER spare ich mir jetzt aber da der gewünschte Signal-Ton auch so recht markant ist." Wenn TOP gleich 0 ist passiert am Ausgang nichts. Kein Takt. Mich würde jetzt wirklich interessieren welchen Takt du an PD5 misst. Und natürlich welche vollständigen Registereinstellungen du verwendest. Grundlegend ist im Split-Mode folgendes. Irgendeinen Takt mit irgendeinem Tastverhältnis größer 0 gibt es erst wenn TOP und Compare größer gleich 1 sind. Wobei Compare maximal gleich TOP sein darf. Je größer TOP ist desto mehr Auflösung hat man und desto näher kommt man mit Compare = TOP an 100% Duty Cycle heran. Das sind die Rahmenbedingungen.
:
Bearbeitet durch User
Hallo Veit Devil, nochmals danke für Ihre umfangreiche Erklärung, ich hatte sie leider beim ersten Mal nicht zuende gelesen. Zu Ihrer Frage an Herbert (und indirekt ja auch an mich, s. ersten Programmvorschlag): haben Sie bedacht, dass der Reset-Wert von HPER 255 ist?
S. Landolt schrieb: > Zu Ihrer Frage an Herbert (und indirekt ja auch an mich, s. ersten > Programmvorschlag): haben Sie bedacht, dass der Reset-Wert von HPER 255 > ist? Das wird es wohl sein, denn wenn man explizit 0 vorgibt tut sich in der Tat nichts. Zur Not könnte ich die Frequenz auch messen...
Angehängte Dateien:
-
frequenz.jpg
160 KB
Hallo Veit, also mit Takt 4MHz TCA0_SPLIT_CTRLA = 9 TCA0_SPLIT_CTRLB = 64 TCA0_SPLIT_CTRLD = 1 TCA0_SPLIT_HCMP2 = 48 TCA0_SPLIT_HPER uninitialisiert kommen ca. 974 Hz raus.
Wie zu erwarten: 4 MHz /16 /256 = 976.56 Hz, da TCA0_SPLIT_HPER=255.
Hallo, ich würde kein Register uninitialisiert lassen. Hier wird bewusst oder eher unbewusst der Effekt genutzt das LPER/HPER nach Reset den Wert 0xFF annimmt. Um zu verstehen was da passiert und warum überhaupt was passiert muss man erst wieder im Manual nachlesen. Nach paar Wochen hat den Effekt bestimmt vergessen. Ist zumindestens unschön. Ist nur meine Meinung.
Es sollte ja nur erklären, dass Herbert & ich uns die Frequenz an PD5 nicht einbildeten.
Beitrag #6708039 wurde von einem Moderator gelöscht.
Beitrag #6708066 wurde von einem Moderator gelöscht.
Jetzt mit unnötigen Kommentaren nerven, bis auch der erste Beitrag gelöscht wird, und anschließend den armen Gemobten geben - prima!
S. Landolt schrieb: > Jetzt mit unnötigen Kommentaren nerven, bis auch der erste Beitrag > gelöscht wird, und anschließend den armen Gemobten geben - prima! Unnötig! Und noch dazu kein Bezug zum Thema!
Der sportliche Asm-Programmierer spart wo er kann und nutzt die Umstände optimal 😉
S. Landolt schrieb: > Es sollte ja nur erklären, dass Herbert & ich uns die Frequenz an PD5 > nicht einbildeten. Ist ja alles kein Problem. Hat "nur" für Verwirrung gesorgt. :-) :-) Alles gut.
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.