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

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

[AlexRayne]

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

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

Что Вы называете "приемом по прерыванию"?
У выни свои прекрасные дрова для КОМ, и даже целый специальный апи в ядро встроен под устройства Comm - модемы проще. все известные мне либы в борланде являются прокладкой к этому стандартному АПИ. напрямую с прерыванием никто не работает.
проблем с потерями не было, хотя обмен бывал интенсивный - мегабод.
можно посоветовать покрутить :
1)объем буфферов кома (я делал 8кб)
2)приоритет нитки приемника сделать выше нормального
3)если у вас между пакетами есть пауза более 1мс, настроить ее в свойствах таймингов кома. в запросах асинхронного чтения возможно оно поможет АПИ возвращать целиком пакет а не куски случайно презанные.
4)какая может быть гарантия что порт вашего ПК видит ваш поток без потерь, даже если ваш снифер прекрасен? Вы в качестве снифера тот же самый ПК используете?
5) можно поставить прокси с журналированием на ком (я пользовал com0project, но их вроде множество разных), и уже к нему подключать вашу программу. в этом случае вы сможете сравнить поток принятый прокси с потоком принятым вашей софтиной.
6) вы журналировали поток считанный из порта, сравнить его с финальными нарезанными пакетами? точно эти байты не считываются из порта?

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

[neiver]

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

[AlexRayne]

Начинать надо с того, что COM порт вообще и его реализация в Windows в частности, не гарантирует безошибочной передачи данных.
То есть рассчитывать на это нельзя, и контроль и/или обеспечение целостности данных надо реализовывать в протоколе обмена. Поврежненный пакед должен отбрасываться и если нужно передаваться повторно.

Парень сборется с другой проблемой - у него не пропадание сигнала на линии (этим он займется видимо позже, когда жареный петух клюнет), а пропадание байтов прямо на порте. можно это списать на особенности железа, но вероятность невелика

[Ruslan1]

AlexRayne, большое спасибо за конструктивный ответ с кучей хороших идей!
Что именно Вы имеете в виде когда говорите про "прекрасные дрова для КОМ, и даже целый специальный апи в ядро встроен под устройства Comm"? Что именно советуете почитать-посмотреть, может даже применительно к простоте прикручивания в Билдер?
Я раньше работал по поллингу, и задачи другие были. А сейчас решил по прерываниям сделать, нашел понятное мне описание в интернете(ссылка в моем письме)- по нему и сделал.

Если уже есть компонент а или просто апишная функция "брать все байты из порта и кидать в большой пользовательский кольцевой буфер" - было бы замечательно. В пятом Билдере ставил пакет TurboPower Async Professional, но использовал по поллингу. Сейчас на новый (хихи) 6-й билдер перешел и думал без сторонних компонентов обойтись.

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

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

[Lagman]

Что Вы называете "приемом по прерыванию"?
У выни свои прекрасные дрова для КОМ, и даже целый специальный апи в ядро встроен под устройства Comm - модемы проще. все известные мне либы в борланде являются прокладкой к этому стандартному АПИ. напрямую с прерыванием никто не работает.

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

[sonycman]

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

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

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

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

[rx3apf]

1. Дурацкий вопрос - а порты вообще с FIFO ? И оно включено ?

2. Как вариант, запустить какую-нибудь терминалку, залоггировать, а потом посмотреть - потери есть ?

[Raven]

Если Wind'а иногда не успевает выгребать данные из аппаратного буфера, может стоит подумать в сторону аппаратного управления потоком (RTS/CTS)?

[DS]

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

[ViKo]

Я пересылал в комп пакеты данных на скорости 115200, сбоев не замечал. Формат был 8N2. Вот его и посоветую попробовать.

[V_G]

Я пересылал в комп пакеты данных на скорости 115200, сбоев не замечал. Формат был 8N2. Вот его и посоветую попробовать.

Да я тоже много чего пересылал, и на 480 кБод, и без сбоев. Насколько я понял, особенность проблем ТС в том, что данные идут постоянно, что в моей практике не встречается.
Хотя я Билдер не пользую, пишу в MSVC++ с отдельным потоком на прием и WaitCommEvent в том потоке с ивентом по каждому пришедшему байту...

[ViKo]

Возможно, фантазирую, детально не вникал, полагаю, если стопов 2 или 1,5 то синхронизироваться по следующему старту можно точнее. Будет больше запаса на неравенство тактовых частот. А также увеличивается время для работы процессора.

[AlexRayne]

AlexRayne, большое спасибо за конструктивный ответ с кучей хороших идей!
Что именно Вы имеете в виде когда говорите про "прекрасные дрова для КОМ, и даже целый специальный апи в ядро встроен под устройства Comm"? Что именно советуете почитать-посмотреть, может даже применительно к простоте прикручивания в Билдер?

Вот это именно и имел ввиду - что вы путаете всех использованием слова "драйвер". В венде уже написаны дрова под множество материнок и уж тем более под известные стандартные контроллеры УАРТ. Вот они как раз напрямую с железом и прерыванием работают. писать их не требуется - они готовы и встроены в Ось. Овь прелагает довольно простое стандартное АПИ для работы с Сомм портами. Если вы поставили борланд - покурите их хелпы Win32 SDK или чтото вроде этого. Это огромный хелп по всем ресурсам венды. и в частности там описан и Comm интерфейс. Если вы полезете в изходники АсинкПро - то наглядно увидите как вендовые вызовы используются. АсинкПро - это обертка вендовых вызовов.
Когда я говорю "прекрасные" - значит они есть работают, отлажены, и проверены. (и удобны)

AlexRayne, большое спасибо за конструктивный ответ с кучей хороших идей!

Если уже есть компонент а или просто апишная функция "брать все байты из порта и кидать в большой пользовательский кольцевой буфер" - было бы замечательно. В пятом Билдере ставил пакет TurboPower Async Professional, но использовал по поллингу. Сейчас на новый (хихи) 6-й билдер перешел и думал без сторонних компонентов обойтись.

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

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

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

Вам уже посоветовали использовать 1,5-2 стопбита. это хорошее предложение, если оно конечно возможно для ваших абонентов.

С адаптерами КОМ-УСБ советую не играться если есть нормальный порт на матери или PCI плате ввода вывода. Я встретил кривой адаптер от МОХи, народ жаловался на ФТДИ - у обоих проблемы с буфером приемника на больших трафиках.

[V_G]

Кстати, о больших трафиках. Так ли они необходимы?
Очень много встречал профессиональных программистов, которые для своего личного удобства используют большие скорости и постоянно кидают в порт повторяющиеся данные (типа проверки связи и информации "я живой"). Причем в ситуациях, когда достаточно скорости 9600 и работы по принципу "запрос-ответ". А потом еще переносят эти принципы на радиоканал и забивают все вокруг.
Может, все-таки сначала подумать о минимизации трафика?

[Ruslan1]

Я пересылал в комп пакеты данных на скорости 115200, сбоев не замечал. Формат был 8N2. Вот его и посоветую попробовать.

Какое количество байтов в сутки? что такое "сбоев не замечал"? Их не было? Или может быть были, но их никто не логгировал? И, ключевой вопрос- чем принимали (какой софт)?
К сожалению, 8N1.5 или 8N2 не подходит. Как и не подходит "снизить скорость до [тут вставить желаемое]".

[ViKo]

Я не сутками пересылал, а кадрами. По ним - обработка. Количество байтов на стороне передачи и на стороне приема совпадало. К результатам обработки тоже не в претензии.
Принимал и терминальной программой HTerm и Матлабом.

[@Ark]

Вероятная причина, все-таки, несовпадение тактовых частот - ошибка более 1%.
Если есть возможность, стоит посмотреть какая тактовая там реально получается в устройстве для скорости 115200.

---
P.S. Кстати, порт компьютера тоже стоит проверить, на всякий случай.
Передавайте в него непрерывный поток нулей на 115200 и посмотрите реальную скорость на выходе.


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

[Ruslan1]

Вот это именно и имел ввиду - что вы путаете всех использованием слова "драйвер".

Хм. Обычно я стараюсь следить за тем что говорю и не "путать" людей. Например я ни разу нигде не упоминал слово "Драйвер". Я также дал ссылку на то на базе чего писал софт. И в том документе тоже их программа ни разу нигде не названа драйвером.

В венде уже написаны дрова под множество материнок и уж тем более под известные стандартные контроллеры УАРТ. Вот они как раз напрямую с железом и прерыванием работают. писать их не требуется - они готовы и встроены в Ось. Овь прелагает довольно простое стандартное АПИ для работы с Сомм портами. Если вы поставили борланд - покурите их хелпы Win32 SDK или чтото вроде этого. Это огромный хелп по всем ресурсам венды. и в частности там описан и Comm интерфейс. Если вы полезете в изходники АсинкПро - то наглядно увидите как вендовые вызовы используются. АсинкПро - это обертка вендовых вызовов.

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

Я понимаю, что "АсинкПро - это обертка вендовых вызовов", я не знаю каких. Поэтому и спросил, что именно вызывать-то и как это использовать чтобы побороть потерю байтов.
Спасибо, буду читать про Comm.

Вам уже посоветовали использовать 1,5-2 стопбита. это хорошее предложение, если оно конечно возможно для ваших абонентов.

Это не предложение а костыль. Чтобы его применить- нужны аргументы и пояснения, почему "8N1" теряет байты, а вот "8N2" - уже "хорошее предложение". То есть у Винды (или у моего FIFO в железе) есть глюк, полное исправление которого возможно удлинением времени передачи байта на 1 бит?

С адаптерами КОМ-УСБ советую не играться если есть нормальный порт на матери или PCI плате ввода вывода. Я встретил кривой адаптер от МОХи, народ жаловался на ФТДИ - у обоих проблемы с буфером приемника на больших трафиках.

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

Кстати да, просто опять поставить АсинкПро и попробовать из-под него тоже неплохая идея- вряд ли я сделаю общение с виндовыми апи лучше чем они.
Или есть что-то еще уровня Асинк Про для стареньких билдеров?

[XVR]

У стандартного аппаратного СОМ порта есть внутренний буфер, как правило размером 15 байт. Это не тот буфер, который задается в SetupComm. Если драйвер порта по каким-то причинам не успеет прочитать этот буфер, то принятые байты теряются, о чем извещают соответствующие флаги возвращаемые ClearCommError.

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

2 ТС - покажите код вашего потока чтения. И настройки при открытии порта. Сто процентов бага где то там

[ViKo]

Посмотрел, сколько стопов использую, оказалось, 1. Раньше было 2. Работает безупречно. Длина передаваемого кадра (непрерывного пакета) до 16 кБ.

[Ruslan1]

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

2 ТС - покажите код вашего потока чтения. И настройки при открытии порта. Сто процентов бага где то там

Винда не загружена больше ничем, только самой собой . Из приложений- еще AVG крутится и Тимвьювер в режиме ожидания входящего соединения. И загрузка CPU 10-20%, обычно меньше.
Я тоже думаю что бага у меня, текст привожу ниже. Текст сильно укороченный, но всю работу с портом оставил как есть.
 Ruslan1_serial_port_reading_20170523.txt ( 12.62 килобайт ) Кол-во скачиваний: 51
(это сишный файл)
Проблема- уже в моем кольцевом буфере байтов не хватает.

[krux]

Вероятная причина, все-таки, несовпадение тактовых частот - ошибка более 1%.
Если есть возможность, стоит посмотреть какая тактовая там реально получается в устройстве для скорости 115200.

---
P.S. Кстати, порт компьютера тоже стоит проверить, на всякий случай.
Передавайте в него непрерывный поток нулей на 115200 и посмотрите реальную скорость на выходе.

считаю, что расхождение частот компового железа создать таких проблем не может.
Стандарты на ком-порт растут ногами из ITU-T на телеграф лохматых годов, поэтому приемник обязан принимать всё, что отличается по частоте на +- 20%.
Само собой все реализации UART начиная 16550, и заканчивая современными FTDI - им соответствуют. (Хотя за все китайские клоны переходников USB -UART ручаться не могу.)

[Ruslan1]

Посмотрел, сколько стопов использую, оказалось, 1. Раньше было 2. Работает безупречно. Длина передаваемого кадра (непрерывного пакета) до 16 кБ.

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

[@Ark]

считаю, что расхождение частот компового железа создать таких проблем не может...

Вы пишите очевидные вещи - так как должно быть. Я же предлагаю ТС проверить, что есть в реальности.
Особенно это касается внешнего устройства. Частоты для UART там обычно получаются делением основной тактовой частоты.
Она далеко не всегда достаточно точно делиться на 115200. Ошибку более 1% можно легко получить, если не смотреть за этим.

... приемник обязан принимать всё, что отличается по частоте на +- 20%.

Это не верно.
Чтобы гарантированно без ошибок принимать непрерывный проток - разность частот должна быть не более 1% (по многолетнему опыту).
Все, что выше - с вероятностью сбоев. Тем выше, чем больше разность частот. Разброс 2% - это уже очень плохо, 5% - как правило не работает ничего.

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

[V_G]

Я тоже думаю что бага у меня, текст привожу ниже. Текст сильно укороченный, но всю работу с портом оставил как есть.
 Ruslan1_serial_port_reading_20170523.txt ( 12.62 килобайт ) Кол-во скачиваний: 51
(это сишный файл)

1. Не видно, где организуется поток для ввода (CreateThread). Я обычно это делаю в функции открытия главного окна приложения. Если сомневаюсь, открываю поток с приоритетом ABOVE_NORMAL, но чаще всего - с нормальным приоритетом
2. После WaitCommEvent не вызываю WaitForSingleObject: вообще не знаю, что это за функция, как-то обхожусь, хотя тоже задействую структуры OVERLAPPED. В остальном обработка похожая
Дома исходников нет, завтра посмотрю на работе: когда-то давал студентам-дипломникам шаблонные советы по организации обмена по com-порту

[XVR]

Вызов Synchronize(RxDataProcessing); из нити чтения COM порта тормозит эту самую нить до тех пор, пока RxDataProcessing не вернется. Видимо это может быть долго и байт другой может потеряться.
Более того, совершенно непонятно почему у вас эта самая RxDataProcessing вызывается как из главной формы (по таймеру), так и из COM нити - это явно неправильно.
Далее, при вызове RxDataProcessing из main потока она у вас читает и модифицирует переменные, которые используются в COM потоке (RxBuff.wrpnt) - это совершенно недопустимо.
В общем вам надо переработать схему передачи прочтенных данных между нитями.

Далее, конструкция if (RxBuff.wrpnt >= RX_RINGBUFF_SIZE) RxBuff.wrpnt = 0; не должна срабатывать никогда. Это переполнение приемного буфера. Надо бы ее отследить и показать пользователю, а не тихо выбрасывать все, что накопилось


Далее, результат вызова ClearCommError надо бы проверить на ошибки.

Вызов ReadFile тоже было бы неплохо проверить на успешность (так, на всякий случай)

[AlexRayne]

Хм. Обычно я стараюсь следить за тем что говорю и не "путать" людей. Например я ни разу нигде не упоминал слово "Драйвер". Я также дал ссылку на то на базе чего писал софт. И в том документе тоже их программа ни разу нигде не названа драйвером.

Да действительно не используете. видимо слово "прерывание" меня в ступор ввело, и многочисленные упоминания как работает контроллер УАРТА. напрямую с контроллером ,кроме драйвера, ведь венда никому работать не даст.

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

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

Это не предложение а костыль. Чтобы его применить- нужны аргументы и пояснения, почему "8N1" теряет байты, а вот "8N2" - уже "хорошее предложение". То есть у Винды (или у моего FIFO в железе) есть глюк, полное исправление которого возможно удлинением времени передачи байта на 1 бит?

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

Кстати да, просто опять поставить АсинкПро и попробовать из-под него тоже неплохая идея- вряд ли я сделаю общение с виндовыми апи лучше чем они.
Или есть что-то еще уровня Асинк Про для стареньких билдеров?

работа с винапи будет не сложнее, У вас все нормально же написано. сделать сильно проще не получится.

Вызов Synchronize(RxDataProcessing); из нити чтения COM порта тормозит эту самую нить до тех пор, пока RxDataProcessing не вернется. Видимо это может быть долго и байт другой может потеряться.
Более того, совершенно непонятно почему у вас эта самая RxDataProcessing вызывается как из главной формы (по таймеру), так и из COM нити - это явно неправильно.
Далее, при вызове RxDataProcessing из main потока она у вас читает и модифицирует переменные, которые используются в COM потоке (RxBuff.wrpnt) - это совершенно недопустимо.
В общем вам надо переработать схему передачи прочтенных данных между нитями.

+1
Все еще хуже Synchronize тут использовать это жупел. он делает блокируеще исполнение RxDataProcessing в нитке VCL - когда все формочки перерисовываются. это тормоз который трудно описать.
используйте сигналы (Event) или семафоры чтобы передавать другой нитке ваш буфер.
да и обработку этого буфера лучше перенести сюда из нитки VCL , и отдавать уже гтовые распознаные и провереные пакеты.

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

[Ruslan1]

Большое спасибо всем за кучу отличных идей и советов, буду разбираться!

