Es geht darum, Hardware über ein abgewandeltes I²C Protokoll zu testen.
Der Bus soll dabei über die parallele Schnittstelle simuliert werden.

Da im vorliegenden Fall die Genauigkeit im Mikrosekundenbereich liegen muss
(es soll getestet werden, ob sich die angeschlossene Hardware an die
Spezifikation hält und die schreibt z. B. vor T1 = 50..1000 µsec vor),
scheidet eine Anwendung im Usermode definitiv aus.

Das ganze sollte ohne Zusatzhardware unter WinXP laufen, da die Software an mehreren
Rechnern zum Einsatz kommen soll und Platinen lassen sich so schlecht
mittels Copy + Paste verteilen...

Hab leider noch nie einen Treiber geschrieben.
Aber wenn ich mir das hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-178708-and-highlight-is-driver.html
bzw. auch MSDN durchles,
dann müsste sich sowas doch in einer Interrupt Routine (=höchste Priorität) machen lassen.
Man müsste halt in Kauf nehmen, dass der Rechner auf nichts anderes reagiert, solange der Test läuft.

Zusammenfassung:
Ist es möglich, einen Pin vom Druckerport für z. B. 70 Mikrosekunden auf 'high' zu setzen.

Thx
Martin

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Das heisst dass Du den IRQ Controller so programmieren musst das er nur noch das LPT-IRQ durchlässt - wenn die CPU nämlich gerade ein INT(R) abarbeitet sind alle anderen INTS blockiert ausse #2 ( = NMI ) und dann wärs schon zu langsam.

{EDIT] Müll :
ABER : Wie will Du das die Taktung über LPT überhaupt realisieren? Vielleicht sthe ich ja grad im Feld aber die hat doch viel höhrere Latenzzeiten, oder?[/EDIT]

Grüsse

*this

Was die LPT angeht:
Es existiert bereits ein DOS basiertes Tool, welches funktioniert.
Ich muss zugeben, dass ich noch nicht nachgemessen hab, ob das wirklich auf
die Mikrosekunde genau geht, aber es läuft zumindest ausreichend genau.
Drum geh ich davon aus, dass die Geschwindigkeit der Schnittstelle das geringste
Problem darstellt.

Dann läßt sich also sagen, dass es mit einem Kerneltreiber funktioniert,
unter der Voraussetzung, dass die Schnittstelle mitspielt?

Werd mich dann mal in die Treibergeschichte einlesen und vielleicht um
die eine oder andere Erkenntnis reicher werden.

Danke.

Dann läßt sich also sagen, dass es mit einem Kerneltreiber funktioniert,
unter der Voraussetzung, dass die Schnittstelle mitspielt?

Nein (siehe oben).
EDIT:

dann müsste sich sowas doch in einer Interrupt Routine (=höchste Priorität) machen lassen.

Du brauchst keinen ISR, du brauchst wenn dann KeRaiseIrql(). Wenn du damit auf CLOCK_LEVEL oder sowas brutales hochgehst ist das so ziemlich das Beste was du mit Windows hinbekommen wirst.
Aber selbst dann kannst du noch von diversen Dingen für (relativ) kurze Zeit unterbrochen werden.
Wenn dann ein Interrupt getriggert wird, während dein Thread mit z.B. CLOCK_LEVEL läuft, dann wird der zuständige ISR zwar nicht ausgeführt, aber es kann sein dass der Interrupt Handler von Windows selbst noch angesprungen wird, und erst dort dann die Interrupts gesperrt, damit dein Thread weitermachen kann. Das erfordert ein paar Port Zugriffe, und die sind oft ordentlich langsam.

3GHz == 3 Milliarden
=> Die CPU müsste doch im Nanosekundenbereich ihre Befehle abarbeiten?

Aeehh, ja, kleiner Rechenfehler von mir...
Vergiss also am besten mein Geschwätz von gestern.

Grüsse

*this

P.S.: Wer lacht da? Einstein hat sich afaik mal um über 60 Grössenordnungen verschätzt - bei mir waren's nur drei!

anonymus schrieb:

3GHz == 3 Milliarden
=> Die CPU müsste doch im Nanosekundenbereich ihre Befehle abarbeiten?

Aeehh, ja, kleiner Rechenfehler von mir...
Vergiss also am besten mein Geschwätz von gestern.

Grüsse

*this

P.S.: Wer lacht da? Einstein hat sich afaik mal um über 60 Grössenordnungen verschätzt - bei mir waren's nur drei!

Sind denn 3GHz nicht 3 Milliarden Takte pro sekunde?
kilo = tausend.
mega = millionen
giga = milliarden

1 Nanosekunde = 1000 Picosekunden = 10^-9 Sekunden
also 3 Takte pro Nanosekunde. Oder verrechne ich mich auch?

oder etwa nicht?

Windows (egal welche Version) ist ohne eigene "Extensions" nicht Echtzeitfähig. Mit einem Treiber kann man zwar die durchschnittlichen Latenzzeiten deutlich verkürzen, ändert aber Grundsätzlich nix.
Mikrosekundenbereich kannst du IMHO vergessen. Auf ~~1ms ja, vielleicht, mit Bauchweh, aber auch nur wenn nix wichtiges davon abhängt.
Mit selektierter Hardware und selektierten Treibern sollte deutlich weniger als ~~1ms möglich sein, ob man in den Microsekundenbereich kommt ... weiss nicht ... mich würde es wundern. Kritisch darf die Anwendung aber auch mit selektierter Hardware nicht sein.
Nicht selektierte PC Hardware ist - egal welches OS - nicht Echtzeitfähig, da es immer noch das BIOS gibt, und dieses oft den SMI (den du softwaremässig nicht maskieren kannst, zumindest gibt es keinen Standard dafür) verwendet um diverse Hardware Fehler auszubügeln.

Dann läßt sich also sagen, dass es mit einem Kerneltreiber funktioniert,
unter der Voraussetzung, dass die Schnittstelle mitspielt?

Nein (siehe oben).
EDIT:

dann müsste sich sowas doch in einer Interrupt Routine (=höchste Priorität) machen lassen.

Du brauchst keinen ISR, du brauchst wenn dann KeRaiseIrql(). Wenn du damit auf CLOCK_LEVEL oder sowas brutales hochgehst ist das so ziemlich das Beste was du mit Windows hinbekommen wirst.
Aber selbst dann kannst du noch von diversen Dingen für (relativ) kurze Zeit unterbrochen werden.
Wenn dann ein Interrupt getriggert wird, während dein Thread mit z.B. CLOCK_LEVEL läuft, dann wird der zuständige ISR zwar nicht ausgeführt, aber es kann sein dass der Interrupt Handler von Windows selbst noch angesprungen wird, und erst dort dann die Interrupts gesperrt, damit dein Thread weitermachen kann. Das erfordert ein paar Port Zugriffe, und die sind oft ordentlich langsam.

Das macht natürlich wenig Hoffnung.
Wenn da nicht weniger als eine Millisekunde drin ist.
5-6 ms Reaktionszeit kriegt man ja schon im Usermode hin
(gut, nicht garantiert, aber gemessen hab ich nie mehr...)

Von einem Treiber hätt ich mir doch einiges mehr erwartet.

Sorry, was ist "selektierte Hardware"? Google bringt mich ned wirklich weiter.

Najo, jetzt geht's erstmal a paar Tage nach Italien.
Und dann mal schaun, wie's weitergeht.
Aber schaut dann wohl ned so gut aus...

mfg
Martin

schirrmie

gerade neue News bei tecchanel, da musste ich gleich hieran denken
http://www.tecchannel.de/news/themen/entwicklung/470000/index.html

Hab mich da mal a bissl eingelesen und das schaut ganz vernünftig aus.

Allerdings macht das von Hustbaer vorgeschlagene "KeRaiseIrql()"
auch eine ganz gute Figur.

Da werd ich jetzt einfach mal viel lesen müssen.
Anhaltspunkte hab ich jetzt zumindest schon mal.

Thx @all.

WIndows XP ist grundsätzlich nicht Echtzeitfähig, allerdings kann mit einigen Tricks schon sehr zeitkritische Anwendungen realisieren. Dein Problem sollte sich mit einem Kernelmodetreiber eigentlich locker realisieren lassen, sofern die Hardware mitspielt. Als beispiel kann man im Kernelmode Timer Initialisieren (XP), welche in 100 ns Intervall angegeben werden.
Millisekunden sollten da ebenso möglich sein.
Allerding ist die einarbeitung in dieses Thema schon recht aufwendig und die Dokomentatinen recht rar, ausser das Windows DDK.

Vielmehr ist es so, dass es (fast) egal ist (ca. 10 ms dürfen vergehen, und die sollte man sogar im Usermode hingekommen, zumindest warens über RS232 mal ~6ms) wann eine Funktion abgearbeitet wird,
es muss nur sichergestellt sein, dass sie, wenn sie mal arbeitet, nicht mehr
unterbrochen wird.
Und das müsste mit dem "KeRaiseIrql()" doch möglich sein, mit allen Einschränkungen die sich draus ergeben (hab ein Dokument gefunden, wo drin steht,
dass man z. B. drauf achten muss, dass man keinen Speicher verwendet, der
ausgelagert werden kann, falls das Level höher als XX gewählt wird).

Was ich dann allerdings brauch ist eine Counter, den man abfragen kann, wieviel Zeit vergangen ist, so dass man in einer Schleife eine bestimmte Zeit warten kann.

