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

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

[neiver]

Начинать надо с того, что COM порт вообще и его реализация в Windows в частности, не гарантирует безошибочной передачи данных.
То есть рассчитывать на это нельзя, и контроль и/или обеспечение целостности данных надо реализовывать в протоколе обмена. Поврежненный пакед должен отбрасываться и если нужно передаваться повторно.
По возможным причинам. У стандартного аппаратного СОМ порта есть внутренний буфер, как правило размером 15 байт. Это не тот буфер, который задается в SetupComm. Если драйвер порта по каким-то причинам не успеет прочитать этот буфер, то принятые байты теряются, о чем извещают соответствующие флаги возвращаемые ClearCommError.
Приоритет пользовательского процесса не влиет на приоритет драйвера СОМ порта при обработке прерываний.

[sonycman]

Начинать надо с того, что COM порт вообще и его реализация в Windows в частности, не гарантирует безошибочной передачи данных.
То есть рассчитывать на это нельзя, и контроль и/или обеспечение целостности данных надо реализовывать в протоколе обмена. Поврежненный пакед должен отбрасываться и если нужно передаваться повторно.
По возможным причинам. У стандартного аппаратного СОМ порта есть внутренний буфер, как правило размером 15 байт. Это не тот буфер, который задается в SetupComm. Если драйвер порта по каким-то причинам не успеет прочитать этот буфер, то принятые байты теряются, о чем извещают соответствующие флаги возвращаемые ClearCommError.
Приоритет пользовательского процесса не влиет на приоритет драйвера СОМ порта при обработке прерываний.

Тоже думаю, что проблема просто в переполнении ФИФО аппаратного приёмника.
Потому, что винда тупо не успевает выгребать данные.

Но тогда надо проверить, флаг переполнения должен быть установлен.

Может, стоит попробовать адаптер COM->USB, там аппаратная буферизация может быть лучше, и ошибок не будет?

[jcxz]

Тоже думаю, что проблема просто в переполнении ФИФО аппаратного приёмника.
Потому, что винда тупо не успевает выгребать данные.

Не думайте ибо этого не может быть.
Даже если-б загрузка CPU была == 100%, драйвер COM-порта, работающий на высоком уровне привилегий, всё равно успевал бы всё выгребать. Тем более на такой низкой скорости. Тем более, что и загрузка CPU никакая.

Я делал так: в потоке приёма создавал на куче пакет, собирал его, проверял валидность, потом отправлял главному окну указатель на этот пакет при помощи PustMessage(). Главный поток обрабатывал пакет и удалял его.

Хмм... А очередь сообщений, связанная с окном и её обработка тредом окна гарантирует, что сообщения из этой очереди будут обрабатываться в том же порядке, в котором они постились в очередь? Тем более если постинг идёт из разных тредов?
Я бы на это не рассчитывал.
Да и вроде в случае межпоточной передачи сообщений, PostMessage аналогичен SendMessage-у.

В 7 похоже, есть баг в COM драйвере. Многие программы, нормально работавшие с XP, глючат с ком-портами на 7. Единственное, что надежно под ней работает -USB-COM адаптер, причем с FTDI чипом.

Моя программа, написанная много лет назад под WinXP, сейчас работает одновременно с 3-я компортами на Win8, каждый - на скорости 921600 бод (отладочные потоки 3-х устройств). Сейчас это COM-порты - на PCI-карте, раньше были - на USB-UART-ах (FTDI и CP210x), а также - комбинации того и другого.
До этого всё так же работало на Win10 на другом компе. Работает это целыми днями.
Так что проблема 99.9% не в виндовых дровах. А как всегда - в кривых руках написателей этих "многих программ".
Проблемы возникают только с PL230x на высоких скоростях. На всех опробованных виндах. Вот тут явно дело в дровах Prolific.

[AHTOXA]

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

Да, гарантирует:

With the exception of the WM_PAINT message, the WM_TIMER message, and the WM_QUIT message, the system always posts messages at the end of a message queue. This ensures that a window receives its input messages in the proper first in, first out (FIFO) sequence.

Тем более если постинг идёт из разных тредов?

Без разницы.

Я бы на это не рассчитывал.

А здесь не надо гадать, надо просто читать документацию.

Да и вроде в случае межпоточной передачи сообщений, PostMessage аналогичен SendMessage-у.

Нет.

ЗЫ. Совершенно очевидно, что вы не разбираетесь в теме ©.

[jcxz]

Да, гарантирует:
А здесь не надо гадать, надо просто читать документацию.

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

Нет.
ЗЫ. Совершенно очевидно, что вы не разбираетесь в теме ©.

Да ладно! А если внимательнее прочитать описание WinAPI?

Я делал так: в потоке приёма создавал на куче пакет, собирал его, проверял валидность, потом отправлял главному окну указатель на этот пакет при помощи PustMessage().

А если надо отправить сообщение не главному окну? Или у Вас всегда приложения только с одним окном?

[AHTOXA]

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

Читать лень, а пофлудить - не лень? Не в произвольном, а FIFO.
Если вы отправляете сообщения WM_MY_DATA, то они будут извлекаться в том порядке, в котором были отправлены.

Да ладно! А если внимательнее прочитать описание WinAPI?

Если почитаете, то, может, немного начнёте разбираться. Но я сомневаюсь и в этом.

А если надо отправить сообщение не главному окну? Или у Вас всегда приложения только с одним окном?

Без разницы, какому окну. Любому.

[jcxz]

Если вы отправляете сообщения WM_MY_DATA, то они будут извлекаться в том порядке, в котором были отправлены.

А если другое не WM_MY_DATA?

