СОМ-порт и Windows, как повысить реакцию на прием байт?

[DropSoft]

Работаю с СОМ-портом из Windows, использую модуль Synaser из библиотеки Synapase.
При чтении порта данные приходят частями с интервалом 15-17 мс. Вот пример лога чтения ответа на очередной запрос:

Код: Выделить всё

16:54:23.621 _Send> 03 41 00 06 C8 38 8A 34
16:54:23.621 _isRC>
16:54:23.623 _isRC>
16:54:23.625 _isRC> 03 41 00 06 C8 38 FF FF FF FF FF
16:54:23.627 _isRC>
16:54:23.629 _isRC>
16:54:23.631 _isRC>
16:54:23.633 _isRC>
16:54:23.635 _isRC>
16:54:23.637 _isRC>
16:54:23.639 _isRC>
16:54:23.642 _isRC> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F6 69

Получается, в 621 мс послан запрос, в 625 мс получена первая часть данных, затем около 17 мс ничего нет, а потом в 642мс приходит оставшаяся часть посылки.
Хотя физически ответная посылка передается цельным куском. Я понимаю, что это особенности работы Windows, прием производится через

Код: Выделить всё

ReadFile(FHandle, Buffer^, length, Dword(Result), @Overlapped)

Но можно ли как-нибудь этого избежать, чтобы получать байты из порта не позднее хотя бы одной миллисекунды после их физического прихода в UART?

[olegy123]

Откуда получаете данные, как читаете, могут ли быть там задержки. Есть ли возможность работать на больших скоростях. Нужны больше информации.

[DropSoft]

Посылается запрос на скорости вплоть до 3 МБод (переходник с USB на FT232R поддерживает).
На посылку приходит ответ от прибора, практически сразу (задержка - менее пары сотен микросекунд), длина посылок ограничена 256 байт (ограничение прибора), если компьютер не получил ответ на посылку в течении таймаута (обычно 50-100 мс), запрос повторяется несколько раз. Если физическая среда RS-485 - полудуплекс, то _одновременно_ посылать и принимать нельзя. При этом цикл обмена составляет (по осциллографу) в районе 1000...1100 мкс. А фактически из-за Windows цикл занимает 16...20 мс. При передаче больших массивов информации (или опросе большой сети приборов) время увеличивается фактически в 15 и более раз.
Длина ответной посылки указывается в заголовке ответной посылки, что требует побайтного анализа приходящих данных, чтобы выделить заголовок и затем принять указанное число байтов и проверить контрольную сумму. Циклы передачи - приема ведутся в отдельном потоке.
Пробовал играть значениями структуры COMMTIMEOUTS, не помогает.

[Seenkao]

Сделай задержку на отсылку данных.

Насколько я читал, там слишком большая частота отправки данных, из-за этого происходят сбои.

[olegy123]

Получается, в 621 мс послан запрос, в 625 мс получена первая часть данных, затем около 17 мс ничего нет, а потом в 642мс приходит оставшаяся часть посылки.

на сколько помню, можно работать в неблокирующим режиме. Читать обязательно весь буфер а не посимвольно.

[Pavia]

Overlapped тормозит. Пиши без него.

Добавлено спустя 2 минуты 36 секунд:

При чтении порта данные приходят частями с интервалом 15-17 мс. Вот пример лога чтения ответа на очередной запрос:

А таймер для лога у вас какой если gettickcount то у него дискретность 15-17 мс.

[DropSoft]

Pavia Таймер миллисекунды правильно выдает, без пропусков.

Код: Выделить всё

MemoLog.Add(FormatDateTime('HH:NN:SS.ZZZ  ',Now) + s);

Без overlapped попробую, это надо будет в исходниках модуля Synaser из библиотеки Synapase ковыряться.

[info53]

Попробуйте уменьшить таймаут в настройках драйвера FT232, как указано на картинке ниже

[АндрейБ]

Если вы используете микросхему FTDI для организации виртуального СОМ-порта,
то решение, на мой взгляд, есть. В диспетчере устройств в настройках виртуального
СОМ-порта в дополнительных настройках есть параметр "Время ожидания (мсек)".
По умолчанию там стоит 16мс, но можно поставить 1мс.
И сразу становится всё намного быстрее.