Hallo. Ich möchte unter Windows CE einige Sensoren abfragen, die an verschiedenen Schnittstellen angebunden sind. Ein Sensor wird über RS485 angesprochen und der andere über SPI. Da ich die Daten beider Sensoren möglichst vom gleichen Zeitpunkt haben möchte, stellt sich mir die Frage ob das überhaupt möglich ist. Ich bin noch neu auf dem Gebiet der Win CE Programmierung, muss ich dazu sagen. Meine jetzige Vorstellung ist diese: Wenn ich zwei Routinen habe, die SPI bzw. RS485 bedienen, kann ich sie logischerweise nur nacheinander laufen lassen, da meine Hardware nur einen Prozessorkern besitzt. Also könnte Windows CE bestenfalls die erste Routine abarbeiten und direkt im Anschluss die zweite. Wenn die Routinen effizient programmiert sind und nicht viel Zeit in anspruch nehmen, dann müssten die gewonnenen Messwerte zeitlich sehr dicht beieinander ligen. (was nun "direkt im Anschluss" und "zeitlich zehr dicht" genau bedeutet ist erstmal egal.. einige ms vielleicht). Im schlimmsten Fall wird das OS die erste Routine abarbeiten und sich dann einige Zeit mit anderen Rechenaufgaben beschäftigen, bis die nächste abgearbeitet wird. Ist diese Vorstellung erstmal ok so? Falls ja oder falls ich total daneben liegen sollte stelle ich mir trotzdem die Frage, wie soetwas am besten programmiert werden sollte um das geforderte Kriterium (zeitnahe Messwerte) zu erfüllen? Hoffe Ihr könnt mich verstehen :) Guten Abend. Arletta
Die Vorstellungen sind fast richtig. Man kann tatsaechlich Programme gleiczeitig ausfuehren. Wenn das innerhalb eine einzelnen Programmes geschehen soll, so nennt sich das Multithreading. Man kann mehrere Threads gleichzeitig laufenlassen. Dh das Stichwort fuer weitere Recherchen ist : Multithreading
Arletta schrieb: > Wenn ich zwei Routinen habe, die SPI bzw. RS485 bedienen, kann ich sie > logischerweise nur nacheinander laufen lassen, da meine Hardware nur > einen Prozessorkern besitzt. nicht unbedingt. Vermutlich verbingt der Prozesser bei diesen schnittstellen die größte zeit mit Warten. Wenn also die Treiber und Hardware sinnvoll arbeiten, dann können die Daten von beiden schnittstellen gleichzeitig an den Rechner geliefert werden, dort werden sie dann nacheinander an die Anwendung übergeben.
Arletta schrieb: > Im schlimmsten Fall wird das OS die erste Routine abarbeiten und sich > dann einige Zeit mit anderen Rechenaufgaben beschäftigen, bis die > nächste abgearbeitet wird. > Ist diese Vorstellung erstmal ok so? Nein. Wann Windows CE welchen Code abarbeitet ist (von Interrupts einmal abgesehen) ganz in der Hand des Entwicklers. Windows CE ist ein Echtzeitbetriebsystem mit 256 Prioritäten. Durch die Wahl der Prioritäten für deine Threads hast Du volkommenen Kontrolle über den Ablauf! CeSetThreadPriority() ist dein Freund... Achtung: 0 ist die höchste Priorität und kann nur von Interrupts unterbrochen werden!
Ist denn Priorität 0 vom time-slicing ausgeschlossen und kann daher nicht durch gleiche Priorität (0) unterbrochen/abgelöst werden? (Abgesehen davon, dass der Scheduler ohne Interrupts wohl auch nicht arbeiten könnte. Irgendwie müssen die Ereignisse, die zu einer Umschaltung führen, ja vermittelt werden. So gesehen beruht doch jeglicher Task-/Thread-Wechsel auf mindestens einer Unterbrechung.)
Ergänzung: Unterbrechungen sind natürlich nur für die Ereignissteuerung nötig. Wenn ein Task abgibt, kommt der nächste wartende selbstredend ohne Unterbrechung wieder an die Reihe. Mein Frage bezieht sich nur auf die Priorität 0, ob die eine Sonderstellung einnimmt.
df1as schrieb: > Ist denn Priorität 0 vom time-slicing ausgeschlossen und kann daher > nicht durch gleiche Priorität (0) unterbrochen/abgelöst werden? Afaik werden alle Threads mit gleicher Priorität im Round-Robin-Verfahren abgearbeitet. Mit CeSetThreadQuantum kann für jeden Thread festgelegt werden, wie viel Zeit er am Stück arbeiten darf. Interruptroutinen sind ebenfalls unterbrechbar (verschachtelte Interrupts).
Arc Net schrieb: > Afaik werden alle Threads mit gleicher Priorität im > Round-Robin-Verfahren abgearbeitet. Mit CeSetThreadQuantum kann für > jeden Thread festgelegt werden, wie viel Zeit er am Stück arbeiten darf. Korrekt. Standard ist ein Thread Quantum von 100ms. > Interruptroutinen sind ebenfalls unterbrechbar (verschachtelte > Interrupts). Das ist nur teilweise korrekt. Die Interrupt Service Routinen (ISRs) sind nicht unterbrechbar. Der Interrupt Service Thread (IST) des Treibers ist aber ein Thread wie jeder andere und kann unterbrochen werden. Zu beachten ist, dass der Interrupt gesperrt bleibt bis der IST mit InterruptDone() bestätigt. D.h. dass z.B. bei shared Interrupts (PCI) kein Interrupt auf der gleichen Int-Line kommen kann bis der IST abgearbeitet ist! http://msdn.microsoft.com/en-us/library/ms836807.aspx
Raphael Baum schrieb: > Das ist nur teilweise korrekt. Die Interrupt Service Routinen (ISRs) > sind nicht unterbrechbar. Teilweise nicht unterbrechbar (hatte das auch nicht mehr vollständig in Erinnerung) "A change to the Interrupt architecture that was introduced in Windows CE 3.0 was the ability to Nest Interrupts. At the point that the OAL ISR is entered, all higher priority interrupts have been enabled. The ISR may be preempted. Scenarios where timing within the ISR is critical may require interrupts to be disabled for that period of time." > http://msdn.microsoft.com/en-us/library/ms836807.aspx bzw. http://msdn.microsoft.com/en-us/library/aa448274.aspx
Arc Net schrieb: >> Das ist nur teilweise korrekt. Die Interrupt Service Routinen (ISRs) >> sind nicht unterbrechbar. > > Teilweise nicht unterbrechbar (hatte das auch nicht mehr vollständig in > Erinnerung) > "A change to the Interrupt architecture that was introduced in Windows > CE 3.0 was the ability to Nest Interrupts. At the point that the OAL ISR > is entered, all higher priority interrupts have been enabled. The ISR > may be preempted. Scenarios where timing within the ISR is critical may > require interrupts to be disabled for that period of time." > http://msdn.microsoft.com/en-us/library/ms836807.aspx Das ist prinzipiell richtig, aber in fast keinem BSPs realisiert. Oft ist das durch die Hardware - sprich den Interrupt Contoller - bedingt. In http://msdn.microsoft.com/en-us/library/ms836807.aspx wird z.B. der Interrupt Handler aus dem x86 BSP gezeigt (PeRPISR()). Ein neuer Interrupt kann hier erst wieder zuschlagen, wenn der EOI am ende der Routine auf dem PIC gemacht wird. Die ISR wird aber schon vorher in NKCallIntChain() aufgerufen. Bei allen mir bekannten BSPs für x86 aber auch fast allen ARM BSPs wird das so realisiert. Zu MIPS Systemen kann ich nichts sagen, da ist mir noch keines untergekommen...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.