Problem jest nieco głębszy więc zacznę od początku....
W aplikacji którą mam jest możliwość wysłania czegoś na port szeregowy... przy czym cała obsługa wygląda tak, że jest otwierany port, później wysyłane są znaki i port jest zamykany.
w skrócie jest to klasyczny przykład transmisji na tym porcie, w bardzo dużym skrócie kod wygląda tak:
...
FPortHandle := CreateFile(PChar('\\.\COM1'), (GENERIC_READ or GENERIC_WRITE), 0, nil, OPEN_EXISTING, 0, 0);
...
WriteFile(FPortHandle, Buf^, FOutBufSize, Sent, nil);
...
CloseHandle(FPortHandle);
I jeszcze jedno urządzenie nigdy niczego nie zwraca... więc czekanie na informację zwrotną nie ma większego sensu, po prostu ma być to wysłane na port i tyle...
Oczywiście jest konfiguracja parametrów portu, prędkości transmisji itd..., wywoływany są funkcje API FlushFileBuffers, WaitCommEvent.... itd...
I wszystko jest ok na fizycznych portach COM, czy na sterownikach popełnionych przez Microsoft. Problem pojawia się jeżeli jest to interface USB z konwersją na COM... do którego podpięte jest jakieś urządzenie, a sterowniki napisane są przez dostawcę tego cuda...
W przypadku gdy używam portu fizycznego to closehandle zachowuje się poprawnie, dane są kompletne i na drugim komputerze (testowym) dostaję je w całości...
Jednak w przypadku przejściówek USB... pojawia się problem... CloseHandle urywa transmisję nieważne ile zostało w rzeczywistości wysłane...
Przykładowo wysyłam 100 bajtów (tle jest przekazane do WriteFile), dostaję informację, że wszystko jest ok i że zostało zapisane/wysłane 100 bajtów...
jednak na drugim komputerze odbieram tylko cześć danych... rozwiązaniem tymczasowym jest wywołanie delay(100) przed zamknięciem portu... ale... podejrzewam że czas oczekiwania będzie różny w zależności od długości wysłanych danych i zdefiniowanej prędkości transmisji... żadne próby i kombinacje z FlushFileBuffers i WaitCommEvent nie odniosły skutku...
Mało tego... problem nie występuje tylko w Delphi... wyglądana to że jest to ogólny problem w Windowsie
Ten sam problem występuje nawet gdy wysyła się dane z ręki z konsoli...
MODE COM2: BAUD=57600 PARITY=N DATA=8 STOP=1 XON=OFF
Copy /b 1.txt COM2:
Również dane są urwane... niekompletne..
Wina jest na 100% po stronie sterowników różnych producentów przejściówek... tyle, że tych 'złych' jest chyba więcej... na 6 testowanych chyba tylko jedna zachowuje się poprawnie...
Może jest na to jakieś rozwiązanie? Chociaż jak nawet konsola na tym padła...
Szukałem rozwiązań na necie... i echo... nie zauważyłem by ktoś z tym walczył... czy znalazł rozwiązanie...
A dokładanie Delay na przed zamknięciem portu to chyba najgorsza możliwa opcja... tyle, że może się okazać jedyną...
Może ktoś rozwiązał ten problem, bądź wie jak go rozwiązać?
Z gry dziękuje za wszelkie sugestie
Pozdrawiam
Darek