PPM einlesen, mixen und ausgeben

VHzA Gast #2519353
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter D. #2519574
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
VHzA Gast #2519600
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #2519693
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
VHzA Gast #2520021
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
VHzA Gast #2520472
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren