Hallo,
ich würde gerne eine Jittermessung mit einem PIC16F877 realisieren. das
Problem liegt jetzt daran, dass der Jitter nicht größer als 600ns sein
darf, d.h. if jitter < 600ns mache nichts
if jitter >= 600ns gib error aus.
Bevor ich mich jetzt voll ins "Vergnügen" stürze wollte ich einen
erfahrenen Microcontroller-Programmier fragen, ob dies überhaupt möglich
ist?
Ich dachte mir irgentwie 2 Interrupt-Eingänge und dann "wenn Zeit ist"
die beiden Zeiten vergleichen. Bei einer Befehlszeit von 200ns dürfte
das eintreten der Interrupts und abspeichern dieser Counter nicht mehr
als 3Befehle lange sein.
Geht sich das aus?
Wenn nicht, hat jemand eine bessere Idee?
mfg
woldo
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
Hallo Christoph,
danke für die schnelle Antwort.
Es gibt einen Master der jede 1ms einen 30µs breiten Takt ausgibt. Der
Slave sollte nun genauso jede 1ms (zur selben Zeit) einen 30µs Takt
ausgeben (synchronisieren). Die jtternde Flanke wiederholt sich also
jede ms. Der "error" soll nun ausgegeben werden wenn der Slavetakt
entweder 600ns zu früh oder 600ns zu spät kommt.
mfg
woldo
@ 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
Hallo
@Severino R
"Das Capturen kann man mit Polling (ständiges abfragen) oder durch einen
Interrupt organisieren. Polling ist einfacher zu programmieren,
verbraucht aber viel Rechenzeit."
Dann sind wir wohl wieder beim Interrupt,oder?
Qfalk
"Allerdings weiss ich jetzt nicht, ob beim
PIC der Takt für die ICP nicht auch erst durch 4 geteilt wird."
Wo wird denn das Input Capture Einheit (ICP) sonst verwendet?
lg
woldo
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