Спасибо за замечание про Synchronize, именно по озвученным причинам я этот метод и не использую (вначале использовал, но в процессе борьбы с теряющимися байтами перестал). Сильно извиняюсь что не удалил из текста неиспользуемые строки. Они там просто закомментарены в том исходнике который вы смотрите, и снабжены комментарием:

//the method is changed, just periodic polling in main task by a timer
// Synchronize(RxDataProcessing);

То есть эта нитка сама по себе и валит в глобальный буфер, не останавливаясь на этот Synchronize().

Вызов Synchronize(RxDataProcessing); из нити чтения COM порта тормозит эту самую нить до тех пор, пока RxDataProcessing не вернется. Видимо это может быть долго и байт другой может потеряться.

там "//" перед этим, есть строка не используется.

Далее, при вызове RxDataProcessing из main потока она у вас читает и модифицирует переменные, которые используются в COM потоке (RxBuff.wrpnt) - это совершенно недопустимо.

О!!
вот тут может и есть мой ошибк.
Я думал что достаточно их как volatile объявить и использовать.

В общем вам надо переработать схему передачи прочтенных данных между нитями.

дада, спасибо, буду думать. А как без Synchronize это сделать? неужто через глобальные переменные нельзя?
Просто скажите в каком направлении копать, я копать умею только где не знаю....
(Upd: извиняюсь, уже прочитал совет про евенты и семафоры, значит через них буду. Тогда уже сразу про очереди поищу, чтоб просто мессадж с новым указателем записи передать в ожидающую нитку- надеюсь оно тут есть где-то).

Далее, конструкция if (RxBuff.wrpnt >= RX_RINGBUFF_SIZE) RxBuff.wrpnt = 0; не должна срабатывать никогда. Это переполнение приемного буфера. Надо бы ее отследить и показать пользователю, а не тихо выбрасывать все, что накопилось

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

[XVR]

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

Далее, в нити приема нужно делать не кольцевой буфер, а прием пакета (например в массив). Потом полностью принятый пакет (нарезанный по его границе) внутри Synchronize копируется в AnsiString и засовывается в очередь (например в std::deque<AnsiString>). Извлечение из очереди делается по таймеру.

Этот подход хорош тем, что он весьма простой, и оставляет много возможностей для оптимизации (начиная от собственного менеджера памяти, что бы не тягать данные через AnsiString и кончая собственной асинхронной очередью без привлечения Synchronize)

У меня даже такая очередь есть (была сделана в качестве примера для лекций по программированию)

CODE

//---------------------------------------------------------------------------

#ifndef queueH
#define queueH
//---------------------------------------------------------------------------
#include <deque>

template<class Item>
class WQueue {
std::deque<Item> queue;

CRITICAL_SECTION cs;
HANDLE sema;
HANDLE not_emp_sig;

public:
WQueue(int max_size)
{
sema=CreateSemaphore(NULL,max_size,max_size,NULL);
not_emp_sig=CreateEvent(NULL,FALSE,FALSE,NULL);
InitializeCriticalSection(&cs);
}
~WQueue()
{
CloseHandle(sema);
CloseHandle(not_emp_sig);
DeleteCriticalSection(&cs);
}

void put(const Item& it)
{
WaitForSingleObject(sema,INFINITE);
EnterCriticalSection(&cs);
queue.push_back(it);
SetEvent(not_emp_sig);
LeaveCriticalSection(&cs);
}

Item get()
{
for(;;)
{
WaitForSingleObject(not_emp_sig,INFINITE);
EnterCriticalSection(&cs);
if (queue.empty())
{
LeaveCriticalSection(&cs);
continue;
}
Item rv=queue.front();
queue.pop_front();
if (!queue.empty()) SetEvent(not_emp_sig);
ReleaseSemaphore(sema,1,NULL);
LeaveCriticalSection(&cs);
return rv;
}
}

size_t get_cur_size()
{
EnterCriticalSection(&cs);
size_t rv=queue.size();
LeaveCriticalSection(&cs);
return rv;
}

};

#endif

Как раз от BCB6.0

Только семафор оттуда удалите - он был сделан для ограничения максимального размера очереди

[AlexRayne]

дада, спасибо, буду думать. А как без Synchronize это сделать? неужто через глобальные переменные нельзя?
Просто скажите в каком направлении копать, я копать умею только где не знаю....
(Upd: извиняюсь, уже прочитал совет про евенты и семафоры, значит через них буду. Тогда уже сразу про очереди поищу, чтоб просто мессадж с новым указателем записи передать в ожидающую нитку- надеюсь оно тут есть где-то).

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

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

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

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

