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.
ISRs kann man eh vergessen wegen cli.
Christian schrieb:> 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.
> ISRs kann man eh vergessen wegen cli.
Unsinn! Siehe oben!
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.
Falk B. schrieb:> 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.
Christian schrieb:> 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.
Achim H. schrieb:> Das Event System ist wohl zu langsam?
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.
Achim H. schrieb:> 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.
Christian schrieb:> Ich dachte, es wäre klar genug. Dann halt in Worten. Jede Zeile ist> ein(!) CPU-Takt.
Nö, siehe Netiquette.
"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.
Nö.
Christian schrieb:> 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
Carsten-Peter C. schrieb:> Moin,> mit diesen Befehlen könnte man das machen
Wenn man die CPU zu 100,0% damit beschäftigen will, ja. Das war aber
glaube ich nicht das Ziel.
Christian schrieb:> 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.
Carsten-Peter C. schrieb:> Ein Beispiel mit einem ATmega> Anfang:> cbi PORTC, 6 ;1Takt LOW> sbi PORTC, 6 ;1Takt HIGH
Atmega musst du schon näher spezifizieren. Die Classic-ATmegas brauchen
für cbi und sbi je zwei Takte.
Christian schrieb:> 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.
Mit
CCAEN = 1
WG1A = Fcpu
WG0C = 6Takte High - 10 Low
könnte an OC1A das gewünschte rauskommen?
Ob S. schrieb:> Die Classic-ATmegas brauchen für cbi und sbi je zwei Takte.
Ja - das ist oft lästig, aber die Xmega schaffen das in einem Takt :-)
Christian schrieb:> ich brauche folgende Waveform:_-_-_-_____-_-_-_____-_-_-_____ ....Christian schrieb:> Ich dachte, es wäre klar genug.
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?
So weit zum Thema "ich dachte" ...
Thread beobachten
Seitenaufteilung abschalten