Цикл в цикле

[Borjomy_1]

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

[IvanLis]

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

В этом случае, как уже сказали, можно использовать непересекающиеся алфавиты.
Сообщение --> Кодирование --> Передача --> Декодирование --> Сообщение
Например и в почтовых серверах и мессенджерах (ICQ, Jabber) передается сообщение в системе Base64.

Что касается проверки "качества" посылки, для этого на разных уровнях ЭМВОС используются различные механизмы.
Начиная от бита "контроля четности", о котором забыли, а он тоже настраивается в VISA и поддерживается на физическом уровне.
И заканчивая упомянутыми CRC.

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

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

Да, коллеги, согласен с Яковом, давайте снизим градус.

Сам Яков легких путей не ищет, и это его личная точка зрения.
Например если взять тему: http://labviewportal.org/viewtopic.php?f=87&t=6938
С самого начала предлагалось организовать асинхронную запись используя буфер FIFO. Вместо этого было проведено научное исследование с набором и анализом статистики и т.д. и т.п.....

У меня иногда складывается мнение, что Якову платят за трудозатраты (человеко/час) или объем кода, но ни как не результат

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

[Andrew Lunev]

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

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

[Jakob Brontfeyn]

Что то мы опять переходим на личности, употребляя иногда не совсем коректные выражения типа "костыль". и "кривое решение".
А что касается тулкита, так он изваестен стал кроме форума также и здесь:
http://sine.ni.com/cs/app/doc/p/id/cs-15827#
http://www.etz.de/3557-0-SPS-Funktionen ... ieren.html

[dadreamer]

ххх: на чём пишешь фронтенд?
yyy: на костылях и велосипедах
ххх: ммм, хороший фреймворк!

[Andrew Lunev]

Что то мы опять переходим на личности, употребляя иногда не совсем корректные выражения типа "костыль". и "кривое решение".

Яков, толерантность не мой конёк. Что чувствую, то и говорю. Я и негра называю негром, а не афроамериканцем. Как выразиться менее резко, но так же доступно, я не знаю. Опять же, это форум, а не официальная рецензия на научную работу... Если я напишу вместо "кривое решение" - "недостаточно прямое решение" от этого станет легче?

Я с вами лично не знаком, и все мои наезды не на вас, как человека, а как эксперта по Labview и измерениям. Это не ругань, это скорее научная дискуссия. Мне ваши методы не понятны и я их не принимаю. При этом я понимаю, что кому-то они могут помочь и кто-то может иметь другое мнение. Я здесь высказываю только свое личное мнение, но оно совпадает на 100% с мнениями других экспертов в этой ветке. Если метод придуман и описан, как стандарт, то сначала надо попробовать его, а не придумывать свой стандарт и предлагать его другим. Вот если стандартный не работает, то уже надо думать, как выходить из ситуации.

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

[Vitekkz88]

Andrew Lunev
...Он до сих пор во все темы сует свой тулкит для новичков...Жалко просто людей...

Я когда это читал - кушал печеньку и молоком запивал. От смеха запачкал монитор...протираю теперь
А по вопросу: вон, dadreamer написал уже достаточно разумное решение. Вести приём и передачу в разных потоках либо по предложению Borjomy_1 отправлять команду и заказывать данные в размере N байт для приёма - ещё проще в реализации.
Ответы даны.
А "разбор полётов" с Яковым имеет смысл перенести в отдельную тему. А еще лучше - закрыть, а то как дети щас начнёте "у кого больше" и "кто старше".
Яков, слова "костыль" и "кривое решение" в мире программирования и программистов не являются переходом на личности. Не оскорбляйтесь.

[Jakob Brontfeyn]

Я рад, что Вы посмеялись, говорят смех удлиняет жизнь.
Мне тоже смешно, не только от того, что посягают на свободу творчества, и свободу выбора путей достижения цели, тем более, что вели успешно достигнуты, а я бы даже уже сказал в каком то смысле и на свободу слова. Типа, уже идет речь о том, что можно предлагать участникам форума, а что нельзя. Довольно странно то, что участники, высокая квалификация которых не вызывает сомнений, не увидели главного достоинства моего метода анализа только количества принятых байтов (или его "первой производной") не читая буфер, апотом считывая его только один раз, а не самих этих байтов в поисках терминального символа, который может исказится или его может вообще не быть в протоколе, но ведь для этого надо все время читать буфер, как это делает элемент VISA внутри себя в каких циклах я не знаю или, наверное, при приходе каждого нового байта, он тянет при этом компьютерное время и с этим ничего не сделаешь, внутрь ему не залезешь, надо делать параллельные циклы
А я то, ведь время не тяну. Ситуация аналогична той, что если, например, надо задержать время скажем на 1000 мс, то заурядный программист поставит просто элемент задержки на вход подаст 1000, а не заурядный сделает 10 циклов с тактом в 100 мс и будет там выполнять, что то другое, пока буфер наполняется, параллельные циклы не нужны.
второе
Почему они не понимают, что вероятность потери байта в канале с умеренными помехами значительно ниже вероятности искажения байта, и практически это нуль, сколько байтов передали столько их и придет, иначе действительно надо уменьшать
скорость или искать другой канал.
Короче, имел я в виду такие стандарты, у меня свой стандарт, а 1 августа был "Юбилей" 15 лет на немецкой инженерной работе на одной фирме.

