Forum: Mikrocontroller und Digitale Elektronik PPM einlesen, mixen und ausgeben


von VHzA (Gast)


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?
von Peter D. (peda)


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
von VHzA (Gast)


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.
von Peter D. (peda)


Lesenswert?

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
von Karl H. (kbuchegg)


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.
von VHzA (Gast)


Lesenswert?

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!
von VHzA (Gast)


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.
von VHzA (Gast)


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.
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
Noch kein Account? Hier anmelden.