3-Kanäle PWM messen

Draco schrieb:
> Ich möchte drei PWM Signale / Kanäle von einem RC Empfänger mit einem
> AVR (Atmega32u4). Da es ein Road-Empfänger ist (Spektrum SRS) bekomme
> ich von dem Empfänger kein PPM Summensignal, sondern kann nur die drei
> Kanäle einzeln einlesen.
>
> Wie beim RC üblich folgen die Kanäle jedoch aufeinander, sprich erst
> kommt Signal von Kanal 1 dann 2 dann 3

> Wie kann ich mit nur einem Timer die drei Kanäle separieren?

Mit nur einem Timer, ja. Mit nur einem ICP-Kanal, nein. Allerdings 
reichen zwei ICP-Kanäle für 3 Fernsteuerkanäle. Denn die L->H Flanke von 
Kanal 2 fällt mit der H->L Flanke von Kanal 1 zusammen und die H->L 
Flanke von Kanal 2 mit der L->H Flanke von Kanal 3. Es reicht also, 
steigende und fallende Flanken von Kanal 1 und Kanal 3 auszumessen. 
Kanal 2 ergibt sich durch simple Rechnung.

Mit etwas Aufwand auf der Hardwareseite reicht ein einzelner ICP-Kanal. 
Dazu muß man nur von jedem Fernsteuerkanal ein Monoflop triggern lassen 
(mit der steigenden Flanke) und die Monoflop-Impulse addieren. Schon ist 
es wieder ein PPM-Signal.

Im einfachsten Fall reichen dazu 3 npn-Transistoren als wired-OR und je 
ein CR-Differenzierglied vor jeder Transistorbasis.

Das sollte mit den 3 Interrupts so zu machen sein:
Hauptprogramm: Initialisiere INT0 auf steigende Flanke und Freigeben.

ISR INT0:
* setze Timer 1 auf null und starte ihn. MerkeFlag löschen.
* Sperre mich selber und konfiguriere INT1 auf steigende Flanke

ISR INT1:
* Stopp und lese timer1 und speicher das unter PWM1 Länge
* Reset Timer1 und starten
* Mich selber sperren und INT2 auf steigende Flanke konfigurieren

ISR INT2:
Wenns Flag nicht gesetzt ist
* Stopp und lese timer1 und speicher das unter PWM2 Länge
* Reset Timer und starten
* Mich auf fallende Flanke konfigurieren. Flag setzen.
wenn Flag gesetzt ist
* Stopp und lese timer1 und speicher das unter PWM3 Länge
* Sperre mich und gebe INT0 mit steigender Flanke frei.

Matthias S. schrieb:
> ISR INT0:
> * setze Timer 1 auf null und starte ihn. MerkeFlag löschen.
...
> ISR INT1:
> * Stopp und lese timer1 und speicher das unter PWM1 Länge
> * Reset Timer1 und starten
...

Nein.

Warum sollte man den Timmer immer rücksetzen und neu starten? Einen 
Timer läßt man ganz einfach durchlaufen. Bei einer Frequenz die hoch 
genug für die gewünschte Zeitauflösung ist. Und dann liest man ihn in 
der ISR aus (bzw. läßt die ICP-Unit den Zähler in ein Capture-Register 
sichern). Wenn man dann 2 oder mehr solche Timestamps hat, kann man die 
Zeitspanne zwischen zwei Ereignissen ganz einfach ausrechnen, indem man 
die Zählerstände subtrahiert.

So lange zwischen zwei Ereignissen maximal ein Umlauf des Zählers 
stattfindet, wird auch der Überlauf von der (unsigned) Subtraktion 
korrekt berücksichtigt. Für die Erfassung eines PPM Signals sollte eine 
Auflösung von 1µṣ bei weitem ausreichen und läßt bei Verwendung eines 
16-Bit Timers mehr als genug Luft. Dann hat man 1000 bis 2000 Ticks des 
Timers pro Impuls. Und eine Auflösung von 0.1% respektive 10 Bit.

Axel S. schrieb:
> Warum sollte man den Timmer immer rücksetzen und neu starten?

Du hast dann drei fertige Werte ohne rumrechnen und kannst direkt damit 
weiterarbeiten. Das Stoppen, Lesen und Reset eines Timers ist in 3 
Zeilen erledigt und wenns platzmässig eng wird, auch in einem 
Unterprogramm für alle drei ISR gemeinsam machbar.
Es ist ausserdem eine höhere Auflösung möglich, da man wirklich nur die 
max. 2ms erfassen muss und nicht den gamzen 20ms Frame, wenn man hohe 
Auflösung haben möchte.
Da muss man nicht kunstvoll den Timer mit ICP laufen lassen und externe 
Hardware dazu basteln, denn das ganze läuft so auf der Hardware, die der 
TE schon hat.

m.n. schrieb:
> Oh, hast Du Angst vor simplen Subtraktionen?

Nö, aber warum, wenns gar nicht nötig ist. Ihr tut ja gerade so, als 
darf man um Gottes Willen keinen Timer stoppen und zurücksetzen.

