Port.dll & High Resolution Timer machen Probleme

[bwirmer]

Jepp, Windows und Co sind schlimm - entweder man muss auf QNX o.ä. umsteigen, oder ein bisschen Hardware einsetzen...

Das Problem ist übrigens gelöst. Zwar weiß ich immer noch nicht genau, warum - aber wenn man den Timer vor der Port.dll initialisiert, funktioniert das Programm - umgekehrt nicht.

[just4fun]

Auch kein schlechter Tipp!
Zur Zeit hänge ich aber am Parallelport, da ich dort so schöne viele Leitungen habe.
Ich muss mal schauen, wann ich mich an die "Verschnellerung" durch den Multimediatimer wage und schauen, was es effektiv bringt.
Wie gesagt: Es ist mir nicht so wichtig, ob ein Motorstepper-Impuls dann 1,5 oder 1 ms lang ist. Ist natürlich nicht so schön, dürfte aber für meine Zwecke wohl ausreichen.

Aber dennoch vielen Dank für die guten Tipps und die Anregungen!
Wird weiter in meinem Kopf arbeiten...

Ist ist n klasse Forum hier! Bin jedes mal wieder begeistert.
Hab nur leider viel zu wenig Zeit...

[Blackbird]

@bwirmer,

Linux, Unix, SunOS sind nicht besser - sind eben alles keine Echtzeit-OS.
pSOS+, VxWorks sind es aber. Alternativ kann man auch DOS (ja, echtes, altes DOS!) mit der Betriebssystem-Erweiterung DESQView 386 nehmen. Die ist (fast) echtzeitfähig und multitasking ist sie auch.

Blackbird

[bwirmer]

Linux, Unix, SunOS sind nicht besser

Das meinte ich mit Windows & CO

sind eben alles keine Echtzeit-OS.

QNX aber schon

http://www.openqnx.com

Achja, Windows CE scheint auch ein Echtzeit-OS zu sein

[Skilltronic]

Hallo

Ein PC besitzt für die zeitliche Steuerung einen PIT, einen programmierbaren Intervalltimer, der mit einem Takt von 1,193180 Mhz läuft und den man sowohl auslesen und damit Zeiten theoretisch bis auf unter 1µs genau messen, als auch selbst einstellen und damit die 55ms-Auflösung der übergeordneten Timer verbessern kann. Letzteres geht aber unter Windows nur eingeschränkt. Für exakte zeitliche Steuerung ist es sowieso das beste, man fährt seinen Rechner mit einer Startdiskette unter echtem DOS hoch.

Ichj habe so schon z.B. über den COM-Port und einem TSOP mittels eines QuickBasic-Programms Signale von einer IR-Fernbedienung eingelesen, deren Impulse deutlich unter 1ms lang waren.

Hier ein paar Links zum PIT:

http://www.franksteinberg.de/SOURCE/TIMING.TXT
http://www.sharpmz.org/mz-700/8253ovview.htm
http://ivs.cs.uni-magdeburg.de/bs/le...e3/timer.shtml

Gruss
Skilltronic

[Blackbird]

@Skilltronic,
absolut richtig.
Der "PIT" ist auch unter W95/98 noch erreichbar. Aber ab WinNT/2k/XP/ME nicht mehr. Nur mit einem eigenen Treiber. Oder man verwendet die Funktionen QueryPerformanceCounter(...) und QueryPerformanceFrequency(...) (funktionieren auch unter W95/98 ), die eben genau diesen Counter des 8253 auslesen. In den Chipssätzen der Mainbords gibt es den (Uralt-)IC 8253 nicht mehr. Aber seine Funktionalität ist aus Kompatibilitätsgründen in den Chipsätzen mit enthalten. Genauso wie die von 16550 und anderen.

Meine Antworten bezogen sich auch nur auf C/C++-Code für W32-Systeme, nicht auf Basic (für 16Bit-Systeme), weil der Zugriff auf Hardware-Addressen in W32-Systemen gesperrt ist. Deshalb auch mein Vorschlag, DOS zu nutzen. Dann hat man auch alle Vorteile der hardwarenahen Programmierung, die Du genannt hast.

@bwirmer,
WindowsCE ist kein Echtzeitsystem. Nur ein abgespecktes 32Bit-Windows, das aus genau diesem Grund recht schnell ist.

Hier einmal zum Verständnis das Hauptmerkmal eines Echtzeit-OS:
Jedes von außen eintreffende Ereignis (z.B.: an einem Port) muß nach einer durch die Programmierung festgelegten Zeit (abhängig vom Code und vom Maschinentakt) zu einer Reaktion an einem anderen Port in IMMER der gleichen Zeit führen, egal, was der Prozesser/Rechner gerade macht. Ob das Minuten oder Microsekunden sind, spielt dabei gar keine Rolle - es muß nur immer die gleiche (vorausberechnete) Zeit sein, egal, ob der Rechner gerade die Datenbank abgleicht, das Netzwerk durchsucht, im IDLE-Modus rumrennt oder sonstwas macht.

Naja, egal wie, für unsere (Amateuer-)Anwendungen gibt es eine Menge Möglichkeiten, mit vorhandenen PCs und OS quasi Echtzeitanwendungen, auch für kurze Reaktionszeiten zu "bauen". Das hat der Thread hier schön zusammengefaßt.

Blackbird

[bwirmer]

@bwirmer,
WindowsCE ist kein Echtzeitsystem. Nur ein abgespecktes 32Bit-Windows, das aus genau diesem Grund recht schnell ist.

Stimmt, bin meinen aufgeschnappten Informationen nocheinmal genau nachgegangen. Allerdings ist CE schon ziemlich nah dran (http://www.windowsfordevices.com/art...761039286.html) und mit dem normalen Windows nicht unbedingt zu vergleichen - das trifft wohl eher für XP Pocket zu.

Das Prozesse bei einem Echtzeitsystem jederzeit zu 100% deterministisch sein müssen, ist klar - und Windows ist da strukturell einfach anders aufgebaut.