Hallo Hardware-Freaks,
ich habe folgendes Problem bei der Taktgenerierung am Parallelport mit ca. 10kHz.
ich habe dazu folgende eigene Interrupt-Service-Routine geschrieben:
INTVektor von Interrupt Timer0 auf eigene ISR umgebogen
am Schluss wird alter INT-Vektor von ISR08 aufgerufen
nach Abarbeitung der alten INT08 wird EOI in den PIC reingeschrieben.
Zählerwert im Timer0 vom PIT8253 mit Teilwert 16 statt 65536
Das heisst Auslösen des Timer0-Interrupts alle 13,4 MicroSekunden statt alle 54,9255 Millisekunden
Damit INT08 für die DOS-Uhr wieder korrekt läuft
Zählervariable die immer auf 65536 / 16 = 4096 zählt damit
die Aufrufe von INT08 wieder im richtigen Zeitintervall von 55 millisec erfolgen
Meine eingehängte ISR dient zum Taktimpulse erzeugen.
Als Test ob die Timerinterrupts wirklich absolut regelmässig ausgelöst
werden habe ich ein bit am Parallelport getoggelt und mir den Signalverlauf an eimem Speicheroszilloskop angeschaut
ca. alle 950 Microsekunden gibt es eine Zeitverzögerung von 12,5 bis 50 Microsekunden.
Ich hab schon versucht den NMI über Bit7 des Ports 70h zu maskieren,
die Zeitverzögerungen treten aber auch auf wenn Bit7 in Port 70h 1 ist
Wer um alles in der Welt pfuscht da dem INT0 rein der doch eigentlich
die allerhöchste Interrupt-Priorität hat ?
Gibt es da absolut nicht abschaltbare hardware-Interrupts
muss ich trotzdem andere Interrupts mit niedrigerer Priorität im PIC sperren?
Bin dankbar für Hinweise aller Art
viele herzliche Grüsse
Stefan Ludwig
Hallo,
mein Gott ist das schon lange her - aber ich denke, du müsstest die Funktion von Interrupts allgemein und des 8253 nochmal sorgfältig studieren: Priorität heisst keineswegs, dass ein höher priorisierter IRQ einen anderen bzw. dessen ISR unterbrechen kann. Bei X86 ist es meiner Erinnerung nach so, dass ein akzeptierter IR generell das EI-Bit zurücksetzt und Interrupts daher erst wieder akzeptiert werden, wenn in der ISR EI wieder gesetzt wird. Anders gesagt, eine ISR kann das System beliebig lange exklusiv belegen.
Die Priorität komtt bloss bei gleichzeitigen IRQs ins Spiel.
Gruss Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Peter,
also das ganze läuft unter MS-DOS 6.22 und Programm in Borland-Pascal 7.0
ich habe inzwischen auch ALLLE Interrupts im MasterPIC ausser dem Timer0 und im SlavePIC maskiert. Die Zeitverzögerungen treten trotzdem auf.
weitere Details:
das ganze ist ein kontron PC104 board mit AMD Geode GX1 Prozessor mit 300 MHz
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Stefan,
also das ganze läuft unter MS-DOS 6.22 und Programm in
Borland-Pascal 7.0
ich habe inzwischen auch ALLLE Interrupts im MasterPIC ausser
dem Timer0 und im SlavePIC maskiert. Die Zeitverzögerungen
treten trotzdem auf.
Du machst da einen Denkfehler !
Der TimerTick, den du jetzt frisiert hast, muss ja nur im Mittel stimmen. Für die Uhr spielt es absolut keine Rolle, wenn sie ab und zu mal 20ms zu spät incrementiert wird, das nächste mal erfolgt dann halt einfach etwas früher.
MS-DOS war nie für Echtzeit gedacht. Deshalb werden an kritischen Stellen im MS-DOS einfach alle Interrupts gesperrt bis dieser kritische Teil abgearbeitet ist. Damit gehen deine Interrupts zwar nicht verloren, aber der Aufruf der IRQ-Routine wird im ungünstigsten Fall um diese Sperrzeit verzögert.
Allerdings wirst du auch bei einem Realtime-Betriebssystem immer Jitter auf deinem Ausgang haben. Der einzige Unterschied wäre, dass dir der maximalen Zeitversatz garantiert wird. Allerdings ist die Zeit zwischen dem Auftreten des Interrupts und dem Aufruf der Interrupt-Routine immer etwas variabel. Je nachdem welchen Befehl die CPU gerade ausführt, dauert es unterschiedlich lange bis dieser abgearbeitet ist.
Hinzu kommt noch der Zustand des Cache. Befindet sich der Interrupt-Code schon im Cache geht es schneller, als wenn der Cache erst geladen werden muss.
Desweiteren wird noch ein DMA-Kanal für den Refresh des Hauptspeichers benutzt. Je nachdem wie der Refresh gemacht wird, führt das auch noch zu unterschiedlichen Verzögerungen.
Wenn das Ganze jitterfrei sein muss, musst du direkt einen Ausgang eines der Hardware-Timer verwenden.
MfG Peter(TOO)