Instinktiv würde ich jetzt zwei Timer mit verschiedenen Perioden kombinieren und der Pin soll bitte nur dann HIGH sein, wenn beide Timer einen HIGH ausgeben würden. Extern mit Hardware würde ich das mit einem AND-Bauteil lösen, aber da auf der Platine alles schon vollgebaut ist und auch keine Pins mehr frei sind, wäre es toll, wenn man das irgendwie auch mit onboard-Mitteln hinbekommen könnte. Awex schreit irgendwie danach, aber ich blick da nicht durch und nur die Timer selber scheinen es nicht zu können.
Was ich schon versucht habe:
Mit dem Event-System kann man einen Timer nicht abschalten.
Mit DMA den Timer abschalten geht nicht zeitgenau, da er einen Bus-Arbiter verwendet = Jitter.
ich brauche folgende Waveform:---_____---_____--_-_____ ....
Instinktiv würde ich jetzt zwei Timer mit verschiedenen Perioden
kombinieren und der Pin soll bitte nur dann HIGH sein, wenn beide Timer
einen HIGH ausgeben würden.
Kommt drauf an, wie lang die Zeiten sind und wie genau es sein muss. Siehe Netiquette.
Mit dem Event-System kann man einen Timer nicht abschalten.
Wozu auch? Das macht man problemlos mit einem PWM-Ausgang und dem dazugehörigen Interrupt. Das ist sogar mur mit CPU jitterfrei.
Ich dachte, es wäre klar genug. Dann halt in Worten. Jede Zeile ist ein(!) CPU-Takt.
1
LOW
2
HIGH
3
LOW
4
HIGH
5
LOW
6
HIGH
7
LOW
8
LOW
9
LOW
10
LOW
11
LOW
12
LOW
13
LOW
14
LOW
15
LOW
16
LOW
Insgesamt 16 Takte. Dieses Pattern soll sich andauernd wiederholen.
Der erste Timer müsste also _PER=1 _CCA=1 sein. Der zweite muss den ersten entweder abschalten oder sperren. Es darf nicht passieren, dass dort manchmal 4*HIGH steht. Er muss also taktgenau abschalten.
Wozu auch? Das macht man problemlos mit einem PWM-Ausgang und dem
dazugehörigen Interrupt. Das ist sogar mur mit CPU jitterfrei.
So ein Unsinn! Selbst ohne cli-Blöcke in den Libs hast du je nach Befehl, der gerade ausgeführt wird, einen Jitter von bis zu fünf zusätzlichen Takten. Z.B. wenn er gerade einen call verarbeitet.
Ich dachte, es wäre klar genug. Dann halt in Worten. Jede Zeile ist
ein(!) CPU-Takt.
Das hättest du gleich klarstellen sollen. Das war NICHT klar. NICHTS wies in deinem Posting auf diesen Sachverhalt hin! Wie kommst du auf die schwachsinnige Idee, dass das für die Leser deines Postings klar wäre? Weil es dir klar war, dass du das willst? Wir können deine Gedanken NICHT lesen!
Es gibt übrigens noch was anderes, was du nicht klargestellt hast: um WELCHEN XMega geht es überhaupt? Hinweis für dich: es gibt weitaus mehr als nur einen Typ! Und, für dich vielleicht überraschend: ja die unterscheiden sich durchaus. Wäre es anders, hätte Atmel schließlich nur einen Typ herausbringen müssen, meinst du nicht auch?
Das Event System ist wohl zu langsam? Aber mit der "advanced waveform extension" könnte es gehen. Wenn ich Figure 15-2 (XMEGA-AU_Manual_complet) richtig verstehe kann es OC0A mit OC1A verknüpfen.
Wozu antworten wenn man die Frage nicht versteht. Abb 1 ist doch wirklich deutlich. Allein das "Taktgenau" fehlte. Und natürlich kann man Ints vergessen. Der Xmega wird wohl kaum alleine zum Takt ausgeben da sein. Und jeder weitere Int würde den dann schreddern.
Das Event System nicht, aber damit kann man den Timer anscheinend nicht abschalten. Ich habe bisher nur den Weg über DMA gefunden und DMA ist nicht jitterfrei.
Aber mit der "advanced waveform
extension" könnte es gehen. Wenn ich Figure 15-2
(XMEGA-AU_Manual_complet) richtig verstehe kann es OC0A mit OC1A
verknüpfen.
Leider sehe ich das derzeit so, dass man nur die CCx verknüpfen kann. Ich bräuchte aber wohl eher zwei PER-Register, also Perioden.
Das Event System ist wohl zu langsam? Aber mit der "advanced waveform
extension" könnte es gehen. Wenn ich Figure 15-2
(XMEGA-AU_Manual_complet) richtig verstehe kann es OC0A mit OC1A
verknüpfen.
Wozu antworten wenn man die Frage nicht versteht. Abb 1 ist doch
wirklich deutlich. Allein das "Taktgenau" fehlte. Und natürlich kann man
Ints vergessen. Der Xmega wird wohl kaum alleine zum Takt ausgeben da
sein. Und jeder weitere Int würde den dann schreddern.
Aha, pluto25 ist also Sockenpuppe von dragony.
Zumindest die, die solcherart Information sinnvoll verwerten können, können mit DIESER Information tatsächlich etwas anfangen.
"Daran denken, dass die Leute im Forum nicht neben einem sitzen und alles so vor sich sehen wie der Fragesteller"
Insgesamt 16 Takte. Dieses Pattern soll sich andauernd wiederholen.
Naja, bei der Zahl 16 könnte dem geneigten Programmierer das Vielfache von 8 Auffallen. Und Datenmuster kann man per SPI erzeugen. Also füttert man SPI per DMA und TIMER mit zwei Datenmustern und erhält ein jitterfreies 16 Bit Muster.
Der erste Timer müsste also _PER=1 _CCA=1 sein. Der zweite muss den
ersten entweder abschalten oder sperren. Es darf nicht passieren, dass
dort manchmal 4*HIGH steht. Er muss also taktgenau abschalten.
Doch. Aber egal. Ich nehme die externe Lösung. Vielleicht sinds ja
morgen 23 Takte.
Das Konzept ist generell fragwürdig, denn die allermeisten Mikrocontroller können die IOs nicht mit vollem CPU-Takt umschalten, schon gar nicht mit solchen Mustern. Dafür sind sie schlicht nicht gebaut. Das ist die ein Job für CPLDs/FPGAs oder ähnliche Sachen wie PIO-Einheiten im RP2040, Propeller etc. die können taktgenau solche Spielchen betreiben. Aber auch da können die IOs ggf. zu langsam sein.
Moin,
mit diesen Befehlen könnte man das machen
RJMP k Relative Jump PC ← PC + k + 1 2 Clocks
SBI A, b Set Bit in I/O Register I/O(A, b) ← 1 1 Clocks
CBI A, b Clear Bit in I/O Register I/O(A, b) ← 0 1 Clocks
Ein Beispiel mit einem ATmega
Anfang:
cbi PORTC, 6 ;1Takt LOW
sbi PORTC, 6 ;1Takt HIGH
cbi PORTC, 6 ;1Takt LOW
sbi PORTC, 6 ;1Takt HIGH
cbi PORTC, 6 ;1Takt LOW
sbi PORTC, 6 ;1Takt HIGH
cbi PORTC, 6 ;1Takt LOW
nop ;1Takt
nop ;1Takt
nop ;1Takt
nop ;1Takt
nop ;1Takt
nop ;1Takt
nop ;1Takt
rjmp Anfang ;2Takte
Anstelle der nop’s könnte man eine Unterbrechungsbedingung einfügen, wenn gewünscht. Ist aber schon sehr ungewöhnlich.
Gruß
Carsten
Ich nehme die externe Lösung. Vielleicht sinds ja
morgen 23 Takte.
Ja sowas passiert eben, wenn man nicht die Anwendung beschreibt, sondern nur eine vermeintliche Lösung. Man kriegt dann nur selten dazu passende Antworten. Und die Leute grübeln statt dessen darüber, welche verrückte Aufgabenstellung wohl dahinter stecken könnte.
Ein klare Beschreibung der Aufgabe ermöglicht dagegen, mal einen Blick aus seinem Elfenbeinturm heraus zu werfen.
Nein - was du denkst und was du mit deinem Post rüber bringst, sind bisher noch zwei ziemlich verschiedene Dinge.
Ein Signal ohne Spezifikation der Zeiten ist keine Signalspezifikation.
Je nach Zeichensatz ergibt sich ein unterschiedlicher Duty-Cycle im Burst. Das jedes deiner Zeichen für einen CPU-Clock steht, d.h. DC bei den Pulsen 1:1 gemeint ist und die Abweichung in der Darstellung sich aus den Unzulänglichkeiten der Bildschirmdarstellung mit irgendeinem eingestellten Font ergibt, kann man nur raten. Und wie sieht die Periode des Signals aus?
Soll nach den drei Dreier-Bursts mit Pause von 5 Takten wirklich eine Pause von 6 Takten folgen, so wie es sich ergibt, wenn man das dargestellte Signal danach wiederholt?
Wenn nicht - warum stellst du dann nicht einfach eine Periode dar?
