4. rs232: Zeitabstand zwischen ausgehenden Bytes

rs232: Zeitabstand zwischen ausgehenden Bytes

  • N

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

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

    0
  • A

    NtDelayExecution() und timeBeginPeriod() hören sich interessant an.
    Werd ich morgen gleich mal ausprobieren.

    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

    0
  • J

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

    0
  • N

    Jochen Kalmbach schrieb:

    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.

    0
  • J

    Dann hab ich es mit einer anderen Funktion verwechselt... IMHO macht es aber dann 0 Sinn, diese Funktion zu verwenden... dann kann man ja gleich Sleep verwenden

    0
  • N

    Jochen Kalmbach schrieb:

    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...

    0
  • ?

    Die Idee mit dem Warten, wie auch immer realisiert, hat einen kleinen Denkfehler:
    Wenn Daten per Funktion "WriteFile(...)" den Treibern uebergeben wurden (also die Funktion abgearbeitet ist), heisst das noch lange nicht, das sie gerade aus dem seriellen Port herausgepurzelt sind.
    Man muss schon auf das Ende der Schreiboperation zum UART warten. Der sendet aber gleich, sobald er die Daten uebernommen hat. Erst ab diesem Zeitpunkt kann man "warten".
    Das Ende des Datensendens nach WriteFile kann man mit WAIT_OBJECT_0 von WaitForMultipleObjects (mit einem overlapped event) erfahren.

    Blackbird

    0
  • J

    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.
    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

    0
  • A

    So, habs jetzt mal ausprobiert:

    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

    0
  • B

    *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.

    0
  • N

    anonymus schrieb:

    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);   
}
    0
  • J

    Blackbird schrieb:

    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!

    0
Anmelden zum Antworten