Hallo,

ich habe ein Problem: Und zwar soll ich einen Takt an der Seriellen Schnittstelle erzeugen. Und zwar an den Pins RTS und DTR. Dass heisst da geht nichts über die Baudrate (oder??, wenn ja wäre es gelöst). Das Problem ist jetzt einfach die Zeit, und zwar soll ich Periodendauern zwischen 0.5ms und 1ms erstellen.
Meine Frage wie bekomme ich das hin. Also, so das es auch auf jeden Rechner so ist, also nicht einfach ne for-schleife so das es zufällig grade bei mir passt.

Meine bisherigen gedanken:

1. erstmal mit Thread.Sleep(new Timspan(500000)); //für 0.5 ms // da lag ich um den faktor 100 daneben
2. dann habe ich aktives warten probiert:
   DateTime start = DateTime.Now;
   //ein tick entspricht 100 Nanosekunden
   while(((DateTime.Now - start).Ticks/10) < microSeconds)
   ;
   Das hat die Periodendauer ungefähr halbiert (zu oben)
   
3. Ein Echtzeit-OS muss her!? Windows CE? Ein eigenes (habe ich mal or ner Weile angefangen, wäre echtzeitfähig da es nichts macht außer das

Die ersten beiden Lösugen waren nur mal so Versuche um eben abzuchecken wieviel fehlt. Dabei war mir klar das es nicht klappt.
Achso und der Thread in dem das ist hat schon die höchste Priorität.
Das mit WinCE wäre eine Idee, aber auch net so das wahre.
Ds mit dem eigenen OS. Ist nur so daher gesponnen, da derjenige für den das ist wohl kaum ein OS installieren möchte was ncihts kann außer ein bissl was senden.

Gibt es noch eine andere Möglichkeit als ein anderes OS, vlt. mit einem Treiber???

mfg

wie wäre ein Timer?

Das habe ich in der Zwischenzeit auch probiert.
Allerdings nicht mit dem normalen Timer sondern mit dem HighPerfomanceCouner
Ich muss noch messen, deswegen kann ich noch kein Ergebniss sagen.

Der normale Timer ist (angeblich) zu ungenau, wegen der Auflösung.

Es scheint zu funktionieren.
Mal abwarten wie es sich in den nächsten Tests schlägt

mfg MasterOfDesaster

Falls der PC nur für diese Aufgabe zuständig ist, kann man doch auch Echtzeit bei der CPU-Priorität im Taskmanager einstellen, oder?

Ich bin mal davon ausgegangen, das das ThreadPriority.Highest entspricht.
Von daher habe ich das schon.
Aber echte Echtzeit wird man damit definitiv nicht erreichen

Naja ne gewissen Anfälligkeit ist auf nem Multi Tasking Betriebssystem nicht auszuschalten. Wenns blöd läuft und der PC entsprechend ausgelastet ist.

Noch etwas bezüglich QueryPerformaceCounter:
Beware of QueryPerformanceCounter()

Zitat

Original von Traumzauberbaum Naja ne gewissen Anfälligkeit ist auf nem Multi Tasking Betriebssystem nicht auszuschalten. Wenns blöd läuft und der PC entsprechend ausgelastet ist.

Nicht unbedingt. Das nicht alles superschnell, und innerhalb einer gewissen Zeit fertig ist ist klar. Aber die Dinge die eilig sind müssen halt rechtzeitig fertig sein. Bei entsprechendem Scheduling, prioritätsgesteuert und unterbrechend z.B., klappt es, zumindest mit dem höherprioren Threads. Bei Windows hast du meine volle Zustimmung, acuh bei CE. Linux kann glaube ich auch recht gut echtzeitfähig gemacht werden.

Das geht ja schon rein theoretisch kaum.

Stell dir vor du hast ein Programm, dass alle 1 ms drankommen soll. Das Programm muss soll alle 1 ms nen Takt geben, d.h. es muss auch innerhalb der 1 ms komplett fertig werden. Die benötigte Rechenzeit für einen Takt sei t. Lass das Programm dann (1 ms/t) + 1 mal starten, und es ist unmöglich, das alle innerhalb von 1 ms einen Takt geben.

@marsgk: Der Artikel stimmt mich ja nicht gerade positiv
Naja es scheint erstmal zu funktionieren, wobe ich schon etwas "schummeln" muss.
Ich muss schon ein paar µs weniger warten als der Takt minmal breit sein sollte. Aber das hängt evtl. auch mit Codelaufzeiten zusammen. irgendwie muss aus meinem port.DtrEnable = true; ja auch noch ne spannung erzeugt werden.

Hallo MasterOfDesaster,

hast Du inzwischen eine halbwegs brauchbare Lösung gefunden und könntest sie hier mal posten?
Ich sitze nämlich gerade vor ähnlichem Problem, dass ich einen genaueren Timer benötige als den Standardtimer (das ja nur auf ca 55ms genau ist).
Ich habs jetzt auch mit nem eigenen Timer Thread und dann mit Sleep versucht, bin aber auch nur auf ca 0,5ms genau. Das sind 8ms Gesamtzeit schon eine ganze Menge ;-) Und läuft ja dann schnell auch auseinander wenn die Gegenstelle (serielle Verbindung) alle 8ms etwas erwartet.

