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