http://de.wikipedia.org/wiki/Puls-Pausen-Modulation Ich versuche gerade einen Mixer zu bauen, der am RC-Empfänger zwischen Empfängerteil und Demultiplexer sitzt. Es ist also ein PPM Signal zu dekodieren, zu verarbeiten und ein neues PPM Signal auszugeben. Bei mir werkelt ein MSP430, dessen Pin-Change Interrupt die Signalflanken erfasst, und ein Timer-Interrupt, der das neue Signal ausgibt. Die Berechnung erfolgt in der main-loop. Da das neue Signal natürlich erst berechnet werden kann, wenn eines erfasst wurde, wird es verzögert ausgegeben. Da der Demultiplexer alle 20 ms einen Reset erhält, gebe ich das neue Signal derzeit um ein Paket versetzt aus, parallel kommt also schon ein neues an. Das führt leider dazu, dass sich einzulesende und auszugebende Flanken und die dazugehörigen Interrupts überschneiden und zu Jitter führen. Gibt es ein Rezept dagegen, ausser Pakete zu ignorieren oder über einen anderen Weg auszugeben?
VHzA schrieb: > Das führt leider dazu, dass sich einzulesende und auszugebende Flanken > und die dazugehörigen Interrupts überschneiden und zu Jitter führen. Ich kenne den MSP nicht. Aber beim AVR kann man einen Puls mit Input-Capture einlesen. D.h. der Interrupt muß nur spätestens bis zur nächsten Flanke erfolgen. Dann stimmt der Timestamp auf einen CPU-Zyklus. Und für das Senden gibt es Compare-Outputs, d.h. der Pin wird zum Comparezeitpunkt gesetzt oder gelöscht. Der Compareinterrupt muß dann nur bis zum nächsten Comparezeitpunkt beendet sein. D.h. Empfang und Senden erfolgt jitterfrei auf 50ns [20MHz] genau. Peter
Guten Morgen Peter, Timer funktionieren ja überall sehr ähnlich und ich mache es fast, wie du vorgeschlagen hast: > Puls mit Input-Capture einlesen > Compare-Outputs >>MSP430, dessen Pin-Change Interrupt die >>Signalflanken erfasst, und ein Timer-Interrupt, der das neue Signal >>ausgibt. Leider habe ich aber nur einen 16-bit Timer auf dem µC und kann m.W. entweder Capture oder Compare verwenden, daher habe ich mich für einen Flankeninterrupt zum Messen (d.h. Timerwert auslesen) und die Compare-Unit (Pin Toggle) und ihren Interrupt (nächsten Timerwert berechnen) zum Erzeugen entschieden. Vielleicht kann ich aber den Compare-Interrupt weglassen und das Berechnen des neuen Timerwertes in der Main-Schleife machen, dann gibt es nur noch einen Interrupt, dem nichts in die Quere kommen kann. Andernfalls muss ich doch eine andere Ausgabemethode nutzen. Danke für dein Interesse.
VHzA schrieb: > Leider habe ich aber nur einen 16-bit Timer auf dem µC und kann m.W. > entweder Capture oder Compare verwenden Sicher? Sind das nicht verschiedene Pins und Register? Beim AVR (z.B. ATtiny24) geht jedenfalls beides gleichzeitig. Peter
Anderer Ansatz
> Da der Demultiplexer alle 20 ms einen Reset erhält
Warum muss das so sein?
Was ich damit meine: Klar muss der Demultiplexer einen Reset erhalten.
Aber der Reset muss ja nicht am µC vorbei auf den Demultiplexer gehen.
Resette den Demux vom µC aus und du befreist dich damit aus deinem
Timing-Problem.
Aua - du hast Recht! http://www.ti.com/lit/ug/slau144i/slau144i.pdf 12.2.4 Capture/Compare Blocks
1 | Two or three identical capture/compare blocks, TACCRx, are present in Timer_A. Any of the blocks may be used to capture the timer data, or to generate time intervals. |
Der Pin-change Interrupt zum Messen könnte also entfallen. Super Tipp, Danke!
Karl Heinz Buchegger schrieb: > Resette den Demux vom µC aus und du befreist dich damit aus deinem > Timing-Problem. Ich glaube nicht wirklich, da keine zwei "Signalketten" in die Periode passen. Damit kommt es eigentlich immer zur Überlappung. Anders sieht es aus, wenn man die Kanäle dekodiert und parallel ausgibt, dann reicht die Zeit in der Synchronisationslücke aus.
Es funktioniert nun ohne merkliches Zittern, manchmal tickt zwar ein
Servo, aber ich bin vorerst zufrieden. Danke nochmal für den Hinweis!
Auch wenn es m.E. dem Timing nicht zugute kommt - den Demux-Reset muss
ich dennoch selbst erzeugen, denn sonst lassen sich nur in Abhängigkeit
vom Empfänger eigene Kanalimpulse erzeugen - wenn dieser kein
brauchbares Signal bekommt (Reichweite, Störung, Sender aus) kommt
ausser Rauschen bei meinem Empfänger nämlich auch kein Reset-Impuls.
Eine Fail-Safe Funktion ('sichere' Kanalstellungen) liesse sich also
nicht realisieren.
Bitte 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.