Der Time Stamp Counter wäre zwar so ein Kandidat, aber was ich so gelesen hab, ist der nicht allzu verlässlich (grade in Systemen mit mehr als einem Kern weil dann zwei Counter laufen, die nicht zwingend gleiche Werte haben, auch Hyperthreading soll da schon Probleme machen... oder falls die Taktfrequenz von der Last abhängt)
Auf der anderen Seite, wenn der Code nicht unterbrochen wird, dann müsste doch sichergestellt sein, dass er nur auf einem Kern läuft und somit müsste der TSC trotzdem OK sein.

APIC timer wäre evtl. eine Alternative, aber da hab ich noch nix gefunden, wie man da rankommt...

APIC timer wäre evtl. eine Alternative, aber da hab ich noch nix gefunden, wie man da rankommt...

http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
http://rtg.informatik.tu-chemnitz.de/docs/vortraege/def-sa-wiet.pdf
http://plan9.bell-labs.com/sources/plan9/sys/src/9/pc/apic.c

Vonwegen Timer ... warten kannst du mit KeStallExecutionProcessor (busy wait). Längere Zeiten kann man mit KeDelayExecutionThread warten, allerdings nur auf PASSIVE_LEVEL, und nur mit sehr grober Auflösung.

Ansonsten gibt es noch KeQueryInterruptTime (was wahrscheinlich zu ungenau sein wird) und KeQueryPerformanceCounter. Ob KeQueryPerformanceCounter für dich funktionieren wird kann ich nicht sagen, ich hab' mit dem performance counter auf jeden Fall schlechte Erfahrungen gemacht, allerdings war das im Usermode.

Die Signalzeiten werden auf ca. 2µsec genau eingehalten.
=> gut so.

Falls die Reaktionszeit interessiert:
Wenn sich an einem Pin der parallelen Schnittstelle ein Wert ändert,
läßt sich innerhalb von 3µsec ein anderer Pin ändern.
=> auch gut.

Übrigens waren 3µsec auch die minimalen Signalzeiten, weniger war nicht möglich.

Dazu Interrupts mittels _asm{cli} deaktiviert, im Anschluss mit _asm{sti} wieder aktiviert.
Ab IRQL 28 auch brauchbare Ergebnisse in ähnlicher Größenordnung,
alles unter 28 ist grauenhaft

mfg
Martin

Die ganze Diskussion hier ist Sinnlos...

Echtzeit heisst *nicht* so schnell wie möglich, sondern es heisst "deterministisch"!!!!

Und das ist nun mal unter Windows (NT und höher) nicht gegeben!!!!

Wenn irgendjemand einen Treiber schreibt der (aus versehen) mal 10 Sekunden braucht (innerhalb CLI), dann haben die anderen Treiber halt Pech gehabt!

Windows (NT/W2k/XP) ist *nicht* Echtezeitfähig... somit kann es auch keine Treiber geben die Echtzeitfähig sind!!!

kann es wohl. windows ist nicht allmächtig.

Jochen Kalmbach schrieb:

!!!!
!!!!

http://storage9.myopera.com/AlchemicalSecrets/albums/290842/omg1.png

Jochen Kalmbach schrieb:

Windows (NT/W2k/XP) ist *nicht* Echtezeitfähig... somit kann es auch keine Treiber geben die Echtzeitfähig sind!!!

kann es wohl.

Ja, träum weiter, Kind. Dass hier ein WINDOWS Treiber gemeint war sollte wohl klar sein.

Dass hier ein WINDOWS Treiber gemeint war sollte wohl klar sein.

du weisst nicht, das man mit code, der im ring0 ausgeführt wird, nahezu alles anstellen kann?

du weisst nicht, das man mit code, der im ring0 ausgeführt wird, nahezu alles anstellen kann?

Und genau das ist das Problem!!! Ich glaube Du hast mein Post nicht richtig gelesen...

Wenn *Du* alles machen kannst, dann können *andere* auch alles machen und dann ist Dein determinismus wieder dahin!

hustbaer schrieb:

Dass hier ein WINDOWS Treiber gemeint war sollte wohl klar sein.

du weisst nicht, das man mit code, der im ring0 ausgeführt wird, nahezu alles anstellen kann?

1. Du kannst selbst in Ring 0 den SMI nicht loswerden, und das war's dann schonmal mit echtzeitfähig.

2. Was Windows angeht: klar kannst du alle Interrupt abdrehen und lala und lalubb, bloss andere können das auch.
   Dass ein OS echtzeitfähig ist heisst NICHT dass man es "anhalten" kann, damit man dann diverse blöde polling Schleifen laufen lassen kann während alles andere steht um eben "echtzeit" zu bekommen.
   Dass ein OS echtzeitfähig ist heisse dass man eben NICHT das OS anhalten oder sonstwie stören muss und TROTZDEM garantiert bekommt dass z.B. Interrupts mit einer max. Latenz aufgerufen werden. Und genau das geht unter Windows NICHT.

Windows
ist
> NICHT <
echtzeitfähig
!