Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба ... В чем разница? Только в том, что из-за своей ненормированной паузы Вы еще совсем потеряли битовую синхронизацию. Синхронизация, после сбоя и так будет потеряна с большой вероятностью. Я вам об этом уже устал твердить. И основной вопрос как ее достоверно восстановить. Если это делать по паузе - то получается более или менее надежно. И чем больше запрашиваемая пауза, тем лучше с этой точки зрения. Длительная пауза есть некоторая гарантия того, что временные помехи на линии прекратились, и можно начинать работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Синхронизация, после сбоя и так будет потеряна с большой вероятностью. Я вам об этом уже устал твердить. А сделать паузу в "твержении" и НАКОНЕЦ подумать? Чем отличается искаженный бит в середине байта от всплеска в середине или конце Вашей байтовой паузы? Я бы сказал, что Вы получите ложный старт и худший вариант :(, нежели битый бит. Ну а в случае искажения стартового бита, что в лоб, что по лбу хоть для байта, хоть для Вашей волшебной паузы. Длительная пауза есть некоторая гарантия того, что временные помехи на линии прекратились, и можно начинать работать. Ну очень хочется самого себя обмануть? :( Вы с помехами договорились :), чтобы непосредственно перед началом байта помех не было? Если не договорились, то никаких гарантий :(, даже "некоторых" нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба А сделать паузу в "твержении" и НАКОНЕЦ подумать? Может и Вы, наконец, подумаете и отойдете от Вашей теории одиночных ошибок? "Битыми" могут стать и биты, и байты и, целые группы байтов, и паузы в том числе... В среднем, нужно закладываться на такую ситуацию, как типичную, а не на одиночные ошибки. Или Вы с помехами договорились? :) Ну очень хочется самого себя обмануть? Вы с помехами договорились , чтобы непосредственно перед началом байта помех не было? Если не договорились, то никаких гарантий , даже "некоторых" нет. Гарантий никогда нет. Есть высокая вероятность, что помехи прекратились, если есть длинная пауза. И разница в том, что "битая" пауза - это уже не пауза. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Может и Вы, наконец, подумаете и отойдете от Вашей теории одиночных ошибок. "Битыми" могут стать и биты, и байты и, целые группы байтов, и паузы в том числе... В среднем, нужно закладываться на такую ситуацию, как типичную, а не на одиночные ошибки. Или Вы с помехами договорились. :) Ля-ля-ля... продолжаете себя обманывать? Ну и как борьбе с ошибками ДАЖЕ ОДИНОЧНЫМИ помогает волшебная пауза? Никак? Ну а массовыми сбоями - еще хреновее. Есть высокая вероятность, что помехи прекратились :) Утомили, ей богу своими фантазиями. И разница в том, что "битая" пауза - это уже не пауза. ;) Ага это не пауза, это, повторяю, ложный старт гарантированно сбивающий байтовую синхронизацию, в отличии от битого бита в теле байта, который с точки зрения сбоя байтовой синхронизации совершенно безобиден. Все я, честное слово, утомился :(. Написано много, и имеющий разум, да поймет, стоит-ли бездумно уповать на паузы, надеяться на удачные помехи, стучать в бубен..... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Ну и как борьбе с ошибками ДАЖЕ ОДИНОЧНЫМИ помогает волшебная пауза? Никак? Ну а массовыми сбоями - еще хреновее. Повторять сначала? :) Утомили, ей богу своими фантазиями. Взаимно. Ага это не пауза, это, повторяю, ложный старт гарантированно сбивающий байтовую синхронизацию, в отличии от битого бита в теле байта, который с точки зрения сбоя байтовой синхронизации совершенно безобиден. Понятно, упорно стоим на своем - рассматриваем только одиночные ошибки... Почему-то возможный ложный старт после сбойного байта Вас не смущает, а вот во время паузы... .. Написано много, и имеющий разум, да поймет... ... и сделает правильные выводы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Почему-то возможный ложный старт после сбойного байта Вас не смущает, а вот во время паузы... Последний раз. Ложный старт возможен только если в предыдущем байте был сбит стартовый бит. Только, раз Вы так любите рассуждать вероятности, то даже одиночный сбойный бит собьет байтовую синхронизацию в паузе со 100% вероятностью, а при посылке байта, только если попадет на ПЕРВЫЙ из 11-12 битов посылки. Вот такие дела, смеющийся без причины Вы наш. Это действительно было последнее разъяснение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Ложный старт возможен только если в предыдущем байте был сбит стартовый бит. Только, раз Вы так любите рассуждать вероятности, то даже одиночный сбойный бит собьет байтовую синхронизацию в паузе со 100% вероятностью, а при посылке байта, только если попадет на ПЕРВЫЙ из 11-12 битов посылки. Можно и в последний. Вероятность ложного старта даже при одиночной ошибке, грубо - порядка 10%. А поскольку одиночные ошибки - лишь один из возможных видов ошибок - вероятность ложного старта будет еще выше. Можете сюда добавить еще вероятность появления сбоев в паузах между байтами, так как при асинхронной передаче байты не всегда, и не обязательно, следуют друг за другом без пауз... Если Вы взялись рассуждать о вероятностях... Возникновение же ложного старта в межфреймовой паузе, просто сделает эту паузу не действительной, и принятый ложный байт будет отброшен... Это действительно было последнее разъяснение. Аналогично. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 10 марта, 2010 Опубликовано 10 марта, 2010 · Жалоба Понятно, упорно стоим на своем - рассматриваем только одиночные ошибки... А на кой их, пардон, рассматривать? Если не используются коды с исправлением ошибок, то рассмотрение "количественного" содержания ошибок в пакете данных бессмысленно - пакет либо валидный, либо нет. И если не приняты маркеры начала или конца - пакет недействительный, и если к моменту чтения и подсчета CRC взведен флаг ошибки - пакет недействительный. И всем пофигу, сколько там помех проскочило и с какими статистическими характеристиками: неверный пакет - повторить передачу. Хоть до второго пришествия. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 23 11 марта, 2010 Опубликовано 11 марта, 2010 · Жалоба Всего хорошо в меру. Под каждую задачу - свой метод. Если мы принимаем очередную фотку с Вояджера, то переспросы бессмыслены и там надо избыточной кодирование с исправлением ошибок. Если мы обмениваемся с устройством на столе или даже в пределах цеха , то там обмен идет четко разграниченными лигическими блоками (запрос ответ). И по любому подозрению на ошибку просто бракуем или запрос или ответ . С этим справляется обычная контрольная сумма в конце. Дополнительно вводить паритеты при этом - полная чушь. Причем вводить их требую протоколы. Пока мы являемся хозяевами положения и пишем свою прогу в контроллере на С - мы все определим, как только встает какая ОС - приплыли - еле еле удается выковырять эту информацию от операционки. На практике ошибки все же ходят парами. И то что мы на стендах видим и то что глазками - как то этежем ниже велись сварочные работы - обмену - конец. Грозоотметчик Попова в действии. Реально нам бед больше принесло использование коллегами вставки в RS232 сегмента из локальной сети. Вот круче диверсии никто еще не делал. А по теме топика - ну только в отдельном потоке ReadFile крутить ожидая приема 1 байта и каждый раз смотреть ошибку (это чтобы конкретно поймать где ошибка паритета). Подозреваю что до 2400 , ну 4800 будет работать, а дальше вопрос. Ну и "не могу молчать" :) про предложения обмениваться через USB - чушь полнейшая. Но, это уже коллеги , собственно, отметили. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 12 марта, 2010 Опубликовано 12 марта, 2010 · Жалоба Ну а если подумать о том, какое количество софта, с каким количеством ошибок и какой зависимостью от окружения требуется для облуживания USB? Нужен, например, отладочный интерфейс - при вылете системы через USB стек Вы почти наверняка вообще ничего не увидите. UART, как минималистичная штучка будет востребован еще очень и очень долго. С USB всё не так страшно. Клавиатуры (HID) и флешки (MassStorage) без проблем работают с любым железом и любой ОС. Вот их то (HID+MassStorage) я и использую для связи с компом. А во время отладки, но не в изделии, конечно можно использовать UART, но житаг то получше будет. Хотя, ИМХО и без того и другого вполне успешно можно обходится. А синхронизацию в UART лучше всего не по паузе восстанавливать, а именно по передаче 2-х FF-ов в непрерывном потоке данных. Т.к. в этом случае безошибочный приём FF-а (второго) с весьма высокой вероятностью свидетельствует о восстановлении синхронизации - если помеха 0-й создаст сразу видно. Немного протокол подправить, чтобы пакет с синхронизирующего FF-а начинался и всё. Тогда если этот FF и следующие за ним байты приняты без ошибок, то можно считать, что новый пакет не испорчен. Но на компе при работе через родной драйвер так не сделаешь - ошибки в кучу сливаются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 23 12 марта, 2010 Опубликовано 12 марта, 2010 · Жалоба Не-а. В modbus rtu никаких своих чудес вставлять нельзя в протокол (вставить можно но толку от этого никакого , наоборот еще больше ждать надо будет). Можно только в символьный. Так что, именно пауза, так скажем в 10 интервалов передачи байта на данной скорости, прочищает мозги принимающему UARTU. А лучше еще побольше - это уже чтобы протокольная прога поняла, что больше ей ничего не придет. В промышленности нигде и никогда USB не использовался и не будет использоваться (ну только иногда в контексте - сунул - скачал - ушел). Со всеми приборами обмен идет по последовательным каналам с реализацией или умощненного RS232 или RS485. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 12 марта, 2010 Опубликовано 12 марта, 2010 · Жалоба А во время отладки, но не в изделии, конечно можно использовать UART, но житаг то получше будет. Вот именно для отладки и именно в изделии, и именно на объекте UART и надо использовать. А JTAG (подключение+железо+драйвера+офигенный софт)в этих условиях гарантированно идет лесом. Ну и "не могу молчать" про предложения обмениваться через USB - чушь полнейшая. Это просто значит, что Ваш кругозор крайне ограничен. Утверждать о не применимости USB, CAN ...., а только знакомого Вам "485 со товарищами" есть просто недалекость. А синхронизацию в UART лучше всего.... А еще пофантазировать? А в бубен, постучать? Шаманы рекомендуют..... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 23 13 марта, 2010 Опубликовано 13 марта, 2010 · Жалоба Это просто значит, что Ваш кругозор крайне ограничен. Утверждать о не применимости USB, CAN ...., а только знакомого Вам "485 со товарищами" есть просто недалекость. Ну ка ну ка. Расскажите: где там в промышленности USB используется, а то может мы не знаем и паримся зря? А CAN я бы с USB вообще не стал в одну кучу валить. Вот обязательно (иногда на первой же странице иногда к третьей) всплывает кто то с USB. И начинается пурга полная. Причем ясно что человек делал какую то настольную поделку и начинается выдача этого за наше всё. Настоятельно рекомендую сходить в любую котельную хотя бы и посмотреть (если он там вообще есть) как делается обмен с приборами. Или зайти на сайт хотя бы прософта или КотрАвт или Теплоприбора или Метрана или Элемера и посмотреть как делается обмен с приборами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 13 марта, 2010 Опубликовано 13 марта, 2010 · Жалоба А синхронизацию в UART лучше всего Равноправные варианты пакетной синхронизации: 1. При 9-битах (не к этой теме, по все же) - прием байта адреса (бит9=1) 2. Посылка BREAK, прочищающего мозги всем и откидывающего на дефолтные настройки 3. По модбасовски - тайм-аут между посылками 4. Преамбула 0х55 (одновременно и автонастройка скорости, кто может) 5. Любой символ, считающийся признаком начала пакета с разруливанием двойного толкования этого символа (эскейп-последовательности). 6. Самосинхронизация за счет длины пакета и контрольной сигнатуры - например, длина пакета не более 10байт, сигнатура, как в далласах(onewire) - пожалста, приняли байт, отсчитали от него назад контрольную сумму в окне, не более длины пакета, если совпало с принятым байтом - пакет принят. Все это так или иначе делал. Сказать, что какой-нить из методов (особенно спорный №6) - полный ацтой - не скажу. Номер шесть тоже вполне ничего. Не-а. В modbus rtu никаких своих чудес вставлять нельзя в протокол (вставить можно но толку от этого никакого , наоборот еще больше ждать надо будет). Можно только в символьный. Так что, именно пауза, так скажем в 10 интервалов передачи байта на данной скорости, прочищает мозги принимающему UARTU. А лучше еще побольше - это уже чтобы протокольная прога поняла, что больше ей ничего не придет. Есть минимально различимые паузы. Если девайсы вместе с программистом, их воспитавшим, курят траву, то это не модбас. В случае необходимости в устройстве заводится регистр, содержащий значение минимально допустимого тайм-аута для данного девайса, если он уж совсем тормозной. Т.е. если ему что-то отстучали, и он не принял, то более того, что прежде прочитано из регистра, ждать нет смысла. Правда, это мимо стандарта, регистр может находиться на каком угодно адресе... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 13 марта, 2010 Опубликовано 13 марта, 2010 · Жалоба Ну ка ну ка. Расскажите: где там в промышленности USB используется, а то может мы не знаем и паримся зря? А CAN я бы с USB вообще не стал в одну кучу валить. Ну утешили :) хотя-бы CAN, как я понял, "использовать в промышленности" Вы разрешили. А USB это совершенно обыденный интерфейс к PC, в том числе массово используемый для тех-же CAN адаптеров. Не говоря уже о десктопных измерительных приборах. Вот обязательно (иногда на первой же странице иногда к третьей) всплывает кто то с USB. И начинается пурга полная. Да я вижу, какую пургу Вы дежурно понесли :( Настоятельно рекомендую сходить в любую котельную У меня встречное предложение - вылезайте Вы из этой котельной, оглянитесь - за ее пределами тоже есть жизнь и промышленность! И место для USB. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться