Serielle Schnittstelle schnell(!!!) zum Senden bewegen.
-
Was wäre denn das für ein OS, wenn Benutzerprozesse erst recht wieder machen könnten, was sie wollen? Die einzige Möglichkeit, ein OS zu umgehen, ist, einen Kerneltreiber dafür zu schreiben und diesen zu laden. Und da muss keine einzige Zeile Assembler drin vorkommen.
-
In Asm kann ich doch ohne weiteres dem Prozessor befehle erteilen, daraus folgt das der HAL nahe 0 ist. Wenn ich jetzt dem Prozessor sage er soll ohne ende idlen dann tut der das auch. Auf Grafikkarten kann ich mir sogar ohne ASM exklusiven Zugriff holen. (DirectX ...) oder sehe ich da was falsch?
-
Wenn du irgendwas tust, was die Funktionsweise des OS beeinträchtigen würde, dann wird von der CPU eine Exception ausgelöst und der böse Prozess vom OS getötet, so einfach ist das.
-
Auch mit einem Kerneltreiber kannst du keine Echtzeit hinbekommen.
-
Das habe ich auch nicht behauptet.
Allerdings würde ich schon meinen, dass man wahrscheinlich schnell genug sein kann, dass es auf der (nun nicht gerade rasanten) RS-232 nicht wirklich ins Gewicht fällt.
-
@Rinding ich könnte aber meinerseits einfach das OS vorher umbringen (vielleicht geht das bei WinXp nicht mehr aber zu Zeiten von Win95- 98 ging das sicher...)
-
<janet> schrieb:
D.h. mal liegt ne Sekunde zwischen zwei Zeichen, mal 100 ms.
Ich brauchs aber genau.wenn eine volle sekunde verzögerung zu messen ist dann läuft da grundlegend was faul. ansonsten...probiers mal damit: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/transmitcommchar.asp
-
Es gibt ein (etwas umständliches) Verfahren, mit der man Mikrosekunden-genaue Abläufe über die Serielle Schnittstelle unter Windows erzeugen kann. Zwei Einschränkungen gibt es aber:
- Die Auflösung ist zwar sehr genau, aber nicht beliebig wählbar (nur in Stufen)
- "Echtzeit" ist nicht gegeben, weil eine Reaktion des Users (oder Threads) nicht in einer festen, vorher bestimmbaren Zeit erfolgt.Wenn der Buffer der Serielle Schnittstelle groß genug ist und man dafür sorgt, das er immer gefüllt ist, dann werden die einzelnen Zeichen im exakten Takt der Baudrate versendet. Man muß "nur" die Zeichen herausfischen (lassen) oder abzählen, die eben alle 100 ms erscheinen. Mit Hardware oder Software im Empfänger oder wie auch immer.
Blackbird
-
Wow, erstmal vielen dank für die große anteilnahme.
geeky schrieb:
Ändert sich was, wenn der FiFo-Puffer bei der seriellen Schnittstelle abgeschaltet wird ?
Nein. Theoretisch müsste er jedes Zeichen sobalds an der Schnittstelle ankommt losschicken.
Zwischen dem Treiber (CommDrv/lib - nutzt Winapi-treiber) und der Schnittstelle scheint wohl noch ein langer Weg durch OS zu liegen. Da hengt es.net schrieb:
wenn eine volle sekunde verzögerung zu messen ist dann läuft da grundlegend was faul. ansonsten...probiers mal damit: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/transmitcommchar.asp
So was ähnliches schon probiert. Ändert nix.
Meine Zeitintervalle erhalte ich durch einen HW-Timer, der wiederum einen Interrupt ausslöst. Der Aufruf der Interrupt-callback-Funktion verlief bisher asynchron.
Ich bin dabei das in Synchron zu ändern (dann läufts im Kontext des Interruptauslösers und ich sollte nicht mehr solche verzögerungen haben)
Leider kann ich dann weder globale Variablen noch WinAPI Funktionen benutzten.
Also begebe ich mich jetzt auf die Suche nach einer Möglichkeit dem CommDrv die WinApi abzugewöhnen, oder eben nach einer anderen Bibliothek.Ich glaube fast nicht das ich damit viel zeit gewinne, denn letztenendes habt ihr recht und ich bräuchte ein Echtzeitbetriebsystem.
Wenn ich ein Ergebnis habe lass ich es euch wissen.
Danke
-
Alles gar nicht so einfach.
Kennt jemand eine Bibliothek o.ä. mit der man auf eine serielle Schnittstelle ohne verwendung der Windows-Standarttreiber zugreifen kann?
Es gibt Comm-Drv/VxD, leider ist es mir nicht möglich davon eine Shareware oder ein Trial aufzuspüren. Das würde ja für den Anfang reichen.
-
wenn ich mich nicht irre ist im win-ddk der comport-treiber als sourcecode dabei. den könnteste manipulieren oder austauschen und so direkt auf den uart zugreifen
-
Ein VXD nützt dir auch nix, es sei denn, du hast W9x - voller Abscheu wende ich mein Gesicht ab...
-
Ringding schrieb:
Ein VXD nützt dir auch nix, es sei denn, du hast W9x - voller Abscheu wende ich mein Gesicht ab...
stimmt.
Aber gott sei dank gibt es noch commDrv/Nt -> ist das gleiche wie VxD nur eben auch für Win2k.
Da das erstmal gekauft sein will, kann ich noch nicht mehr zum lösen meines eigentlichen Problems sagen.
Nächste Woche gibts dann mehr.Vielen Dank nochmal an alle.
-
Also,
mit CommDrv/NT funktionierts.
Man muss direkt die Treiber der Schnittstelle austauschen und schon kanns losgehen.
Ich braucht nur die Initialisierung ändern, der Rest vom Code konnte gleichbleiben, da sich CommDrv/NT unter CommDrv/Lib schiebt.Vielen Dank nochmal an alle.