Цикл в цикле

[IvanLis]

И где у меня наблюдается побитовое чтение и склейка, что то Вы не так поняли.

Исходники Ваши, конкретно этого примера, я не видел и не знаю как это реализовано.
Сделал выводы опираясь на представленное Вами описание алгоритма:

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

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

[Jakob Brontfeyn]

Почитайте внимательно. Слово производная в кавычках
Вот этот этот алгоритм
http://www.labviewportal.org/viewtopic. ... 850#p65830

[Borjomy_1]

Соглашусь с IvanLis, для ASCII сообщений достаточно начального байта и терминального, для приема произвольных посылок неизвестного размера. А производители коммуникационного оборудования ТЕМ БОЛЕЕ придерживаются стандартов, когда я говорил про бить по рукам и рублем, я имел в виду доморощенных изобретателей, в мыслях не было, что вы имели в виду оборудование, которое можно считать промышленным стандартом. И если вы не увидели у ADAMа терминального байта в протоколе обмена, вы ПРОСТО НЕВНИМАТЕЛЬНО читали документацию. Поэтому, если НЕМНОГО подумать, то для надежного чтения ASCII посылки достаточно правильно сконфигурировать "VISA Configure Serial Port" и делать один-единственный вызов "VISA Read" , указав ему в длине максимально возможную длину строки (это тоже можно найти в описании протокола).

[dadreamer]

для надежного чтения ASCII посылки достаточно правильно сконфигурировать "VISA Configure Serial Port" и делать один-единственный вызов "VISA Read" , указав ему в длине максимально возможную длину строки

А как быть, если передаются рандомные бинарные данные (например, файл), где терминатор может встретиться произвольно, и не раз?
Соглашусь, что для большинства устройств терминатор обеспечивает свою работу. Однако, если взять двунаправленный обмен абсолютно любых данных, то терминатор может не помочь. Например, обмен сообщениями по COM-порту (типа, аськи): пользователь может ввести и отправить хоть какие данные, можно, конечно, запретить ему это делать и указать на некоторый протокол связи (алфавит). Но в случае с бинарным обменом я не вижу других вариантов, кроме "извращений", о которых писал IvanLis.

[Borjomy_1]

Jakob Brontfeyn, Зачем вводить в заблуждение неопытных пользователей, демонстрируя явно более сложный и грешащий потенциальными ошибками алгоритм? Тем более у другого может не оказаться лишних 50мс. Что делать, если данные непрерывно идут?

[Borjomy_1]

dadreamer,

А как быть, если передаются рандомные бинарные данные (например, файл), где терминатор может встретиться произвольно, и не раз?

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

[dadreamer]

Borjomy_1, глупый вопрос, может, но если VISA настроена на терминатор, а читаем фиксированное число байт и вдруг встретился "левый" терминатор, то будет считано всё количество байт или только то, что до терминатора? Сам бы проверил, но сейчас нет возможности.

Например,
[заголовок (длина и т.п.)][посылка...левый_терминатор...посылка][терминатор посылки + CRC]

[Jakob Brontfeyn]

Коллеги, давайте не делать скоропалительных выводов, каждое мое решение выстрадано на собственной шкуре и проверено временем, конкретно с 2000 года с ЛВ4.1, Пентиум-100 и далее по нарастающей.
Завязка только лишь на один терминальныхй символ не очень хорошая идея, в условиях реальной работы, электрических и человеческих помех.
Кроме того, я ведь ничего своим алгоритмом не отменяю, а лишь дополняю.
1. установил длина посылки не меняется и не нуль считал из буфера (если нуль постоянно, выход по таймауту)
2. проверка посылки на полноценность: есть признак начала и конца? равна ли длина типичной ожидаемой длине?
3. принятие решения по неполноценной посылке, например: забраковать на 100% и оставить значения из предыдущей посылки,
установить алармные значения после 3 раз или что другое сделать, и так далее.

[Borjomy_1]