Das ist einfach und geradeaus, jegliche Umverdrahtung entfällt, die drei 
INTs haben sowieso hohe Priorität und kommen sich auch nicht ins Gehege.
Warum also kompliziert, wenns auch einfach geht.

Matthias S. schrieb:
> Axel S. schrieb:
>> Warum sollte man den Timmer immer rücksetzen und neu starten?
>
> Du hast dann drei fertige Werte ohne rumrechnen und kannst direkt damit
> weiterarbeiten.

Wirklich? Dein µC kann nicht subtrahieren?

> Das Stoppen, Lesen und Reset eines Timers ist in 3
> Zeilen erledigt und wenns platzmässig eng wird, auch in einem
> Unterprogramm für alle drei ISR gemeinsam machbar.

Das ist nicht der Punkt. Beim Zurücksetzen des Timers verlierst du 
Ticks. Mit einem durchlaufenden Timer und Capture aber nicht.

> Es ist ausserdem eine höhere Auflösung möglich, da man wirklich nur die
> max. 2ms erfassen muss und nicht den gamzen 20ms Frame, wenn man hohe
> Auflösung haben möchte.

Ich verstehe dein Argument nicht. Abgesehen davon, daß die Auflösung nur 
von der Timer-Frequenz abhängt. Und daß die Genauigkeit bei durch- 
laufendem Timer und Capture natürlich besser ist. Weil meine keine Ticks 
verliert und die Latenz der ISR dann keinen Einfluß hat.

> Da muss man nicht kunstvoll den Timer mit ICP laufen lassen

Ich verrate dir mal ein Geheimnis: ICP und OC sind Grundfunktionen der 
Timer. Die wurden extra dafür gebaut. Die Verwendung dieser Features ist 
in etwa so "kunstvoll" wie das Einlegen des zweiten Gangs beim Auto. So 
wie du redest fährst du wahrscheinlich alle Strecken nur im ersten Gang?

> und externe Hardware dazu basteln

Für die Verwendung von ICP braucht man genau gar keine extra Hardware. 
Die braucht man nur, wenn man ICP-Kanäle sparen will/muß.

Draco schrieb:
> mit einem AVR (Atmega32u4).
Was soll der sonst noch tun? Wie genau muss die Zeit ermittelt werden?
Hintergrund: wenn du sonst nicht viel zu tun hast, dann kannst du 
einfach die Eingänge pollen...

Matthias S. schrieb:
> Ihr tut ja gerade so, als darf man um Gottes Willen keinen Timer
> stoppen und zurücksetzen.
Würde ich auch nie tun. Denn dadurch hast du potentiell den doppelten 
Jitter: einmal beim Zurücksetzen und einmal beim Auslesen.

Mal ein Beispiel:
Wenn man die Aufgabe hat, etwas jede Stunde zu tun, dann setzt man ja 
auch nicht jede Stunde seine Armbanduhr auf 0 Minuten zurück, sondern 
lässt sie einfach durchlaufen. Wenn man dann z.B. um 9 Uhr auf dem Klo 
sitzt und mal 3 Minuten zu spät kommt, kann man diesen Fehler um 10 
Uhr wieder korrigieren. Hätte man um 9 die Uhr zurückgesetzt, dann würde 
sich so ein Fehler aufsummieren...

Fazit: Timer laufen durch. Zeiten werden durch Differenzen berechnet.

Draco schrieb:
> Das der Überlauf nur nach "oben" geht?
Jetzt hast du es: da ist kein zusätzlicher Aufwand da, wenn man nur mit 
Differenzen rechnet.

Binär sieht das so aus:
1000 - 65000 -->
0x03E8 - 0xFDE8 = 0x0600 (+ "Unterlauf"-Flag, das keinen interessiert)


Nur darf du eben nicht der zweite Zeitpunkt den ersten "überholen"...

Draco schrieb:
> m.n. schrieb:
>> Du darfst sowieso Alles machen ;-)
>> Aber warum sollte man einen Timer derart behandeln, daß er zu sonst
>> nichts mehr nützlich ist. Lasse ihn mit höchster Geschwindigkeit
>> durchlaufen und Du kannst damit einen 1 ms Tick erzeugen, die
>> PMW-Ausgänge verwenden, und und und.
>
> Das ist schon richtig, aber was mach, wenn ich während eines Zyklus
> einen Timer-Überlauf habe? Dieser muss ja auch separat abgefangen werden

Nein, muß er nicht. Schrieb ich oben schon.

1

#include <stdio.h>

2

int main()

3

{

4

  unsigned short t1= 0xFFF0; 

5

  unsigned short t2= 0x0100;

6

  printf("zwischen Zählerstand %hu und %hu liegen %hu Ticks\n", 

7

         t1, t2, t2-t1);

8

}

1

$./test 

2

zwischen Zählerstand 65520 und 256 liegen 272 Ticks

> Die drei PWM Kanäle extern zu einem PPM Summensignal zusammenzufassen,
> wäre echt ne schöne Spielerei, kann man sich vielleicht mal auf die
> Agenda schreiben. Aber für das aktuelle vorhaben zu overkill.

Eigentlich nicht. Mir ist auch immer noch nicht klar, warum es unmöglich 
sein soll, an das originale PPM-Signal zu kommen.