[AHTOXA]

Добавлю в копилку способов передачи данных от потока приёма к основному потоку: PostMessage().
Эта функция помещает сообщение в очередь на обработку и тут же возвращает управление. А уж когда главный поток его заберёт и обработает - это его дело.
Я делал так: в потоке приёма создавал на куче пакет, собирал его, проверял валидность, потом отправлял главному окну указатель на этот пакет при помощи PustMessage(). Главный поток обрабатывал пакет и удалял его.
Всё очень просто, надёжно, никто никого не ждёт, и не надо париться с синхронизацией.

[AlexandrY]

Здравствуйте!
Есть Windows7 Pro, 32-bit, компьютер- китайский одноплатник на Intel 1037U, 4GB RAM.
СОМ-порты- 4 штуки прямо на материнке.
И есть внешний передатчик, посылающий в COM-порт пакеты.

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

Насколько вижу ни Intel 1037U ни его Platform Controller Hub (PCH) не имеют UART-ов.
Значит ваши UART-ы виртуальные через USB.
Я бы посмотрел что у вас еще на USB висит (камера, Wi-Fi...) и поотключал бы их жестким сносом драйверов из системы.

[AlexRayne]

Напишите хоть в чем выявился источник потерь

[Ruslan1]

Насколько вижу ни Intel 1037U ни его Platform Controller Hub (PCH) не имеют UART-ов.
Значит ваши UART-ы виртуальные через USB.
Я бы посмотрел что у вас еще на USB висит (камера, Wi-Fi...) и поотключал бы их жестким сносом драйверов из системы.

Спасибо, интересная идея, не подумал про такое.
Сериальные порты в BIOS Setup уже видны, или по этому признаку не определить через что оно работает? Есть какие-то низкоуровневые тестеры, чтоб подергали железо и сказали через какой чип оно работает и что еще на каком хабе сидит (если это USB)? Машинка используется вот такая. (кстати, эта модель очень понравилась по качеству исполнения)

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

[AlexRayne]

Спаисибо, интересная идея, не подумал про такое.
Сериальные порты в BIOS Setup уже видны, или по этому признаку не определить через что оно работает? Есть какие-то низкоуровневые тестеры, чтоб подергали железо и сказали через какой чип оно работает и что еще на каком хабе сидит (если это USB)? Машинка используется вот такая. (кстати, эта модель очень понравилась по качеству исполнения)

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

А в диспетчере устройств это хозяйство не разглядеть?

[Ruslan1]

Напишите хоть в чем выявился источник потерь

Я обязательно отпишусь как разберусь/не разберусь, пока руки не дошли, через день-два возьмусь. Приоритеты задач меняются на ходу...

[Timmy]

В коде меня удивляет использование overlapped WaitCommEvent(). Можно ли сразу вызывать WaitForSingleObject() и GetOverlappedResult(), не проверив по коду возврата WaitCommEvent() и GetLastError(), что WaitCommEvent() ушла в асинхронный режим, как это всегда делается в примерах от Микрософт?

[XVR]

WaitForSingleObject вызывать можно. Если WaitCommEvent не ушла в wait, то event останется в том состоянии, в котором был. А был он в установленом состоянии.
А вот GetOverlappedResult неизвестно - MSDN на этот счет молчит