[IvanLis]

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

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

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

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

[Jakob Brontfeyn]

Вот начало моего сообщения:

Как то раз, я успешно применил такую методу...
...............................................................
по моему все совершенно политкоррекно, никакого давления на кого либо нет.

смотрите текст полностью здесь:
http://www.labviewportal.org/viewtopic. ... 250#p65830

[Borjomy_1]

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

Может, вы не понимаете, как работает вообще система?... Никакие параллельные циклы делать не нужно. Поток, который ожидает необходимого числа байт, просто приостанавливается до наступления события. Благодаря чему могут выполняться другие потоки. Цикл (While Loop, For Loop), в котором производится чтение внутри исполняется как stream.
Вы же предлагаете внутри этого потока создать еще один поток (цикл), который ТОЧНО ТАКЖЕ будет приостанавливаться до наступления определенного события, в данном случае - это выполнение задержки. Мало этого, производится вызов функции, который производит нагрузку на процессор, параллельно приему данных в буфер VISA. От того, что вы читаете число принятых байтов в буфере, нагрузка на систему НЕ УМЕНЬШАЕТСЯ, а только увеличивается- данные все равно кладутся в буфер, потом вы все равно вычитываете их вызовом функции. Но даже не это самое некрасивое в этом решении. Самое некрасивое это то, что при частоте обмена 115200 время поступления одного байта составляет 0.1мс, а таймер, которым вы синхронизуете цикл - не может быть менее 1мс. Таким образом программа В ПРИНЦИПЕ не способна достичь максимальной скорости обмена и максимально быстрой реакции на прием посылки.
Что касается ошибок в передаче данных, то В ПЕРВУЮ ОЧЕРЕДЬ смотрят исполнение линии связи и ее соответствие спецификации на устройства. Ошибок в линии быть не должно. Если они присутствуют, то борятся с ними совершенно другими методами. Если вы изобретаете велосипед, делайте это потихоньку.
У нас, например, устройство, находящееся в отвратительной электромагнитной обстановке, грязи, высокой температуре и вибрации, отсылает данные на максимальной скорости 115200 (непрерывно, за секунду 21байт х 500 посылок/с) без ошибок. С расстояния 30 метров+. Как вы думаете, вашим алгоритмом мы смогли-бы это принять?

[Jakob Brontfeyn]

Ох.... Платон ты мне друг, но истина мне дороже. Давайте устанавливать истину, может я чего то действительно не понимаю, для того и форум.
1. В самом начале я писал что интервал между посылками, как правило, несколько десятков милисекунд, поэтому принимать 500 посылок в секунду я изначально не собирался. С этим вопросом ясно.
2. Тут более сложно, пусть подключаются знатоки, возможно мои познания в компьютерной технике безнадежно устарели.
Если я Вас верно понял, и нагрузки на процессор до прихода "терминатора" нет, то это значит, что элемент VISA так может запрограмировать микросхему управления компортом UART, что она будет выставлять компьютеру прерывание сама анализируя байты в своем буфере и найдя там байт "терминатора"?
Или может она анализирует только количество пришедших байтов и тоже выставляет прерывание компьютеру при достижении заданного.
На сколько знаю я, UART не такая умная, то есть VISA с ней работает все таки побайтово?
На всякий случай вот один из моих вариантов для случая приема спонтанных посылок переменной длины

[dadreamer]

элемент VISA так может запрограмировать микросхему управления компортом UART, что она будет выставлять компьютеру прерывание сама

VISA - это только лишь враппер WinAPI и ничего более того, что способен сделать арсенал Windows (Linux и Mac в данном случае не рассматриваем).

[Borjomy_1]

1. В самом начале я писал что интервал между посылками, как правило,
несколько десятков милисекунд, поэтому принимать 500 посылок в секунду
я изначально не собирался. С этим вопросом ясно.

Но вы-то советуете его также для отличной от вашей ситуации.

UARTы разные. Есть такие, у которых скорость до 920 кбит/с, а есть и выше. И драйвера для всех разные.

[Borjomy_1]

VISA - это только лишь враппер WinAPI и ничего более того

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