Windows7: прием байтов через COM-порт без потерь, Кто-то имеет личный опыт? чем побороть потерю отдельных байтов? Опции

[Ruslan1]

Здравствуйте!
Есть Windows7 Pro, 32-bit, компьютер- китайский одноплатник на Intel 1037U, 4GB RAM.
СОМ-порты- 4 штуки прямо на материнке.
И есть внешний передатчик, посылающий в COM-порт пакеты.
Скорость- 115200, стандартный формат 8N1.
Длина пакета- не более 255 байт, межпакетный интервал- не менее 4 байт, часто гораздо больше (десятки миллисекунд). Каждый пакет имеет контрольную сумму (crc16), по которой и принимается решение о валидности пакета. Общая загрузка канала где-то 5-8 килобайт в секунду, то есть до 80%. Загрузка CPU около 10-15%.

И есть самописная программа на С++Билдере (6), данный вариант делался по прерываниям, с несколькими потоками (базой был вот этот документ).
Есть поток, принимающий все байты по прерываниям и валящий в большой кольцевой буфер. И другой поток периодически выгребает байты из буфера и делит на пакеты для обработки, проверяет валидность.

Только прием, никаких переключений на передачу.
В результате приемник иногда пропускает байты. То есть все принятые байты всегда совпадают с переданными, но некоторые байты пропущены. Всегда пропущено не более одного байта за раз, в любом месте пакета. Часто бывает что пропущено по одному байту в двух следующих друг за другом пакетах.

Обычно фактов потери байта где-то 10-20 в сутки. Корреляция с действиями Виндоуса пока не найдена, очень уж все случайно.
Потери именно в компьютере- подключенный прямо к этому же разъему логический анализатор исправно ловит все байты, никакого криминала или отклонений во времянке не обнаружено (по уровню тоже все без проблем)


Вопросов два:
1. Кто-то в подобных условиях добивался абсолютно безошибочного приема потока через COM-порт в Виндоус (7) на 115200?
2. куда копать? Сильно надеюсь что моя программа виновата. На другом железе пробовал- эффект тот же, то есть это не электроника глючит.
С приоритетами игрался, никакого эффекта.

Заранее спасибо за любые советы (по существу).

[XVR]

Ваш снифер умеет показывать ошибки от COM порта? Если да, то включите их показ. Возможно байт не принялся по причине Framing Error.
Еще попробуйте осцилографом замерить точную частоту (время битового интервала). Потом включите порт на передачу и замерьте то же самое от РС (например через какой нибудь терминал). Если разница будет более 5% - то это оно Если более 1% - то может быть оно.

Ну и уровни проверьте. Настоящий COM порт должен обеспечивать +/- 12В, но лично я таких давно не видел. Обычно все в районе 5-10В бегает.
У меня даже был один сервер с COM портом который отказался свои же собственные уровни воспринимать (выдавал на выход 5В, на входе хотел не менее 7-8В)

[V_G]

Ну и уровни проверьте. Настоящий COM порт должен обеспечивать +/- 12В, но лично я таких давно не видел. Обычно все в районе 5-10В бегает.

Стандарт RS-232 предполагает уровни ±3...30 В, с этим диапазоном должны уметь работать все правильные порты. Как правило, периферия, в которой используются преобразователи уровня с удвоением питания, выдает ±6...10В, и это никак не должно сказываться на надежности передачи данных.

[XVR]

Стандарт RS-232 предполагает уровни ±3...30 В, с этим диапазоном должны уметь работать все правильные порты.

Ключевое слово 'правильные'. Кто знает, что именно поставили китайцы в RS232 на этом РС?

[Ruslan1]

Ключевое слово 'правильные'. Кто знает, что именно поставили китайцы в RS232 на этом РС?

Ребята, ну нельзя же так уж совсем. Уже сколько раз вижу ситуации про чукчу, который ни разу ни читатель.
Я уже говорил, что пробовал на разных компьютерах. Правда, всегда под Win7.
Если бы мне еще кто-нибудь сказал как детектировать вероятное падение амплитуды на пару байт в течении ну хоть часа без долгозаписывающего осциллографа- скажу спасибо.
понятно, что я в первую очередь про уровни подумал, еще месяц назад. Проверил в онлайне, но детальную долговременную запись аналогового сигнала и синхронизацию с цифрой не делал.
Первое что пришло в голову- виртуальный скоп на саундбластере, но он мои 55 килогерц не возьмет, а если вдруг и возьмет, то ни о какой достоверности измеряемого уровня на разных байтах говорить не приходится.
Пока что провожу симптоматичное лечение и тесты для локализации проблемы. Надеюсь что это глюки в подключенном к сериальному порту девайсе (конвертере RS485/232), с кратковременных падением уровня. Но опять же, пробовал и другие адаптеры, правда из той же серии (используется Мокса с опторазвязкой). попробую что-то еще.
Очень может быть что проблема многоуровневая. Буквально на прошлой неделе такое решал- проблема одновременно была и Матлабовском скрипте, и в формате файла данных, и в методике расчета в устройстве которое считало данные для этого файла, прямо цепочку раскручивал, хотя вначале думал что ошибка просто в скрипте. Но это не в данном устройстве

[jcxz]

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

В моём домашнем осцилле есть функция такая: можно задать допустимые границы осциллограммы на экране (её формы), и он зафиксирует момент выхода осциллограммы за пределы паттерна. Дальше - просто включить передачу постоянного пакета байт. И настроить эту функцию на осциллограмму этого пакета. Этот паттерн задаётся графически на экране.
ATTEN 1152