Ansonsten ist das auch nicht sonderlich aufwendig:

1

                   .---------------------*--- ...

2

          C        |            C        |

3

Kanal 1 --||--*--|<   Kanal 2 --||--*--|<

4

              |    |e               |    |e

5

              R    |                R    |

6

              |    |                |    |

7

             GND  GND              GND  GND

Pro Kanal ein kleiner Kondensator, sagen wir mal 1nF und ein Widerstand, 
sagen wir 10K und ein Transistor wie BC546 oder n-FET wie BSS138. An die 
verbundenen Kollektoren (Drains) noch einen Pullup und schon hat man ein 
(invertiertes) PPM-Signal, das man mit einem einzigen Pin und ICP auf 
die fallenden Flanken simpelst auswerten kann.

> An die Pin-Change-Interrupts hatte ich anfänglich auch gedacht, der
> Vorteil davon wäre: Ich könnte natürlich mehr als 3 Kanäle einfach
> abfragen.

Das halte ich nun wieder für dämlich. Das skaliert nämlich nicht, wenn 
du für jeden weiteren Kanal einen Pin um µC brauchst. Die Hardware- 
Variante von oben braucht lediglich weitere drei Bauteile pro Kanal.

m.n. schrieb:
> Axel S. schrieb:
>> Das halte ich nun wieder für dämlich.
>
> Du meintest sicherlich 'ungeschickt'?

Meinetwegen ;)

Lothar M. schrieb:
> Fazit: Timer laufen durch. Zeiten werden durch Differenzen berechnet.

Wie soll denn bitte durchs Zurücksetzen 'Jitter' entstehen (davon mal 
abgesehen, das wir hier höchstens von ein/zwei Takten reden und das bei 
RC Signalen überhaupt keine Rolle spielt - jeder Joystick im Sender ist 
viel ungenauer)
Der Vorgang des Timer Stoppens und Lesens dauert immer haargenauso lang 
und geht deswegen als Konstante ein. Die einzige Unsicherheit ist das 
Auftreten des IRQ innerhalb eines 2 oder 3 byte Befehls.
Und das kannste knicken, das sind die o.a. 1-3 Takte Unsicherheit. Würde 
der MC mit 32kHz laufen, macht sich das evtl. sogar bemerkbar - aber 
schon bei 1MHz kannste es vergessen.
Und beim Tiny, der gar kein ICP hat, musste ich es auch schon so machen 
(Servoelektronik) und das funktioniert ganz prima.

Draco schrieb:
> Ich möchte drei PWM Signale / Kanäle von einem RC Empfänger mit einem
> AVR (Atmega32u4).

Aha ...!?

Was ist das Ziel?
Du brauchst das PPM-Signal?

Das ist ein EXOR Baustein!

1

             ____

2

Kanal 1 o---| =1 |             ____

3

            |    |----,-------| =1 |

4

Kanal 3 o---|____|    |       |    |----o PPM

5

                      R   ,---|____|

6

                      |   |

7

                      +---'

8

                      |

9

                      C

10

                      |

11

                     GND

Die andere Richtung geht mit einem 4017.


Gruß

Jobst

Matthias S. schrieb:
> Wie soll denn bitte durchs Zurücksetzen 'Jitter' entstehen
Wenn das Zurücksetzen z.B. durch einen Interrupt verzögert wird: der 
Pinchange-Interrupt kommt, wird aber erst ein paar Takte später 
abgearbeitet, weil gerade noch ein SIO-Interrupt "dran" ist. Dann kommst 
du ein paar Takte zu spät und setzt damit deine "Uhr" (=Timer) zu viel 
zurück.

Oder auch so: wenns es im Langsamen schon mit der Armbanduhr schief 
gehen wird, dann geht es sicher auch im Schnellen mit dem uC-Timer 
schief. Das merkt man natürlich nicht sofort (in der Anwendung hier 
mit einem exklusiven Timer für die Aufgabe gar nicht), aber einzelne 
Takte summieren sich auf.

Und wenn man mehrere solcher Messungaufgaben parallel machen möchte, 
aber nur wenige Timer hat, dann bleibt einem gar nichts Anderes übrig, 
als mit einer durchlaufenden Uhr zu arbeiten. Oder was wäre, wenn es nur 
1 Kirchenuhr im Dorf gibt, aber jeder zum Eierkochen die Kirchenuhr auf 
0:00 stellen würde? Dann müssten alle nacheinander ihre Eier kochen und 
hinterher wüsste niemand mehr, wie spät es ist...

Draco schrieb:
> Das Problem was besteht, ist der mehrmalige Überlauf während der
> Pulsepause zwischen Kanal3 und zurück zum Kanal1.
Warum lässt du den Timer nicht einfach langsamer laufen? So, dass ein 
kompletter Zyklus ohne Überlauf da rein passt?

Oder warum startest du als Kompromiss nicht den Timer m Kanal 1, lässt 
ihn einmal hochlaufen und nimmst den Überlauf als Synchronisationshilfe: 
nach einem Überlauf kommt wieder der Kanal 1.