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), с кратковременных падением уровня. Но опять же, пробовал и другие адаптеры, правда из той же серии (используется Мокса с опторазвязкой). попробую что-то еще.
Очень может быть что проблема многоуровневая. Буквально на прошлой неделе такое решал- проблема одновременно была и Матлабовском скрипте, и в формате файла данных, и в методике расчета в устройстве которое считало данные для этого файла, прямо цепочку раскручивал, хотя вначале думал что ошибка просто в скрипте. Но это не в данном устройстве

[XVR]

Надеюсь что это глюки в подключенном к сериальному порту девайсе (конвертере RS485/232), с кратковременных падением уровня.

О! Уже RS485 появился Может дело в стыке RS485 <-> RS232? У RS485 half duplex, а у RS232 - full duplex. И конвертор переключает направление на прием/передачу по RS485 по неким своим законам. Они точно согласуются с реальным потоком данных по RS485? Ибо неверный момент переключения как раз и даст те самые пропущенные байты.

[@Ark]

О! Уже RS485 появился Может дело в стыке RS485 <-> RS232? У RS485 half duplex, а у RS232 - full duplex. И конвертор переключает направление на прием/передачу по RS485 по неким своим законам. Они точно согласуются с реальным потоком данных по RS485? Ибо неверный момент переключения как раз и даст те самые пропущенные байты.

Так вроде поток односторонний. Преобразователь RS485-RS232 будет только на прием работать со стороны RS485. Или мы чего-то не знаем опять?
ТС говорит, что до разъема PC все байты доходят. В любом случае, надо дождаться проверки "эталонным потоком", непосредственно в порт.
Нужно локализовать ошибку, прежде чем гипотезы строить.

[krux]

ТС говорит, что до разъема PC все байты доходят.

Давайте начнём с того, что ТС не выдаёт полной картины, а рубит хвост кусками.
Что уж говорить про "нюансы реализации", которые обходятся за три-девять земель.

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

[Ruslan1]

Давайте начнём с того, что ТС не выдаёт полной картины, а рубит хвост кусками.
Что уж говорить про "нюансы реализации", которые обходятся за три-девять земель.

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

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

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

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

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

[@Ark]

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

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