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

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

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

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


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


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


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

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

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

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

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

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


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

Сочувствую

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

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


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

Да, извиняюсь, неправильно выразился. 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 из треда без окна?

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

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

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

да, конечно.

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

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

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

В-общем, проблема вроде бы не в методах межпоточного взаимодействия.
На данный момент ситуация такова:
Сниффер (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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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