Kann man irgendwie beinflussen, in welchem zeitlichen Abstand einzelne Bytes auf die Leitung gelegt werden?

für jedes Byte writeFile() aufrufen und im Anschluss warten hab ich schon versucht, aber ist zu ungenau...

Weder mit "Sleep()" noch busy waiting mittels Schleife (pseudo Code)

start = currentTime();
do
{
   // Nothing
}while(currentTime() - start < 3)

brauch Abstände zwischen 3 und 8 Millisekunden.
Sowohl bei Sleep als auch bei der Schleife macht Windows da aber nicht mit... (16 ms und mehr sind keine Seltenheit)

Aber irgendwie müsste doch sowas möglich sein, weil es lässt sich auch innerhalb
von 5 ms auf eine Anfrage antworten...

thx
Martin

vielleicht klappt das, aber sicher ist es nicht. windows ist nun mal kein RTOS und macht eigentlich immer was es will (und nicht was der user will)

Benutz dafür eine fertige Bibliothen man. Wieso musst du dir das Leben so unnötig schwer machen. Sleep(1) wirds auch gerade bringen, *lol*

Jochen

danke.

Schlafen kann man leider nur in 16ms Schritten (Sleep(x) wacht nach >= 16ms auf wenn x < 16).

najo, so täts funktionieren: (Sendeabstand zwischen 4 und 7 ms)

for (unsigned long i = 0; i <  NumberBytesToWrite; i++)
	{
		TransmitCommChar(m_comHandle, Buffer[i]); 
		long long x = 0;

		while (x++ < 1000000);

	}

Aber vermutlich wird das auf jedem Rechner anders ausschaun
(da fallen mir auch noch die alten DOS Spiele ein, die auf neueren Rechnern viel zu schnell gelaufen sind...)

Ausserdem optimiert der Compiler die Schleife im Releasebuild weg

Da ich ansonsten auch grad keine Idee mehr hab, hoff ich mal,
dass es ausser mir keiner merkt, wenn der Abstand kleiner ist
(Soweit funktioniert alles, aber es entspricht halt nicht den Vorgaben...)

thx
Martin

Schlafen kann man leider nur in 16ms Schritten (Sleep(x) wacht nach >= 16ms auf wenn x < 16).

dann versuchs mal damit: http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Thread/NtDelayExecution.html
die schlafenszeit kannste damit in µs angeben...

btw: oder du bastelst dir 'ne realtime extension in den kernel. gibt's auch schon, aber leider nicht free

net schrieb:

besser wär's du änderst den anderen kommunikationspartner so dass der nicht auf diese 4...8ms angewiesen ist. alles andere ist sowieso flickwerk.

Geb ich dir vollkommen recht.
Aber leider ist mir die Hardware und damit das Protokoll vorgegeben.
Da kann ich nix dran ändern

thx

NtDelayExecution würde ich nicht verwenden, da dies ein Busy-Wait ist...

nö, Sleep und SleepEx verwenden es auch und letztendlich landen alle da:
http://www.osronline.com/DDKx/kmarch/k105_7epe.htm

The expiration time is computed and the current thread is put in a wait state. When the specified interval has passed, the thread exits the wait state and is put in the ready state, becoming eligible for execution.

Dann hab ich es mit einer anderen Funktion verwechselt...

wohl mit irgendwelchen spinlock sachen.

Jochen Kalmbach schrieb:

IMHO macht es aber dann 0 Sinn, diese Funktion zu verwenden... dann kann man ja gleich Sleep verwenden

naja, man kann die wartezeit in vielfachen von mikrosekunden angeben. ob das was hilft bei unserem geliebten, nicht-echtzeitfähigen windoofs ist natürlich 'ne andere frage aber ausprobieren kann man's ja mal...

Blackbird

Das Ende des Datensendens nach WriteFile kann man mit WAIT_OBJECT_0 von WaitForMultipleObjects (mit einem overlapped event) erfahren.

Nein, kann man nicht. Es gibt keine sinnvolle möglichkeit zu erfahren, wann die Daten die serielle Schnittstelle verlassen hat. Das was Du hier machen willst, würde Dir nur mitteilen, wann die Daten im seriellen Treiber angekommen sind.
Schau Dir einfach im DDK den seriellen Treiber an (welcher nahezu 1-zu-1 im OS so vorhanden ist) und dann wirst Du dies sehen.
Siehe auch:
http://groups.google.de/group/microsoft.public.vc.language/browse_thread/thread/5fbbe539ea89ad1d/68fd9660345ade94
http://groups.google.de/group/microsoft.public.de.vc/browse_thread/thread/5a3602ae1c7251ea/937474a8b5519916

NtDelayExecution():

welchen Header muss man dafür #includen?

timeBeginPeriod():

Die ersten 3 - 4 Byte haben einen Abstand zwischen 1 und >10 ms,
alle nachfolgenden purzeln alle 3 - 4 ms auf die Leitung.

timeBeginPeriod(1);

	for (unsigned long i = 0; i <  NumberBytesToWrite; i++) 
	{ 
		TransmitCommChar(m_comHandle, Buffer[i]); 			
		Sleep(3);
	} 

timeEndPeriod(1);

Dann kann man wohl nix machen.

Auf jeden Fall Danke

*Blackbird* schrieb:

Das Ende des Datensendens nach WriteFile kann man mit WAIT_OBJECT_0 von WaitForMultipleObjects (mit einem overlapped event) erfahren.

Nein, kann man nicht. Es gibt keine sinnvolle möglichkeit zu erfahren, wann die Daten die serielle Schnittstelle verlassen hat. Das was Du hier machen willst, würde Dir nur mitteilen, wann die Daten im seriellen Treiber angekommen sind.

Hast recht, der Treiber erzeugt einen Interrupt/Event, der zu WAIT_OBJECT_0 fuehrt. Ist nur die Frage, wann? Beim Uebernehmen der Daten oder nach dem Laden des letzten Bytes in die Register der UART?

Blackbird
PS.: Mit etwas Hardware dran geht es - exakte Abstaende zwischen den Bytes hinzubekommen. Aber das war ja nicht die Frage.

So, habs jetzt mal ausprobiert:
NtDelayExecution():

welchen Header muss man dafür #includen?

mindestens diesen: http://void.ru/files/Ntexapi.h
und man braucht die 'ntdll.lib'

ganz ohne mickeysofts hilfe gehts aber auch. hier eine kleine demo:

#include "stdio.h"
#include "windows.h"

typedef DWORD (__stdcall *NTDE) (BOOL, LARGE_INTEGER*);

void main (void)
{
   NTDE NtDelayExecution;
   LARGE_INTEGER i;
   DWORD result;

   NtDelayExecution = (NTDE)GetProcAddress (GetModuleHandle("ntdll.dll"), "NtDelayExecution");

   // test: delay for 15 seconds
   i.LowPart = -15 * 10000000;
   i.HighPart = -1;
   printf ("waiting....");
   result = NtDelayExecution (FALSE, &i);
   printf ("%08lx", result);   
}

Hast recht, der Treiber erzeugt einen Interrupt/Event, der zu WAIT_OBJECT_0 fuehrt. Ist nur die Frage, wann? Beim Uebernehmen der Daten oder nach dem Laden des letzten Bytes in die Register der UART?

Hab ich doch geschrieben... wenn die Daten beim Treiber sind... hat mit der Hardware nix zu tun!