Serielle Schnittstelle schnell(!!!) zum Senden bewegen.
-
Hallo,
ich möchte einem Gerät das über die serielle Schnittstelle angebunden ist, in sehr kurzen Zeitintervallen (100ms) ein Zeichen senden.
Das Senden an sich ist kein Problem.
Durch ein Hardwaretimer kann ich auch die Intervalle genau einhalten. Wenn ich dann jedesmal Windows bitte das Zeichen zu senden, dann tuts das auch.
Problem ist: nicht sofort.
Mit einem kleinen Gerät was ich zwischen dem PC und dem Empfänger klemme kann ich überwachen wann das Zeichen tatsächlich über die Leitung geht.
Und das passt leider nie mit meinen Intervallen überein. D.h. mal liegt ne Sekunde zwischen zwei Zeichen, mal 100 ms.
Ich brauchs aber genau.
Kennt einer vielleicht eine Möglichkeit Windows davon abzuhalten zwischen durch noch was anderes zu machen?
Oder gibts eine Bibliothek die sowas umsetzt.
Ich vermute mal an Windows vorbeikommen kann ich wohl nicht.Vielen Dank schonmal
Janet
-
Windows ist kein Echtzeitbetriebssystem; dafür bietet es dir eine recht hohe Abstraktionsebene der Hardware an.
Theoretisch könnte es die Zeichen auch mehrere Sekunden puffern und dann in einem Rutsch senden (vielleicht tut es das bei sogar).
Du musst also IMHO entweder auf ein anderes (echtzeitfähiges) Betriebssystem umsteigen oder deinem Gerät die Fähigkeit geben, die Daten zu puffern. 100ms-Intervalle kannst du unter Windows AFAIK niemals genau einhalten (wenn dann nur mit größten Verrenkungen und zig Nachteilen).
-
Nur so ne Idee, vielleicht kannst dus in Assembler ohne WinApi machen und damit das Betriebssystem umgehen. Als alternatives Betriebssystem fällt mir nur Linux ein. Eventuell könntest du dann mittels asm {} deinen Assembler Code nur zu senden in dein bestehendes Programm einbinden. (Weiß es aber nicht genau!!!!)
-
Man kann mit asm nicht das Betriebssystem umgehen! Dann wäre es ja ziemlich nutzlos.
Wie viel Verzögerung wäre denn vertretbar? Wenn du es wirklich so genau haben willst, wirst du wohl nicht um ein Echtzeitbetriebssystem herumkommen...
-
Ändert sich was, wenn der FiFo-Puffer bei der seriellen Schnittstelle abgeschaltet wird ?
-
@ Ringding:
Nur mal so OT warum sollte man das Betriebssystem mit asm nicht umgehen können?
-
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.