Wenn noch jemand anders eine Idee hat, dann immer her damit

MfG
Fluffi

Es gibt überhaupt keine Möglichkeit Windows-Anwendungen (!) zu irgendeiner Art von Genauigkeit zu verpflichten. Weder 0,5 ms noch 2 Sec. Zugesicherte Genauigkeiten jenseits des Kernels erfordern immer ein Echtzeit-BS bzw. eine Echtzeiterweiterung .

Anders sieht das bei Kernel-Code (Treiber) aus.

Hier z.B. ein Kernel-Tool für "Serielle DV in Echtzeit":

http://www.firmenpresse.de/artikel1801.html

Wenn man also selbst eine zuverlässige, zeitgesteuerte Kommunikation - wie in diesem Fall - realisieren möchte, kommt man um einen Treiber nicht drum herum, und die kann man mit .NET nicht schreiben....

Das Problem an dem angepriesenen Produkt ist, dass dazu auch Hardware benötigt wird (soweit ich das überflogen habe und soweit ich schon dutzende andere Produkte gesehen habe) und außerdem auch nicht wenig kostet :-(. Und damit schon mal völlig unpraktikabel für Software, die einfach so auf verschiedenen Rechnern laufen soll.
Und Bei den Preisen kann man sich auch fix selber was bauen. Ein einfacher Prozessor, der in gewissen Zeitabständen ein Signal an den Seriellen Port schickt. Und schon hat man Eventgetriggert seinen Takt, den man nach belieben nutzen kann und dann auch auf größere Abstände multiplizieren. Aber das ist wie gesagt bei dem Problem hier nicht der Sinn :-/
So ähnlich habe ich es schon mal bei einem anderen Produkt gemacht. Da hatte ich durch das angesprochene Produkt selbst eine Art externe clock.

Ich muss mit den Mitteln die ich habe (also nur Software) eine möglichst hohe Genauigkeit erreichen. Das das dann auch nicht zu 100% verpflichtend fürs System ist, ist mir klar. Aber es wäre gut möglichst nahe heranzukommen ;-)

Da halte ich den Ansatz mit dem HighResTimer für garnicht mal schlecht. Deshalb wollte ich mal wissen was draus geworden ist und wie die Erfahrungen jetzt damit sind..

MfG
Fluffi

Zitat

Original von Huffifluffi Das Problem an dem angepriesenen Produkt ist, dass dazu auch Hardware benötigt wird

Da musst du was Falsches geklickt haben. Hier nochmal:

http://www.kithara.de/ge/prod.php?sub=kser

Zitat

Aber es wäre gut möglichst nahe heranzukommen ;-)

Es gibt nur gut genug oder nicht..

Es ist nicht eine Frage des Timers (oder welcher davon), es ist eine Frage des Thread-Schedulings. Und wenn das System ordentlich mit Interrupts zu tun hat, dann geht die Latenz nach oben.