Interrupt

Benutzen Sie einfach einen der GPIOs. Für die GPIO-Pins gibt es Routinen zur Behandlung von Interrupts.

Mit freundlichen Grüßen,

H. Keller

Quote from "Domandl"

DWORD dwIRQ = 42; // Port 2 Pin 40

42 ist zwar die Antwort auf die Frage nach dem Leben, dem Universum und allem (siehe "Per Anhalter durch die Galaxis"), aber leider klappt das so universell nicht bei der PicoMOD1. Hier muss dann doch die korrekte Bitnummer des Pins mitgegeben werden. Pin 40 liegt laut DeviceDriver-Doku auf Bit 18, wie Sie ja auch schon in den Konfigurationswerten bei UseAsIOA u.ä. korrekt eingestellt haben. Also müssen Sie dwIRQ = 18 angeben.

Mit freundlichen Grüßen,

H. Keller

Quote from "Domandl"

Dec 24 als IRQ funktioniert.

Was mich nun wieder irritiert, da ich eigentlich dezimal 18 gemeint hatte, nicht hex 18.

Quote

Kann der GPIO5 beim Starterkit verwendet werden als DIO? Die Dokumentationen geben da unterschiedliches an (Picomod1_Startinterface_deu.pdf + Picomod1_DeviceDriver_eng.pdf)?

Sie müssen unterscheiden zwischen den Bezeichnungen einzelner Stecker auf dem Starterkit und den Bezeichnungen auf dem Verbindungsstecker auf der PicoMOD1. In der DeviceDriver-Doku werden *nur* die Bezeichnungen des PicoMOD1-Steckers verwendet.

Der Pin GPIO5 vom GPIO-Stecker des Starterkits liegt bei der PicoCOM1 selbst auf Pin24. Und den können Sie sehr wohl im Device-Treiber konfigurieren: Port 1, Bit 1.

Mit freundlichen Grüßen,

H. Keller

Zuerst mal muss der InterruptDone() mit in die Schleife rein. Jedesemal wenn WaitForSingleObject() mit WAIT_OBJECT_0 zurückkehrt, muss InterruptDone() aufgerufen werden. Ohne das bekommen Sie nur einen einzigen Interrupt und dann nie wieder.

Was Sie stattdessen vor dem IOCTL_DIO_RELEASE_SYSINTR machen müssen, ist ein Aufruf der Funktion InterruptDisable().

Mit freundlichen Grüßen,

H. Keller

Eigentlich ist es in WindowsCE gar nicht gedacht, dass ein Anwenderprogramm selbst Interrupts verarbeitet. Das ist also eine Besonderheit von uns, dass dies überhaupt geht. Eigentlich soll auf Interrupts nur in Rahmen von Treibern reagiert werden. Der Grund hierfür ist, dass Micorsoft eigentlich davon ausgeht, dass eine WindowsCE-Plattform eigentlich keine offene Plattform ist, sondern zur Entwicklung für ein spezielles Gerät verwendet wird und die Entwickler den Platform-Builder zur Verfügung haben und somit selbst Treiber entwickeln können. Wir bei F&S wollen aber diese niederen Dinge dem Kunden abnehmen und bereiten Treiber und Einstellungen in entsprechend vorkonfigurierten Kerneln vor. Somit kommt der Kunde ohne Platform-Builder aus.

Leider macht Microsoft uns hier immer mehr einen Strich durch die Rechnung. So ist dieses Konzept, wie wir das hier machen, schon unter Windows CE 6.0 nicht mehr möglich. Wir sind gerade dabei, hier ein allgemeingültiges Konzept zu erarbeiten, wie man das doch irgendwie allgemeingültig und zukunftssicher hinkriegt.

Insofern vermute ich, werden Sie in der allgemeinen WindowsCE-Literatur zum Thema Interrupts nicht fündig. Da müssen Sie schon eher Richtung Gerätetreiber-Entwicklung (Device Driver) suchen.

Mit freundlichen Grüßen,

H. Keller

Quote from "Domandl"

Ergebnis:
Es zeigte sich, dass das Antwortsignal um ca. 50 - 200 µs (manchmal auch mehr) jittert.

Fragen:
Warum ist das so, wie kommt es dazu?
Kann eine Vorhersagen zu den Antwortzeiten getroffen werden?
Wie wird ein GPIO-Eingangssignal zu einem Interrupt?
Können die Registry-Einstellungen oder sonstige Einstellungen (welche?) das Ergebnis verändern?
Können die Prioritäten Auswirkungen auf das Ergebnis haben? Sollte im Programmbeispiel nicht, da höchste Priorität.

Display More

Ein Interrupt wird im Kernel durch eine Interrupt-Handler-Funktion abgearbeitet. Je nach aufgetretenem Interrupt wird der entsprechend damit assoziierte Event gesetzt. Dann wird der Scheduler aufgerufen. Gibt es hierdurch nun einen höherpriorisierten Thread, der lauffähig geworden ist, wird sofort zu diesem Thread gewechselt. Wenn nicht, wird am gerade aktuellen Thread weiter gearbeitet, bis dessen Zeitscheibe um ist.

Man sieht also, dass die Reaktionszeit einzig und allein von der Priorität abhängt, die der zugehörige Interrupt Service Thread (IST, also Thread3 in Ihrem Beispiel) hat. Indem man diesem Thread eine sehr hohe Priorität gibt, kann man fast 100% sicher sein, dass alle Impulse auch tatsächlich empfangen werden, vorausgesetzt sie kommen nicht schneller als die reine Abarbeitungszeit des Codes in diesem Thread.

Die von Ihnen gemessene Verzögerungszeit addiert sich also aus folgenden Teilwerten auf.

