Здравствуйте!
Есть 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. куда копать? Сильно надеюсь что моя программа виновата. На другом железе пробовал- эффект тот же, то есть это не электроника глючит.
С приоритетами игрался, никакого эффекта.

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

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

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

Вы ничего не сказали про источник потока - физическое устройство, которое подключается к PC (как я понял, через преобразователь RS232-RS485).

Там целая сеточка, с таймслотами и синхросообщениями. Но в данном случае это неважно- как я уже описал, байты однозначно правильно долетают от итогового конвертера 485/232 до разъема компьютера. Но вот уверенности в том что уровень сигнала этих байтов всегда корректный, у меня нет.
Сейчас попробую конвертер 485/USB от FTDI, если результат другой- значит все-таки в конвертере дело.
Раньше 115200 и плотный поток вместе нигде не использовал, новый опыт, однако. через грабли.

Конвертор - это, как правило, только преобразователь уровней. Если частота неправильная, то она так и будет конвертирована в неправильную.
Я спрашивал про конкретное устройство, которое передает. На чем оно сделано, какой тактовый генератор (кварц) там стоит?

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

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

Сейчас убрал Моксу RS485/232, включил ФТДИ SR485/USB - то же самое, есть глюк.

Если предположить что проблема все-таки не в амплитуде, то что общего между сниффером, COM-портом и USB? действительно только времянка в голову приходит... В глобальные проблемы уровня "Винда глючит" все-таки пока не готов поверить.

Мы дождемся ответов на вопросы по поводу внешнего устройства - источника потока?

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


непонятно стало - вы с РС232 работаете или с РС485?

тип процессора- STM32F070
задающий кварц- ABLS2-16.000MHZ-D4Y, с конденсаторами 18 pF NP0
SystemCoreClock = 48 MHz, divider = 417 (подключился дебаггером к юниту, проверил регистры- действительно 417).
То есть реальная расчетная скорость 115108 , это -0.08%.
Даже если прибавить возможные 60 ppm кварца (стабильность плюс точность), будет 0.09%.
Что-то еще?

Ну и (приглядываясь к ближайшей стене на тему побить ее головой): так ведь возле компьютера вижу же ж я нормально эти байты, принятые логическим анализатором, а в компе уже не принимаются? Причем частоту семплирования ЛА задал 1 MHz - ему хватает для стабильного приема.
Хм... ну разве что в тот момент что-то высокоскоростное лезет и сбивает порт, а вот анализатор просто по семплрейту пашет, ему-то пофиг...
у меня сейчас на столе терминаторы были отключены...Подключил терминаторы в линию RS-485 - не поменялось.


Я принимаю все в большой буфер по событию (прерыванию от драйвера). Произошло прерывание- вытаскиваю и все принятое пихаю в мой большой буфер, изменяя указатель записи.
периодически по таймеру вызывается задача, которая из этого буфера пытается вычленить из потока новый фрейм (от указателя записи до указателя чтения). Если удалось - то смотрит чему равен указатель удачного фрейма, если не старому указателю чтения- то все байты от старого указателя чтения до этого фрейма и есть неопознанный мусор. Ну и, естественно, сдвигает указатель чтения на конец опознанного фрейма.


У меня система- на RS-485.
Для ввода в PC в штатном режиме использую конвертер RS485/232.
Сейчас для тестов задействовал также конвертер RS485/USB.

Кстати, на конкретно моем PC с конвертером RS485/232 гораздо больше ошибок валит в сравнении с работой через RS485/USB. Но зато этот USB товарищ ловит ошибки в пакетах во время подключения нового USB устройства.

Может, на большей скорости попробовать?

Спасибо. Вроде все нормально...


Я так предлагаю проверить - написать небольшую программку в винде, которая имитирует поток от вашего устройства. У Вас же несколько портов есть, по моему. Дальше соединяете два порта по принципу нуль-модема внешним соединением. И запускаете обе программы - рабочую и имитатор устройства...
Так, хотя бы определите в какой части системы искать ошибку - внутри PC или снаружи.
P.S. Можно потом с другого компа имитатор запустить, и соединить их нульмодемным кабелем.
В общем, "отсечь" все преобразователи, длинные линии, возможные помехи, а может и какие-то ошибки во внешнем устройстве.

Сообщение отредактировал @Ark - May 29 2017, 20:20

Ага, тоже так согласен надо сделать.
Но мне тут начальство подправило курс, задача все-таки не высокоприоритетная. Беру таймаут до выходных. Может, в фоне хоть эту простую проверку с эталонным источником потока сделаю на неделе.
Но уже сейчас вижу что проблема как минимум не только в моей программе. Очень может быть, что все-таки какие-то установки в винде влияют (но не в какой-то одной, а дефолтовые). попробую на XP и на 10-ке запустить, может найду их где вокруг...

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

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