[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.

[V_G]

WaitForSingleObject вызывать можно. Если WaitCommEvent не ушла в wait, то event останется в том состоянии, в котором был. А был он в установленом состоянии.
А вот GetOverlappedResult неизвестно - MSDN на этот счет молчит

У меня все работает нормально с WaitCommEvent и без WaitForSingleObject. Два подряд ожидания не есть хорошо: тут может быть потенциальная причина пропуска информации.
После того, как WaitCommEvent дождалась события, я просто делаю ResetEvent, проверяю код события, по EV_RXFLAG делаю обработку, по другим либо возвращаюсь к WaitCommEvent, либо закрываю порт (если в основном потоке устанавливаю специальный флаг, сигнализирующий о необходимости закрытия)

[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().

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

[rudy_b]

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

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

[jcxz]

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

Проблем нет никаких при грамотном построении алгоритма:
Принимающий тред пишет байты в кольцевой буфер. После каждого обновления содержимого буфера (или не после каждого, а при достижении некоего уровня + по таймауту) посылает нотификацию (оконным сообщением) треду, в котором находится управляющее окно. Управляющее окно, получив нотификацию, читает кольцевой буфер из приёмного треда.
Естественно - парсинг потока байт на пакеты и уж тем более - обработку пакетов, желательно делать уже в треде управляющего окна. Не надо смешивать уровни обработки протокола.
PS: И желательно, без реальной необходимости, избегать передачи указателей на блоки данных в куче между тредами. Как тут советуют некоторые товарищи....

[AHTOXA]

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

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

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

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

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

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

[XVR]

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

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

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

И лишние тоже вводить не надо. Нарезку на пакеты вполне можно делать там, где идет прием с порта. Это же не прямая дыра в железный порт, там еще ОС и куча драйверов по дороге.
Конечно, нарезку на пакеты надо делать только в том случае если она не зависит от содержимого пакетов и/или текущего глобального состояния. Но это уже клинические случаи

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

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

[V_G]

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

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

[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-поту не работает, проверено.

[XVR]

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

Ой. Вот это и есть 'клинический случай'

По Вашему - изменение например протокола обработки потока байт - это клинический случай?

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

Или изменение скажем каких-то параметров обработки потока (собственного адреса и т.п) - это клинический случай?

Нет, изменение адреса же не меняет формата пакета. Клинический случай это когда нарезка потока байтов на пакеты требует каких то знаний, не вытекающих непосредственно из самих байтов.
Например, если в пакете есть байт, отмечающий начало пакета (B1), конец пакета (B2), и эскейп байт (B3), которым заменяются B1/B2/B3 в потоке (B3 + 1/2/3), то такой пакет может (и должен быть) нарезан сразу в приемном потоке.
А если в пакете сначала идет байт, задающий его тип, а за ним структура, соотвествующая этому типу, то это и есть 'клиника'. Такое действительно лучше резать в основном потоке (а еще лучше такое не использовать)

Это чревато утечками памяти. И другими чудесами.

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

[jcxz]

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

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

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

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

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

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

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

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

[XVR]

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

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

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

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

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

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

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

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

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

Сочувствую

[AlexRayne]

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

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

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

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

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

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

[V_G]

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

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

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

Речь ведь об отсылающих тредах без окна?
Цитата из msdn, английским по белому: "The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed"
Так что если отсылающий тред без окна использует SendMessage, он периодически блокируется, хоть заотлаживайся.
Почему я говорю о практике: у Вас реально работает прием по com-порту с SendMessage из треда без окна?

[AHTOXA]

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

А мозг включить никак? Хорошо, отвечу: тоже FIFO. Но ведь вы вещали про то, что порядок пакетов с данными может перепутаться. И как же это может произойти, а?

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

Какая отборная чушь. И SendMessage и PostMessage работают совершенно независимо от того, имеет ли вызывающий тред окно. Вы бы перестали позориться, а?

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

Очередной перл. Вы что, даже не понимаете разницы между окном и оконной функцией? Ну это уже даже не смешно. Как можно быть настолько дилетантом, и при этом вещать с таким апломбом?

[jcxz]

Речь ведь об отсылающих тредах без окна?

да, конечно.

Цитата из msdn, английским по белому: "The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed"
Так что если отсылающий тред без окна использует SendMessage, он периодически блокируется, хоть заотлаживайся.

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

Почему я говорю о практике: у Вас реально работает прием по com-порту с SendMessage из треда без окна?

Я сейчас нахожусь за границей и поэтому посмотреть не могу, пишу по памяти. Как вернусь - тогда посмотрю.
Но просмотрел свои исходники пары проектов, где активно используются несколько тредов - вижу, что в проекте, в разных файлах множество вызовов SendMessage, и только в одном файле есть PostMessage. И в классе моём, который я написал давно для удобного запуска и управления тредами, я вижу, что там тоже SendMessage.

[Ruslan1]

Поздравляю всех с началом новой рабочей недели!
(хотя кто-то уже, наверное, и пиво пьет в тенечке...)

В-общем, проблема вроде бы не в методах межпоточного взаимодействия.
На данный момент ситуация такова:
Сниффер (Free device monitoring Studio от HHD) показывает те же самые проблемы как и моя программа - то есть он уже не видит те же байты, которые я не вижу.
Подключенный ко входу логический анализатор показывает что все байты корректно долетают до разъема DB9 на компьютере.
Сейчас тестирую на моем Dell D620- у него ком порт есть прямо внутри. И, кстати, ошибки ловит чаще чем 1037U, на котором штатно должно крутиться.

Подключил переходник Serial-USB (FTDI) и пустил через него. Разница есть.
Пока что один раз что-то словил, но это может быть и реальный шум. Прямой ком-порт уже бы раз 10 поймал за это время.

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

потери выглядят вот так. Сместил байты принятые сниффером, где пусто- это сниффер ничего не принимал.
(смещение в корректном пакете, время анализатора, корректный байт из логического анализатора, байт из сниффера)
это один пакет, 2 байта плюс 1 байт не приняты.

98 44.301759 0x3F 3f
99 44.301846 0x4D 4d
100 44.301933 0x0B 0b
101 44.30202 0xC1 c1
102 44.302107 0x40 40
103 44.302194 0x86
104 44.302281 0x36
105 44.302367 0xC1 c1
106 44.302454 0x40 40
107 44.302541 0x9B 9b
...
120 44.303671 0x52 52
121 44.303757 0xC1 c1
122 44.303844 0x3B
123 44.303931 0x28 28
124 44.304018 0xAC ac

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

[@Ark]

Ребята, ну нельзя же так уж совсем. Уже сколько раз вижу ситуации про чукчу, который ни разу ни читатель
Я уже говорил, что пробовал на разных компьютерах. Правда, всегда под Win7...

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

[Ruslan1]

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

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

[@Ark]

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

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

[AlexRayne]

потери выглядят вот так. Сместил байты принятые сниффером, где пусто- это сниффер ничего не принимал.
(смещение в корректном пакете, время анализатора, корректный байт из логического анализатора, байт из сниффера)
это один пакет, 2 байта плюс 1 байт не приняты.

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

[Ruslan1]

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

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

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

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

[@Ark]

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

[AlexRayne]

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

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

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

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

[Ruslan1]

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

тип процессора- 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 - не поменялось.

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

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

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

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

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

[ViKo]

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

[@Ark]

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

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

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

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

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

[Ruslan1]

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

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

[jcxz]

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

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

[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: а как красиво все начиналось, неправильно параметры между тредами передаю, эх, прям прослезиться тянет насколько зеленый был... Интересно, что я через неделю буду думать про сегодняшнее положение вещей...

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

[XVR]

Проблема локализована участком "на входном разъеме компьютера логический анализатор байты видит, а сниффер в компьютере уже не видит".

Вы в этом уверены? У вас потери были '10-20 байт в сутки'. Логическим анализатором тоже сутки смотрели?

[Ruslan1]

Вы в этом уверены? У вас потери были '10-20 байт в сутки'. Логическим анализатором тоже сутки смотрели?

(тяжело вздыхая) шутите, как можно быть хоть в чем-то полностью уверенным?

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

[rx3apf]

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

[XVR]

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

Этого достаточно.

Напишите сюда какие у вас уровни приходят на COM порт? (В вольтах). И какая реальная битовая скорость? (осцилографом померяйте и то и другое)

[rx3apf]

Ну при чем тут скорость и уровни ? Скорость не совпадает - искажаются символы. Уровни недостаточны (а найти приемник с отличным от примерно плюс полтора вольта порогом не проще, чем крокодила на лице) - опять же искажение принятого кода. А тут байт выпадает полностью.

[XVR]

Ну при чем тут скорость и уровни ? Скорость не совпадает - искажаются символы. Уровни недостаточны (а найти приемник с отличным от примерно плюс полтора вольта порогом не проще, чем крокодила на лице) - опять же искажение принятого кода. А тут байт выпадает полностью.

Разница в скорости может привести к framing error. Выглядеть это будет как пропадание байта. Раница в уровнях может привести к пропуску стартового бита (а возможно и остальных тоже), что может привести к framing error или к прямому выпаданию символа.

Есть какие нибудь другие предположения, что там может быть не так?

[rx3apf]

Ошибка кадра должна все ж обрабатываться и как-то индицироваться. А если еще и стоповый бит только один, то и дальше должны быть искажения. Что может "быть не так" - полагаю, все ж обработка на уровне системы. Если FIFO нет (или отключено) - запросто. А со скоростью намудрить четко на уровне FE, но без искажения содержимого - это надо исхитриться. Не, я не возражаю, что входной поток скопом или анализатором надо бы глянуть, но тут причина на 99% не в этом.