jittermessung mit PIC16F877

Was jittert denn da? Eine hohe Frequenz oder etwas niederfrequentes, wie 
oft wiederholt sich die jitternde Flanke?
Das Jittern kann doch in beide Richtungen stattfinden, 600ns vor oder 
nach dem Sollzeitpunkt, muß beides (als Betrag) ausgewertet werden?

Das wird wohl eher schwierig.

Da der Interrupt im PIC nur zu bestimmten Zeiten ausgelöst wird 
(innerhalb des Taktzyklus), erzeugt der PIC selber beim Messen einen 
Jitter. Und der wird verhältnismässig gross sein.
Die Frage ist auch, mit welcher Genauigkeit die 600ns erkannt werden 
sollen, also die Schärfe. Wenn irgendetwas zwischen 400 und 800ns ok 
ist, klappts eher. Wenn die Angrenzung genau sein soll, geht das so 
nicht.

Besser ist wohl, das CCP (CAPTURE/COMPARE/PWM MODULE) zu verwenden.
Siehe auch:
http://www.sprut.de/electronic/pic/grund/capture.htm

Severino

@ woldo (Gast)

>jede ms. Der "error" soll nun ausgegeben werden wenn der Slavetakt
>entweder 600ns zu früh oder 600ns zu spät kommt.

Naja, dafür ist die Input Capture Einheit (ICP) geradezu ideal. Sie kann 
Flanken mit der Auflösung des Quarztaktes Messen. 10 MHz -> 100ns. Und 
das ohne Belastung der CPU. Allerdings weiss ich jetzt nicht, ob beim 
PIC der Takt für die ICP nicht auch erst durch 4 geteilt wird.

MFG
Falk

Man muss schon unterscheiden, ob eine Zeit ermittelt (Auflösung?) und 
anschliessend mit 600ns verglichen werden soll, oder ob es darum geht, 
mit einer Auflösung von 600ns das Vorhandensein eines Signals zu 
erkennen. Wenn der Fehler also nur -600ns, 0 oder +600ns sein kann, 
reicht es z.B. 30..400ns vorher und nachher zu testen, ob das Signal da 
ist.

Bei den PICs heisst das Ding übrigens CCP, nicht ICP (wichtig, falls man 
danach suche will...).
Das CCP-Modul verwendet TMR1, welcher maximal mit dem Systemtakt läuft. 
Der Systemtakt entspricht bei diesem und den meisten PICs dem 
Oszillatortakt durch vier. Wenn man den PIC mit 20MHz taktet, gibt dies 
eine Auflösung von 200ns.

Das Polling vs. Interrupt bei Sprut bezieht sich auf das Lesen des 
Statusbits des CCP-Moduls, nicht auf das "Samplen" des Signals.

Übrigens würde ich den PIC16F877A (...A!) verwenden, der aktueller ist.
Oder gar einen 40MHz PIC, wenn die Auflösung nicht ausreicht.

Alles klar?

Severino

@ Severino R. (severino)

>Übrigens würde ich den PIC16F877A (...A!) verwenden, der aktueller ist.
>Oder gar einen 40MHz PIC, wenn die Auflösung nicht ausreicht.

Oder einen AVR, der den Quarz nicht durch 4 teilt. Dann hat nämlich ein 
20 MHz AVR die dopplete Auflösung wie ein 40 MHz PIC.

MFG
Falk

Falk Brunner wrote:

> Oder einen AVR, der den Quarz nicht durch 4 teilt. Dann hat nämlich ein
> 20 MHz AVR die dopplete Auflösung wie ein 40 MHz PIC.
>
Oder einen xxx oder yyy oder zzz, der ist nämlich schneller, oder 
billiger oder die Entwicklungsumgebung ist toller, oder der hat mehr 
Speicher, oder der Compiler optimiert besser, oder der andere ist 
bugfreier oder... ;-)

woldo wollte halt einen PIC16F877 nehmen.

Severino