Jakob Brontfeyn, Терминальный символ ПРЕКРАСНО работает в условиях эксплуатации. Если вы принимаете терминальный символ через раз, все остальное теряет всякий смысл. Потому что в таком случае никакой гарантии, что вы приняли корректную посылку нет, даже если терминальный символ был принят. И тем более ваш метод НИКОИМ ОБРАЗОМ не защищает от электрических и человеческих помех. Он их МАСКИРУЕТ. Вы никогда не узнаете, что витую пару надо менять, а будете грешить на измерительную аппаратуру и получать некорректные данные. И только потому, что не захотели следовать стандартам.
В реальной жизни БОЛЬШАЯ РОСКОШЬ игнорировать битые посылки. Если вы имеете нестабильный прием, то надо качеством связи заниматься, а не выдумывать коррекции. Приходят битые посылки - снижайте скорость обмена. Все остальное - закапывание головы в песок.

[Borjomy_1]

Borjomy_1, глупый вопрос, может, но если VISA настроена на терминатор, а читаем фиксированное число байт и вдруг встретился "левый" терминатор, то будет считано всё количество байт или только то, что до терминатора? Сам бы проверил, но сейчас нет возможности.

Например,
[заголовок (длина и т.п.)][посылка...левый_терминатор...посылка][терминатор посылки + CRC]

Если принимают бинарные данные, то терминатор надо отключать.
То, что вы заказываете при "VISA Read" - это максимальная длина посылки до достижения терминатора и таймаута. Смотря на то, что случится раньше (закончится свободное место в буфере, примется терминальный символ, либо наступит таймаут). Если терминатор отключен, то остается свободное место в буфере и таймаут.
ASCII формат подразумевают, что ни при каких обстоятельствах терминальный символ не может появиться в теле посылки.

[dadreamer]

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

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

Это вроде и понятно, и в то же время в ASCII-таблице присутствуют стандартные терминаторы , что вызывает недоумение (0xA = Line Feed)
http://www.asciitable.com/

[Borjomy_1]

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

[Jakob Brontfeyn]

Borjomy_1
Мне странно то, что у человека с Вашей квалификацией и опытом, какой то вдруг проскакивает агрессивный юношеский максимализм.
Ситуации бывают очень разные.
Последнее время при работе с устройством длина посылки которого мне точно известна и работающего жестко по запросу, я применяю упрощенныи метод. Послал запрос, жду определенное время, которое с 10 % запасом определяю из времени нахождения байтов посылки в канале(по длине в битах 10 бит на байт в канале), скорости обмена и времени реакции опрашиваемого устройства, которое практически не меняется. После этого читаю количество символов в буфере.
Если оно равно ожидаемой длине, читаем буфер, все получается в одну иттерацию.
повторы черезвычайно редки, специально контролировал, практически отсутствуют.
.
Солдаты в горячих точках тоже сматывают липкой лентой два рожка для автомата вместе, хотя армейские "стандарты" делать этого не разрешают. Нет чтобы на оружейном заводе сразу сделать какую нибудь быстросьемную систему на застежках механических или из сильных магнитов.

[Pavel Krivozubov]

Да, коллеги, согласен с Яковом, давайте снизим градус.
Не всегда бывает, что удаётся четко следовать "букве закона" и кодить по всем правилам.
У меня тоже бывали случаи, когда проект нужно было сдавать срочно, документации не было, и приходилось пользоваться реверс-инженирингом и использовать всякие прослушки порта для определения формата посылок. Потом проект сдавался и его просто физически невозможно было уже переделать по правилам, под наплывом новых проектов. Если условия позволяют и проект работает, то нельзя говорить что это ОДНОЗНАЧНО неправильный способ. Это просто альтернативный способ, может быть более простой и наколенный, однако и он тоже имеет право на существование, поскольку работает.

[Borjomy_1]

Ситуации не бывают разные. Ситуации (особенно в промавтоматизации) сводятся к ограниченному количеству решений, этому способствует стандартизация протоколов со стороны производителей устройств. И это говорит мой опыт, чем дальше, тем яснее становится, что решения подобного рода идут от непонимания общих принципов построения протоколов обмена. И идет поиск частных решений. Но при любом изменении характеристик частное решение перестает работать. Увеличилась частота посылок (при изменении спецификации на устройство, модернизации) - и с замененным таким-же, но новым модулем система перестает работать. Сделали и сделали. Это на вашей совести. Но советовать другим частное решение, даже без указания, ГДЕ и НА КАКОМ ОБОРУДОВАНИИ вы это применяли - оказывать медвежью услугу.