15 x 1ms Impulsbreite messen

[Mehel (Gast)]

Hallo,
ich muss auf 15 Kanälen die Impulsbreite eines ca. 1ms breiten Signals 
messen und frage mich ob das mit einem Atmega in C zu machen ist? Das 
System soll die Daten als I2C slave zur Verfügung stellen.

Das Problem ähnelt der PPM decodierung bei Funkfernsteuerungen da 
zwischen den Pulsen auch ca. 20ms Zeit ist. Ich hab aber noch kein 
Projekt mit so vielen Kanälen gesehen. Ausserdem kommen die Impulse bei 
meinem Problem nicht sequentiell sondern asynchron...

Bei 8 bit Auflösung müsste ich die Pins mit ca. 512kHz abfragen, dh. da 
bleiben nur 40 Takte bei 20Mhz... und ich hab warscheinlich berechtigte 
Zweifel dass das reicht. Bei Interrupts könnte ich potentiell eine 
Änderung übersehen (abgesehen davon, dass ich keine 15 Interrupts 
habe...)

Weiss jemand von Euch einen Kniff? Gibt's da spezielle ICs die sowas 
machen?

-mj

[MB (Gast)]

Ich kann dir leider nicht detailliert weiterhelfen, aber vielleicht 
hilft es dir das ganze direkt in einen SRAM (16Bit) zu schieben. Durch 
das anschließende Auslesen (nach der Messung) sind die Zeitpunkte durch 
die Adresse auch bekannt. Das ganze muss eben schnell genug sein um eine 
hohe Auflösung gewährleisten zu können. (wegen den Flanken, sofern diese 
relevant sind)b

Fraglich ist nur, ob das ebenfalls keinerlei Timing-Problemen zum Opfer 
fallen wird. Ich glaube ein SRAM sollte aber nicht mehr als 70ns 
brauchen.
Nachteil ist natürlich der höhere Schaltungsaufwand und die Kosten.

[Falk B. (falk)]

@Mehel (Gast)

>Projekt mit so vielen Kanälen gesehen. Ausserdem kommen die Impulse bei
>meinem Problem nicht sequentiell sondern asynchron...

Dann wird das wohl nix mit dem AVR. der hat keine 15 ICP Eingänge.

>Weiss jemand von Euch einen Kniff?

Da wird man wohl einen CPLD oder so brauchen. Oder man nimmt 15 kleine 
8-Pin AVRs, welche einen Kanal messen und per I2C zurückmelden.

> Gibt's da spezielle ICs die sowas machen?

Keine Ahnung. AFIAK nein.

MfG
Falk

[STK500-Besitzer (Gast)]

>Dann wird das wohl nix mit dem AVR. der hat keine 15 ICP Eingänge.

Könnte man nicht ein ICP per PinChange-Interrupt realisieren?

[Falk B. (falk)]

@  STK500-Besitzer (Gast)

>Könnte man nicht ein ICP per PinChange-Interrupt realisieren?

Nicht bei 512 kHz Abtastrate und 15 ASYNCHRONEN Kanälen.

MFG
Falk

[Gasst (Gast)]

>Das System soll die Daten als I2C slave zur Verfügung stellen.

Wenn der Platz vorhanden ist, könntest Du 15 x Tinys einsetzen - pro 
Kanal einen. Der passende Typ sollte IIC ermöglichen, oder ein zentraler 
AVR sammelt die Daten nur ein (seriell) und sendet sie weiter.

[Hauke R. (lafkaschar)]

Brauchst du bei dem Signal wirklich 10 Bit Auflösung? Mit weniger 
auslösung, d.h. geringerer Samplerate sollte das ein AVR gerade noch so 
per polling schaffen, vielleicht etwas Jitter, aber evtl könnte man die 
kommunikation mit einem 2. AVR lösen, der die Daten Parallel vom ersten 
bekommt.

[Fabian (Gast)]

Wieso geht das nicht mit dem internen SRAM des AVR?
Ein Timer auf 512 kHz einstellen. Innerhalb der ISR 2 Ports in ein int 
einlesen und mit dem Int aus der "letzten Runde" mit exor vergleichen. 
Wenn ungleich 0 > Flag setzen und in der while(1) schleife asynchron 
dieses Flag abfragen. Ist es gesetzt, auswerten, welches Bit sich 
geändert hat.

Parallel dazu läuft ein Timer (oder der selbe), der dann die 
entsprechende Zeit zählt.

[Hans-jürgen H. (hjherbert)]

Wieso geht das nicht mit dem internen SRAM des AVR?
Ein Timer auf 512 kHz einstellen.

Innerhalb der ISR
Zeitzähler erhöhen
2 Ports in ein int
einlesen und mit dem Int aus der "letzten Runde" mit exor vergleichen.
Wenn ungleich dann Zeitstempel und Wert abspeichern.
              und den Abspeicherindex erhöhen.
Nach dem 30 mal den Interrupt wieder sperren.

[Gasst (Gast)]

>Innerhalb der ISR 2 Ports in ein int einlesen und mit dem Int aus >der "letzten 
Runde" mit exor vergleichen.

... und in der restlichen Zeit den Prozessor noch schlafen legen.
Für eine erfolgsversprechende Lösung ist das Timing zu eng (riskant).