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