Если почитаете, то, может, немного начнёте разбираться. Но я сомневаюсь и в этом.

Мне его за Вас читать недосуг. Я то прекрасно знаю, что если исходный тред не имеет окна и связанной с ним обработки очереди сообщений
(а так скорее всего и есть, так как треду, читающему байты из потока COM-порта, окно не нужно), то работа SendMessage() и PostMessage() похожа.
Но я сильно сомневаюсь, что Вам это чем-то поможет. Вы это не читайте, а то вдруг ещё поумнеете!

Без разницы, какому окну. Любому.

Ну да, так и думал - представления о работе WinAPI и взаимодействии окон, тредов, сообщений Вы не имеете.
Отсюда начинаем думать, что будет если отправите этому "любому" окну ваши сообщения с указателями на буферы, а это окно получит WM_CLOSE (либо будет закрыто иным образом) и обработает его раньше?
Будет утечка памяти. Что и является обычным явлением в "прогах" написанных подобными Вам деятелями.

Вы не забывайте, что у ТС не микроконтроллер, а вполне взрослая ПС. Все кольцевые буфера уже сделаны в ядре ОС, зачем ему еще один у себя?

Затем, что обработка кадра - это не сферический конь в вакууме. Для её работы нужна как правило инфа, находящаяся в контролах управляющего окна.
Так что гораздо удобнее работать с этой инфой в пределах одного треда.
И зачем тогда выносить работу с кадрами в другой тред и поиметь кучу проблем с межпотоковым взаимодействием?
И я не говорю, что "нельзя". Я говорю, что "обычно удобнее" делать это в потоке управляющего окна. А уже байтики принимать/передавать в других тредах.

Но это уже клинические случаи

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

Это почему вдруг? Обоснуйте

Это чревато утечками памяти. И другими чудесами. См. выше - уже обосновал.

[V_G]

Мне его за Вас читать недосуг. Я то прекрасно знаю, что если исходный тред не имеет окна и связанной с ним обработки очереди сообщений (а так скорее всего и есть, так как треду, читающему байты из потока COM-порта, окно не нужно), то работа SendMessage() и PostMessage() похожа.

Неправда ваша. Поток, не имеющий окна и принимающий данные с com-порта, использует функцию PostMessage() окну, дескриптор которого имеется. Здесь никакого криминала, PostMessage возвращается сразу же после того, как поместит сообщение в очередь.
А вот функция SendMessage() из потока, не имеющего цикла обработки сообщений, является проблемной, т.к. должна дожидаться квитанции (ответного сообщения).
Это теоретические рассуждения, на практике (а я тоже использую PostMessage) программа с SendMessage для передачи сообщений из функции приема данных по com-поту не работает, проверено.

[jcxz]

А вот функция SendMessage() из потока, не имеющего цикла обработки сообщений, является проблемной, т.к. должна дожидаться квитанции (ответного сообщения).

Вот здесь неправда ваша. Никаких сообщений "в ответ" SendMessage не ждёт. Прочитайте MSDN.

Это теоретические рассуждения

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

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

Вам повезло. Мне приходилось разрабатывать устройства, умеющие работать по нескольким протоколам. Причём даже одновременно в некоторых случаях. И переключаться между ними без перезагрузки. Ну и сервисное ПО приходилось писать для них.

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

Я вот не пойму - а в чём плюс-то такого разделения? Зачем нужно выделять пакеты именно в одном треде, а обрабатывать в другом (где находится вся нужная инфа для этого)? Какой от этого выигрыш? Почему Вы так за это топите???
Минусов я уже кучу перечислил, а плюсы где???
Если нет плюсов, а только минусы (пускай даже по вашему не очень важные), то зачем так делать????

[XVR]

Я вот не пойму - а в чём плюс-то такого разделения? Зачем нужно выделять пакеты именно в одном треде, а обрабатывать в другом (где находится вся нужная инфа для этого)? Какой от этого выигрыш?

Плюс в том, что для накопления целого пакета нужен 1 буфер, размером с максимальный пакет. Может быть (если очень повезет с алгоритмом нарезки пакетов) то даже не понадобится буфер для чтения собственно данных - их можно будет принимать прямо в буфер пакета (но это если очень повезет)
В любом случае нужно 1/2 буфера фиксированной длинны.
Результат такого приема можно отправлять в обрабатывающую нить в виде уже готовых пакетов в буферах фиксированной длинны. Это позволит реализовать своё управление памятью, гораздо более эффективное (и безопасное), чем malloc с сотоварищами.

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

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

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

Конечно это все будет работать если можно легко разделить пакеты и у них есть разумный предел по размеру.

Почему Вы так за это топите???

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

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

Сочувствую

[AlexRayne]

Я вот не пойму - а в чём плюс-то такого разделения? Зачем нужно выделять пакеты именно в одном треде, а обрабатывать в другом (где находится вся нужная инфа для этого)? Какой от этого выигрыш?

выигрыша может и не быть. перефразируя ХВР - ориентироавться надо на простоту. как проще так и делать. и надо учитывать учитывать в это "проще" обработку ошибок и латентность и межпроцессное взаиможействие.
для меня основным критерием выступает то что главная нитка - которая обрабатывает пакеты протокола, если она более менее умная, оказывается нагруженой и завязаной на синхронизацию с другими нитками. тоесть банально может блокироваться на чемто и приемник потеряет данные. Если Ваша нитка завязана у ГУЙ - это верный вариант того что на эту нитку не стоит завязывать задачи реалтайма. (это вроде какраз ваш случай)
если такой опасности нету - то тогда нет проблем обрабатывать прием в главной нитке.

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

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

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

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