Робота с Com-портом.ВАЖНО!

← →
swan © (2005-12-07 21:07) [0]

Уважаемые господа. Помогите разобраться начинающему в хитросплетениях общения с COM-портом.
Задача следующая: послать в порт набор символов для управления внешним устройством и
получить от него ответ. С посылкой вроде все получилось, а вот с приёмом никак. Я приём
"повесил" на таймер, хотя устройство отвечает тут же. Т.е. цикл приема-передачи однократный
по указке программы. Может, я некорректно читаю из порта? Вот процедура, отвечающая за прием
данных:
function ReadComm(var Buff; size: word): integer;
var i: Cardinal; ovr: TOverlapped;

begin
result:=0;
fillChar(Buff, size, 0);
fillChar(ovr, sizeOf(TOverlapped), 0);
i:=0;
if not Windows.ReadFile(f, Buff, size, i, @ovr) then exit;
result:=i;
end;

Соответственно Buff описан как массив символов.
При опросе статуса порта на наличие байт в "приемнике", ответ - 0.
Помогите, пожалуйста!!! Очень прошу.
С уважением, Павел.

← →
Набережных С. © (2005-12-07 22:10) [1]

> С посылкой вроде все получилось, а вот с приёмом никак

Что, просто компьютер так и говорит человеческим голосом - с приемом, мол, никак? Или это как-то иначе проявляется? Неужели так трудно 5 минут подумать над формулировкой собственного вопроса?

В общем, есть подозрение, что файл открыт с флагом FILE_FLAG_OVERLAPPED. Напиши так:
if not Windows.ReadFile(f, Buff, size, i, @ovr) then raiselastoserror
и посмотри, что за ошибка.

← →
swan © (2005-12-08 20:10) [2]

Я попробую показать весь код тест-программы. Дело в том, что почти все, кто пишет о работе с портом подразумевают асинхронную работу в нем. А мне надо 4 раза в сек. опросить 4 устройства по-очереди и получить от них ответ. Размер пакета от 4 до 12 байт. А на Ваш совет вставить проверку чтения из порта раекции проги не последовало. Помогите, если возможно.
unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Buttons, ExtCtrls;

type
TForm1 = class(TForm)
LabeledEdit1: TLabeledEdit;
BitBtn1: TBitBtn;
LabeledEdit2: TLabeledEdit;
Panel1: TPanel;
Timer1: TTimer;
procedure BitBtn1Click(Sender: TObject);
{ procedure Timer1Timer(Sender: TObject);}
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

function OpenComm: boolean;
function ReadComm(var Buff; size: word): integer;
function WriteComm(var Buff; size: word): integer;
function DoneComm: boolean;
var
Form1: TForm1;
f: THandle;
DCB: TDCB;
buffIn: array [0..255] of byte;
buffOut: array [0..255] of byte;
colIn, colOut: integer;
strOut, strIn: shortstring;
mask: DWORD;

implementation

{$R *.dfm}

function OpenComm: boolean;
var
TimeOuts : TCommTimeouts;
begin
result:=False;
f := Windows.CreateFile(PChar("COM2"),
GENERIC_READ or GENERIC_WRITE,
FILE_SHARE_READ or FILE_SHARE_WRITE,nil,OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,0);
if not Windows.SetupComm(f,512,512) or not
Windows.GetCommState(f, DCB) then Exit;
DCB.BaudRate:=9600;
DCB.ByteSize:=8;
DCB.Parity:=NoParity;
DCB.StopBits:=OneStopBit;
if not Windows.SetCommState(f,DCB) or not
Windows.GetCommTimeouts(f, TimeOuts) then Exit;
TimeOuts.ReadIntervalTimeout := MAXDWORD;
TimeOuts.ReadTotalTimeoutMultiplier := 0;
TimeOuts.ReadTotalTimeoutConstant := 0;
TimeOuts.WriteTotalTimeoutMultiplier := 0;
TimeOuts.WriteTotalTimeoutConstant := 0;
if not Windows.SetCommTimeouts(f,TimeOuts) or not
Windows.SetCommMask(f, EV_RING + EV_RXCHAR + EV_RXFLAG + EV_TXEMPTY)
then Exit;
result:= True;
end;

function ReadComm(var Buff; size: word): integer;
var i: Cardinal; ovr: TOverlapped;

begin
result:=0;
fillChar(Buff, size, 0);
fillChar(ovr, sizeOf(TOverlapped), 0);
i:=0;
if not Windows.ReadFile(f, Buff, size, i, @ovr) then begin
raiselastoserror;
exit;
end;
result:=i;
end;

function WriteComm(var Buff; size: word): integer;
var p: pointer;
i: Cardinal;
begin
p:=@Buff;
result:=0;
while size > 0 do begin
if not WriteFile(f, p^, 1, i, nil) then exit;
inc(result, i);
{showmessage("result = "+inttostr(result));}
inc(integer(p));
dec(size);
Application.ProcessMessages;
end;
end;

function DoneComm: boolean;
begin
result:=Windows.CloseHandle(f);
end;

procedure TForm1.BitBtn1Click(Sender: TObject);
begin
mask:=0;
if OpenComm then
begin
strOut:=char(13) + LabeledEdit1.Text + char(13);
WriteComm(strOut,(Length(strOut)+1));

GetCommMask(f,mask);
if (mask and EV_RXCHAR) = EV_RXCHAR then begin
ReadComm(strIn,10);
LabeledEdit2.Text:=strIn;
end
else ShowMessage("No data of Port1");
Windows.CloseHandle(f);
end
else ShowMessage("No Port1 bye");
end;

{procedure TForm1.Timer1Timer(Sender: TObject);
var ComStat: TComStat;
e: DWORD;
InQ: integer;
begin
InQ:=40;

if ReadComm(strIn,256)>0 Then begin
if ClearCommError(f, e, @ComStat) then InQ:=ComStat.cbInQue;
Panel1.Caption:=IntToStr(InQ);
Timer1.Enabled:=False;
Windows.CloseHandle(f);
end;

end;}

procedure TForm1.FormCreate(Sender: TObject);
begin
if not OpenComm then Showmessage("Kosyak!!!")
else ShowMessage("OK!!!");
end;

end.

← →
Набережных С. © (2005-12-08 21:47) [3]

> Дело в том, что почти все, кто пишет о работе с портом подразумевают
> асинхронную работу в нем.

Это потому, что асинхронная работа с портом гораздо удобнее, легче встраивается в архитектуру приложения. Работа с портм подразумевает работу с каким-то внешним устройство, поведение которого невозможно прогнозировать. В асинхронном режиме гораздо легче реагировать на различные ситуации. Ну это так, лирика.

По поводу кода много чего можно сказать...но я уже спать хочу, у меня был не самый легкий день. Та проблема, о которой ты писал, скорее всего вот здесь:
WriteComm(strOut,(Length(strOut)+1)); GetCommMask(f,mask); if (mask and EV_RXCHAR) = EV_RXCHAR then begin ReadComm(strIn,10); LabeledEdit2.Text:=strIn; end else ShowMessage("No data of Port1"); Windows.CloseHandle(f); end else ShowMessage("No Port1 bye");
Ты записал данные в буфер порта и тут же проверяешь его флаги. К моменту проверки данные еще даже не успели уйти с порта, не говоря уж об ответе устройства. Я конечно не знаю твоего протокола, но если это запрос-ответ, где инициатор - компьютер, то так делать нельзя. Сначала нужно дождаться события с помощью WaitCommEvent, а уж потом проверять, что там случилось, данные пришли, или ошибка какая, и соответственно реагировать. А таймер, вот Timer1.Enabled:=False вижу, а True - нет.

Но это только начало проблем. Ума не приложу, что ты собираешься делать, если, например, к моменту запуска программы устройство просто забыли включить. Тем более, что у тебя их четыре. Ну да это не мое дело, сам поди не маленький.

И учись, все-таки, формулировать вопросы. Ты думаешь, у многих найдется желание вникать в твой код? Оно кому-то надо? Нет бы написать, используя общепринятую терминологи: задача такая-то, пытаюсь решить вот таким образом, код вызывается вт так-то и так-то, входные данные такие-то, вот здесь происходит то-то и то-то, функция возвращает такой-то результат, такие-то значение или поднимается такое-то исключение, ну и в таком духе.
Неужели это так сложно?

← →
swan © (2005-12-08 22:41) [4]

Большое СПАСИБО. В следующий раз буду грамотно формулировать задачу(или хотя бы пытаться). Попробую разобраться. С уважением, Павел.

← →
Германн © (2005-12-09 01:27) [5]

2 swan © (08.12.05 22:41) [4]
Ну как бы даже очень непоследовательно говорить о "Дело в том, что почти все, кто пишет о работе с портом подразумевают асинхронную работу в нем." и при этом работать в таком режиме только при чтении из порта. :(

А для
> А мне надо 4 раза в сек. опросить 4 устройства по-очереди
> и получить от них ответ.

стоит найти другое решение, чем синхронная посылка в порт. Имхо.

← →
Набережных С. © (2005-12-09 07:32) [6]

> Германн © (09.12.05 01:27) [5]
> 2 swan © (08.12.05 22:41) [4]
> Ну как бы даже очень непоследовательно говорить о "Дело
> в том, что почти все, кто пишет о работе с портом подразумевают
> асинхронную работу в нем." и при этом работать в таком режиме
> только при чтении из порта. :(

Здесь нет асинхронного чтения. Режим работы определяется при вызове CreateFile и изменен может быть только при переоткрытии файла. При этом невозможно работать асинхронно с файлом/устройством, открытом в синхронном режиме обмена, и наоборот, синхронно с открытым в асинхронном режиме.

← →
tesseract © (2005-12-10 12:06) [7]

> "Дело в том, что почти все, кто пишет о работе с портом
> подразумевают асинхронную работу в нем."

Правильно делают, она снижает загрузку ЦП в эндцать раз.
У меня есть недописанный класс с прямым доступом к драйверу, тот вообще раз в 10-15 быстрее API.

← →
Набережных С. © (2005-12-10 16:44) [8]

> tesseract © (10.12.05 12:06) [7]
>
> > "Дело в том, что почти все, кто пишет о работе с портом
>
> > подразумевают асинхронную работу в нем."
>
>
> Правильно делают, она снижает загрузку ЦП в эндцать раз.
>

Бред. Не надоело ламерство демонстрировать?

← →
tesseract © (2005-12-10 19:06) [9]

>>Бред. Не надоело ламерство демонстрировать?

Это ты себе говори.

А ты реально знаешь процедуру обработки IRP? Или думаешь что обращение к COM их не вызывает?

to swan >>
Инициализацию порта делай с FILE_FLAG_OVERLAPPED

function trThread.InitPort:boolean;
var
CommTimeOuts:TCOMMTIMEOUTS;
begin
// Не верим, что получится
Result:=false;
// реагируем на символ
fMask:=EV_RXCHAR and not EV_RING;
fPortname:=PChar("COM"+inttostr(fScaleSet.Port));
// создаём дескриптор
//crit.Acquire;
try
hCom:=CreateFile(fPortName,GENERIC_READ OR GENERIC_WRITE,0,NIL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED{FILE_ATTRIBUTE_NORMAL},0);
// Если неверен выходим
if GetLastError=ERROR_ALREADY_EXISTS then
begin
CloseHandle(hCOM);
status:=GetLastError;
AddLog("Порт занят"+ fPortName)
end;
FillChar(ReadOl,SizeOF(ReadOL),0);

ReadOl.hevent:=CreateEvent(nil,true,true,nil);
Status:=GetLastError;

if (hCom=0) or (hCom=INVALID_HANDLE_VALUE) then
begin
Status:=GetLastError;
AddLog("Ошибка порта "+ fportName);
// crit.Release;
exit;
end
else
AddLog("Открыт порт "+ fportName);
// Устанавливаем буфер
if not(SetupComm(hCom,22,10)) then
begin
status:=GetLastError;
AddLog("SetupComm Error "+ fPortName);
exit;
end;
// Чистим буфер
if not(PurgeComm(hCom,PURGE_TXABORT or PURGE_RXABORT or PURGE_TXCLEAR or PURGE_RXCLEAR )) then exit;
// Устанавливаем задержки/время ожидания
CommTimeOuts.ReadIntervalTimeout:= 50;
CommTimeOuts.ReadTotalTimeoutMultiplier := 10;
CommTimeOuts.ReadTotalTimeoutConstant := 00;
CommTimeOuts.WriteTotalTimeoutMultiplier := 10;
CommTimeOuts.WriteTotalTimeoutConstant := 00;
// DTR и RTS нам на фиг не нужен
EscapeCommFunction(hCom,SETDTR);
EscapeCommFunction(hCom,CLRRTS);
//Если не получилось выходим
SetCommTimeouts(hCom,CommTimeOuts);
// Устанавливаем параметры порта через DCB
if not(GetCommState(hCom,mDCB)) then
begin
status:=GetLastError;
AddLog("GetCommState Error "+ fPortName);
exit;
end;

MDCB.BaudRate:=fScalePar.hDCB.BaudRate;
MDCB.ByteSize:=fScalePAr.hDCB.ByteSize;
MDCB.Parity:=FscalePar.hDCB.Parity;
MDCB.StopBits:=FScalePar.hDCB.StopBits;

//Заполняем нужные параметры
// Устанавливаем параметры порта и перхвата
if not(SetCommState(hCom,mDCB)) then
begin
Status:=GetLastError;
Addlog("SetCommState Error "+ fPortName);
exit;
end;
// устанавливаем маску перехвата
if not(SetCommMask(hCom,fMask)) then
begin
Status:=GetLastError;
Addlog("SetComMask Error" +fportName);
exit;
end;
// Если дошли до сюда то всё ок
Result:=true;
finally
end;
end;

//Пример процедуры чтения ()
function trThread.AsyncRead:boolean;
var tMask:DWord;
begin
result:=false;
if terminated then exit;
// убираем событие - идёт запись

fWait.ReSetEvent;

if hCom=0 then exit;
// Если надо синхронизироваться, то делаем это

// Ждём сообщения о чтении
WaitCommEvent(hCom,tMask,@READOL);
fSignaled:= WaitForSingleObject(ReadOl.hEvent,WaitInt);
if (fSignaled = WAIT_OBJECT_0) then
begin
// смотрим что у нас
begin
// Читаем
if GetOverlappedResult(hCom, REadOL, BytesTrans,false) then
begin
// Сравниваем произошедшее событие с прибытием символа
if (tMask and EV_RXCHAR)<>0 then
begin
AvBytes:=GetAvBytes; // Сколько байтов пришло
if AvBytes>=fScalePar.Size then
begin
//try
// Если пришло нужное кол-во то
//buf:="";
if ReadFile(hCom,buf^,AvBytes,ReadBytes,@ReadOL) then
begin
// Чистим буфер
PurgeComm(hCom,PURGE_RXCLEAR);
result:=true;
// Если прочитали нужное кол-во
if (ReadBytes>=fScalePAr.Size) then
begin
if not terminated
then
begin
fWeight:=ScaleRead;
// ChangeWeight;
State:="Данные разобраны";
end;
end;
end// if REadFile
else
begin
// Ошибка
fWait.setEvent;
Status:=GetLastError;
Addlog("Чтение невозможно");
end; // if REadFile

// end;
end; // if AvBytes
end; // if Fmask
end;// if GetOVerlappedResult
end; // if Signaled
end; // waitcommevent

fWait.SetEvent;

end.

← →
Набережных С. © (2005-12-10 20:15) [10]

> tesseract © (10.12.05 19:06) [9]

> Это ты себе говори.

Я говорю это тому, кому считаю нужным. В данном случае - Вам. Достало уже:(

> А ты реально знаешь процедуру обработки IRP?

Нет, я не знаю реальную реализацию драйвера. Зато я представляю себе, как она примерно может выглядеть. И уж конечно разработчики реализовали драйвер не хуже, чем я могу себе представить, как минимум.
В любом случае ни о каких "эндцати" разах речи быть не может, в любом случае ему сидеть на прерывании.

ЗЫ Код - фтопку.

← →
Германн © (2005-12-11 01:21) [11]

> Набережных С. © (10.12.05 16:44) [8]
>
>
> > tesseract © (10.12.05 12:06) [7]
> >
> > > "Дело в том, что почти все, кто пишет о работе с портом
>
> >
> > > подразумевают асинхронную работу в нем."
> >
> >
> > Правильно делают, она снижает загрузку ЦП в эндцать раз.
>
> >
>
>
> Бред. Не надоело ламерство демонстрировать?

Ну насчет бреда это вы батенька немного перебрали. Просто сформулировано несколько неверно. Надо было бы написать примерно так: "Чаще всего применяемый новичками способ синхронного чтения порта типа чтения в цикле до тех пор пока все данные не будут получены загружает процессор по черному!

← →
Набережных С. © (2005-12-11 07:21) [12]

> Германн © (11.12.05 01:21) [11]

У меня, батенька:), к ночи телепатор обычно совсем перестает работать:), прочитал только то, что написано, не домысливая. И охарактеризовал так, как оно, на мой взгляд того заслуживает. Возможно слишком резко, но - действительно достало! И конференция-то для начинающих, далеко не каждый здесь сам уже может адекватно оценить полученную информацию, так тем более надо быть аккуратным, ИМХО. А если не обращать внимания, зачем вообще кому-то помагать? Толку-то все-равно не будет:(

> Надо было бы написать примерно так: "Чаще всего применяемый
> новичками способ синхронного чтения порта типа чтения в
> цикле до тех пор пока все данные не будут получены загружает
> процессор по черному!

А вот это совсем не зависит от синхронности/асинхронности операции, такой подход при любом способе даст одинаковый эффект, если читать малыми порциями. Так что, батенька, возражение отклоняется:)

Действительно очень неэффективный подход, вот только на счет "по черному!", это Вы, батенька, немного перебрали:). Скорость работы реального COM-порта слишком мала, выборка будет происходить намного быстрее поступления данных, поэтому большой загрузки процессора на более-менее современном железе достичь не удастся, если, конечно, я правильно понял смысл выражения "загружает по черному".

Вы ведь, судя по [5], не разбираетесь в асинхронном обмене? Просто иначе трудно объяснить столь очевидную ошибку. Тем не менее не считаете нужным даже добавлять к своим высказываниям "IMHO". Никогда этого не понимал:((

Впрочем, если есть другое объяснение, я с радостью и облегчением принесу Вам свои извинения.

← →
tesseract © (2005-12-11 13:31) [13]

>Вы ведь, судя по [5], не разбираетесь в асинхронном обмене? Просто иначе >трудно объяснить столь очевидную ошибку. Тем не менее не считаете нужным >даже добавлять к своим высказываниям "IMHO". Никогда этого не понимал:((

Сам себя топи. Если не разбираешься в механизме обработки прерываний и очереди IRP Ну хотя-бы не выкобенивайся, не в бобруйске.

Код реально выдран из проекта для сырного завода, работает 4 месяца в 24х7. Четверо весов + 2 термопринтера + p2-450 .

А тупо чужой срать умения не нужно ты реально покажи что где и почему.

ЗЫ:Увидимся в топке.

> Если не разбираешься в механизме обработки прерываний и
> очереди IRP Ну хотя-бы не выкобенивайся, не в бобруйске.
>

А Вы, видимо, очень здорово разбираетесь. Ну так расскажите нам, чем же обусловлена заявленная Вами разница в нагрузки на процессор. Думаю, многим будет очень интересно.

> Код реально выдран из проекта для сырного завода, работает
> 4 месяца в 24х7

Очень часто и худший код работает, но это не значит, что он грамотно написан.

> А тупо чужой срать умения не нужно ты реально покажи что
> где и почему.

Да вот, пожалуйста:

> hCom:=CreateFile(fPortName,GENERIC_READ OR GENERIC_WRITE,
> 0,NIL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED{FILE_ATTRIBUTE_NORMAL},
> 0);
> // Если неверен выходим
> if GetLastError=ERROR_ALREADY_EXISTS then
> begin

Знаток драйверов должен бы знать, что ресурсы бывают разделяемые и неразделяемые, и COM-порт относится к последним.
А дальше мне, извините, вникать лень. Вы уж сами.

> Увидимся в топке.

Это вряд ли. Не знаю, как Вам, а мне туда пока вроде как рановато.

>>
>Знаток драйверов должен бы знать, что ресурсы бывают разделяемые и >неразделяемые, и COM-порт относится к последним.
>>А дальше мне, извините, вникать лень. Вы уж сами.

ДА именно и поэтому CreateFile в случае провала ERROR_ALREADY_EXISTS и вернёт т.к ресурс не разделяемый . О чём следует доложить пользователю. Вникаёте внимательно.

>> А Вы, видимо, очень здорово разбиаетесь. Ну так расскажите нам, чем же >>обусловлена заявленная Вами разница в нагрузки на процессор. Думаю, >>многим будет очень интересно.

Происходит не столько загрузка на процессор, сколько ожидание завершения обработки прерывания. А устройство в принципе может неожиданно выключится, включится и тд. И будете вы ждать пока вам функция чего-то, что указано в DCB timeouts вам вернёт вместе со всей осью.

> >Знаток драйверов должен бы знать, что ресурсы бывают разделяемые
> и >неразделяемые, и COM-порт относится к последним.
> >>А дальше мне, извините, вникать лень. Вы уж сами.
>
> ДА именно и поэтому CreateFile в случае провала ERROR_ALREADY_EXISTS
> и вернёт т.к ресурс не разделяемый . О чём следует доложить
> пользователю. Вникаёте внимательно.

Нет. Именно поэтому она, CreateFile, для Com-порта никогда не вернет ошибку ERROR_ALREADY_EXISTS, эта ошибка возвращается в совсем других случаях. А вернет она, если порт занят, ERROR_ACCESS_DENIED. RTFM и практика, RTFM и практика, молодой человек.

> tesseract © (10.12.05 12:06) [7]
>
> > "Дело в том, что почти все, кто пишет о работе с портом
>
> > подразумевают асинхронную работу в нем."
>
>
> Правильно делают, она снижает загрузку ЦП в эндцать раз.
>

> tesseract © (11.12.05 20:07) [15]

> Происходит не столько загрузка на процессор, сколько ожидание
> завершения обработки прерывания.

Ну вот мы и вернулись к "наши баранам". В чем, собственно, сомнений не было с самого начала.

> И будете вы ждать пока вам функция чего-то, что указано
> в DCB timeouts вам вернёт вместе со всей осью.

Кто, я? Что-то Вы опять какую-то несуразицу говорите. Не надо пытаться приписать мне то, чего я не говорил. Дешевый прием, не пройдет.

Все, мне эта ветка надояла, да и говорить, собственно, больше не о чем, посему я откланиваюсь, с Вашего позволения. Ну или без него.

> Набережных С. © (11.12.05 07:21) [12]
>
>
> > Германн © (11.12.05 01:21) [11]
>
> У меня, батенька:), к ночи телепатор обычно совсем перестает
> работать:), прочитал только то, что написано, не домысливая.
И я тоже. Что прочитал, на то и среагировал. Код не смотрел(об этом ниже).

> И охарактеризовал так, как оно, на мой взгляд того заслуживает.
> Возможно слишком резко, но - действительно достало! И конференция-
> то для начинающих, далеко не каждый здесь сам уже может
> адекватно оценить полученную информацию, так тем более надо
> быть аккуратным, ИМХО. А если не обращать внимания, зачем
> вообще кому-то помагать? Толку-то все-равно не будет:(
Ну, имхо, "не достаточная адекватность - не есть обоснование для резкости, имхо"!

>
> > Надо было бы написать примерно так: "Чаще всего применяемый
>
> > новичками способ синхронного чтения порта типа чтения
> в
> > цикле до тех пор пока все данные не будут получены загружает
>
> > процессор по черному!
>
> А вот это совсем не зависит от синхронности/асинхронности
> операции, такой подход при любом способе даст одинаковый
> эффект, если читать малыми порциями. Так что, батенька,
> возражение отклоняется:)

Ну и я тоже читал и отвечал с учётом "наболевшего". А оно, всё-таки зависит порой и иногда и с учётом...
>
> Вы ведь, судя по [5], не разбираетесь в асинхронном обмене?
> Просто иначе трудно объяснить столь очевидную ошибку. Тем
> не менее не считаете нужным даже добавлять к своим высказываниям
> "IMHO". Никогда этого не понимал:((
Добавляю всегда, когда нужно. :)
И да и нет. Т.е. идеологически я "разбираюсь в асинхронном обмене", но и сам лично не писАл работу с COM-портом на API, посему не могу с уверенностью ответить ДА. Но и читай выше.

>
> Впрочем, если есть другое объяснение, я с радостью и облегчением
> принесу Вам свои извинения.

Другое объяснение есть. Дело в том, что я знаю эту проблему с "другой стороны". Я один их многих, кто разрабатывает железо, которое общается с компьютером через COM-порт. И видел как чаще всего решают эту задачу программисты с опытом, но без опыта работы с внешними устройствами.

Да. С форматированием я тут пролетел.
Отвечал как на письмо. :(

> Германн © (12.12.05 02:59) [17]

Хоть я и распрощался с этой веткой, но не ответить Вам было бы не вежливого, мне кажется. Потому придется нарушить собственное слово.

> Ну, имхо, "не достаточная адекватность - не есть обоснование
> для резкости, имхо"!

"недостаточная адекватность" говорилось в отношении новичков, нормальных новичков, которым просто пока не хватает знаний и опыта, пришедших сюда за помощью, и не ожидающих, что их обманут из простого желания поупражняться в гимнастике для пальцев. А никак не отвечающих на вопросы, которые тем самым берут на себя ответственность за свои слова.

Только не поймите меня превратно, я вовсе не утверждаю, что отвечающие не имеют право на ошибку - ну кто же не ошибается, всем, ИМХО, случается. И я не утверждаю, что отвечать должны только те, кто досконально знаком с вопросом. Нет конечно, попытаться ответить или высказать свое мнение имеет право, разумеется, каждый.

Но есть разница между добросовестным заблуждением, когда ответ формулируется соответствующим образом, и безапеляционным, самоуверенным утверждением по вопросу, о котором отвечающий имеет поверхностное представление - в лучшем случае. Как принято в программистком сообществе называть людей, делающих такие заявления, известно, и так я и высказался. Или Вы считаете, что публично лгать - это допустимо, а вот публично же назвать лжеца лжецом - это верх неприличия? Я так не считаю.

> > А вот это совсем не зависит от синхронности/асинхронности

> Ну и я тоже читал и отвечал с учётом "наболевшего". А оно,
> всё-таки зависит порой и иногда и с учётом...

Не понятно, что Вы хотели этим сказать. Видимо, я недостаточно умен, чтобы это понять:( По сути - при чтения по одному байту эффект будет практически одинаковый хоть при синхронном, хоть при асинхронном способе, по причене отсутствия поводов для сколь-нибудь ощутимой разницы. По крайней мере, я таких поводов не вижу, если Вы или кто-либо другой мне их укажите, буду только признателен.

> Другое объяснение есть. Дело в том, что я знаю эту проблему
> с "другой стороны". Я один их многих, кто разрабатывает
> железо, которое общается с компьютером через COM-порт. И
> видел как чаще всего решают эту задачу программисты с опытом,
> но без опыта работы с внешними устройствами.

Раз Вы считаете это действительно весомым объяснением, то, значит, так оно и есть. Хотя у меня другое мнение на этот счет( о чем ниже ), тем не менее
Приношу Вам свои извинения.

А теперь попробую высказать, как это видится мне.
Прошу прощения за повтор:

> Я один их многих, кто разрабатывает железо, которое общается
> с компьютером через COM-порт. И видел как чаще всего решают
> эту задачу программисты с опытом, но без опыта работы с
> внешними устройствами.

Видите ли, я как бы не отношусь к тем, у кого совсем нет опыта "с другого конца". Не стану утверждать, что он большой или сравнимый с Вашим, но он все-таки типа есть - и в области разработки устройств, и написания для них програм, и в области написания ПО для взаимодействия с устройствами. И этот опыт говорит мне, что грамотно спроектированному устройству совершенно параллельно, на какие извраты пойдет автор прогрммы для хоста. Впрочем, обратное справедливо точно так же. Но суть в том, что к делу это не относится, ИМХО. Речь-то шла о совершенно конкретной вещи, совершенно однозначно сформулированной в [7], на которую и последовал ответ в [8]. Именно об этом. А перескакивать с обсуждаемого вопроса на соседние области, когда по обсуждаемому нет аргументов - это, извините, не мой стиль.

На этом, извините, действительно все. Больше я в эту ветку не возвращаюсь. Спасибо и до свидания, но только не в этой теме:)

Робота с Com-портом.ВАЖНО! Найти похожие ветки