• Dauer, bis tatsächlich der Interrupt hardwaretechnisch abgearbeitet wird, also z.B. bis alle Register gesichert sind
• Abarbeitung des kernelinternen Interrupt-Handlers, der die Interruptquelle herausfinden und den zugehörigen Event finden und setzen muss
• Laufzeit des Schedulers, der eine Neubewertung der Prioritäten vornehmen und Ihren IST aktivieren muss; sprich es findet ein Threadwechsel statt
• Laufzeit des Codes in Ihrem IST, bis letztendlich der andere Pin geschaltet ist, also z.B. die Laufzeit von DeviceIoControl(), die wegen dem Wechsel zum DIO-Treiberkontext nicht zu vernachlässigen ist

Der Jitter, also die Schwankung der Zeit bis zum Sichtbarwerden des Signals auf dem zweiten Pin, ergibt sich daraus, dass es noch höher priorisierte Threads als Ihren Thread3 gibt. Denn anders als beim Desktop-Windows gibt es unter Windows CE 256 verschiedene Prioritätsstufen. Und mit THREAD_PRIORITY_TIME_CRITICAL sind sie noch lange nicht auf höchster Priorität. Sie sind noch irgendwo weit über 200 (große Werte bedeuten niedrige Priorität). Die internen Treiber laufen jedoch üblicherweise auf einer Priorität um die 100 und sind damit noch deutlich höher priorisiert. Dadurch kommen diese vor Ihrem Zählthread zum Zuge. Je nach externen Events, also z.B. Traffic auf dem Ethernet, kann also ihr Code tatsächlich noch mehr oder weniger stark ausgebremst werden.

Probieren Sie mal, Ihrem Thread z.B. eine Priorität von 90 zu geben. Dann sollte der Jitter weg sein.

Mit freundlichen Grüßen,

H. Keller

Quote from "Domandl"

#define THREAD_PRIORITY_TIME_CRITICAL 0.

Besser als 0 geht doch nicht, oder verwechsle ich da was?

Da haben Sie nun wieder recht. Normal sind diese Werte nur für die Funktion SetThreadPriority() gedacht und da wird THREAD_PRIORITY_TIME_CRITICAL auf die Priorität 248 gemapped. Sie Haben aber ja die Funktion CeSetThreadPriority() verwendet, wo die 0 direkt gesetzt wird. Ja, höher priorisiert als das geht es tatsächlich nicht. Warum sich dann so ein Jitter einstellt, kann ich auch nicht sagen.

Das heißt, haben Sie schon mal überprüft, ob Sie überhaupt jeden Interrupt mitkriegen, oder ob da welche fehlen? Weil wenn mal ein Interrupt ausgelassen wird, könnte das so einen Jitter auch erklären. Triggern Sie auf Flanke oder Level?

Mit freundlichen Grüßen,

H. Keller

Hmm, ich habe mich vielleicht falsch ausgedrückt. Es geht darum, ob die Anzahl extern erzeugter Interrupts und die Anzahl durchs Programm gezählter Interrupts identisch ist, und zwar möglichst bei einer Frequenz gezählt, wo die PicoMOD1 auf jeden Fall noch mitkommen sollte, also ca. 100 Hz bis 1 kHz.

Warum ich hier nachfrage: wir hatten bei der NetDCU8, die den gleichen Prozessor einsetzt wie die PicoMOD1, auch schon den Verdacht, dass hier hardware-mäßig hin und wieder kantengetriggerte Interrupts verloren gehen. Dort haben wir dann die interne Interruptverarbeitung umgestellt und kantengetriggerte Interrupts durch levelgetriggerte Interrupts emuliert. Seitdem haben die Kunden von keinen Problemen mehr berichtet.

Ich bin mir momentan aber nicht ganz sicher, ob diese Änderung nun auch schon Einzug in den PicoMOD1-Kernel gefunden hat. Wenn nein, wäre dies nun vielleicht ein weiterer Nachweis, dass es bei kantengetriggerten Interrupts tatsächlich Probleme gibt und man hier auch tunlichst diese Emulation einbauen sollte.

Mit freundlichen Grüßen,

H. Keller

Wenn Sie bei einer halbwegs niedrigen Frequenz alle Interrupts zählen, also keinen verlieren, dann ist es kein Problem der internen Interruptverarbeitung. Meine Theorie für den Jitter war ja, dass hier und da ein Impuls verloren geht und darum erst der nächste Interrupt erkannt wird und sich so mal ein kleinerer Abstand (alle Interrupts erkannt) und mal ein größerer Abstand (wenn ein Impuls verloren ging) bildet. Wenn Sie aber alle Impulse zählen, ist doch alles OK. Nur dann habe ich nun auch so langsam keine Erklärung mehr für das Zustandekommen des Jitters. Kann es ganz banal sein, dass Priorität 0 einfach nicht erlaubt ist und entsprechend der Thread gar nicht auf hoher Priorität läuft? Probieren Sie mal noch einen Wert von 10. Der nächste Treiber dürfte eigentlich erst in der Gegend von 100 kommen, insofern wäre 10 immer noch absolut höchste Priorität.

Dass ab irgendeiner höheren Frequenz dann Impulse verloren gehen, ist normal, da dann das Board aufgrund der von mir schon mal genannten Verzögerungen bzw. der reinen Laufzeit des Codes einfach nicht mehr mitkommt, die Interrupts zu verarbeiten. Sprich es kommt schon der nächste Interrupt, während noch der vorherige verarbeitet wird. Dieser neue Impuls geht dann verloren.

Solange Sie also alle Impulse empfangen, brauchen wir nichts in Richtung emulierter Flanken-Interrupts machen. Das wäre sowieso eine Änderung im Kernel, da können Sie selbst leider nicht helfen.

Mit freundlichen Grüßen,

H. Keller