=AK=

В моем случае приемники ничего особенного не "ждут". Они реагируют на байты входного потока определенным образом, примерно так: - Eсли байт равен 0xF0, то очищают приемный буфер - Если байт равен ESC-символу 0x1B, то он выбрасывается, а на следующий за ним символ реакция такая: -- если второй байт равен 0х01, то в приемный буфер записывается символ 0x1B -- если второй байт равен 0х02, то в приемный буфер записывается символ 0xF0 -- если второй байт равен 0х03, то прием пакета (фрейма) заканчивается, проц начинает разбираться с содержимым приемного буфера - Если ничего из вышеописанного, то входной символ просто записывается в приемный буфер При передаче в самом пакете данных символы 0xF0 заменяются на пары 0x1B, 0х02, а символы 0x1B - на пары 0x1B, 0х01. Перед началом пакете передается пара символов 0xF0, 0xF0, а по окончании передачи пакета - пара 0x1B, 0х03. Делается по прерываниям и много процессорного времени не отнимает. Но приходится использовать два таймера.

Пауза перед началом пакета нужна не только для того, чтобы UARTы закончили прием мусора. Она еще служит сигналом сброса. В Мобасе в начале пакета выдерживается пауза 3.5 байт-интервалов. А в самом пакете пауза между байтами не должна превышать 1.5 байт-интервалов, если склероз не подводит.

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

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

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

Был еще один случай, когда я непосредственно столкнулся с недоумками, которые в RS-485 надеялись только на растяжки. Это была совместная разработка, их компания писала большую часть софта, в том числе - софт для связи по RS-485 центрального устройства домашней автоматизации и панели управления у входной двери, через которую взводилась и сбрасывалась секьюрити. Когда систему стали поставлять пользователям, пошли жалобы, что посреди ночи эти панели иногда начинали потихоньку пищать, что действовало на нервы. Как выяснилось, писк в них был заложен сознательно, они пищали в случае потери связи с центральным устройством. А весь самопальный протокол связи был построен только и исключительно в надежде на растяжки. Эти невежды никогда не слышали слова "Modbus", а мои объяснения отскакивали от этих придурков как от стенки горох. Однако пальчики тоже растопыривали веером.

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

В RS-485 есть одна-единственная линия связи - витая пара, к которой подключены приемопередатчики. Других линий нет. Помехоустойчивость же, повторяю, определяется мощностью помехи, наведенной на линию, при которой нарушается работоспособность, т.е. нормальный обмен информацией. Совсем на пальцах: наводим на линию белый шум, замеряем его мощность и смотрим, в какой момент времени начнутся потери информации при обмене или прием ложной информации. Вот это и будет численная характеристика помехоустойчивости. Соответственно, рассуждать о помехоустойчивости тогда, когда "передатчик молчит" или "к линии подключены только приемники" довольно глупо, поскольку при этом нет обмена информацией, так что речь может идти только o частном случае - о ложном приеме информации. А это несколько иная область, поскольку вероятность ложного приема в основном определяется свойствами CRC, защищающих пакеты данных. Только не говорите, ради бога, что CRC - это "сложно и ненужно", "требует огромных ресурсов", и что вы их принципиально не используете. :cranky:

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

С этим я не спорю. От самих растяжек в большинстве случаев вреда нет, более того, частенько они бывают полезны. Гораздо хуже то, что вследствие повсеместного их использования люди безграмотные и невежественные начинают воспринимать их наличие как обязательное и необходимое условие работы RS485.

Вы просто по неопытности пока не понимаете, что означает "более помехоустойчивая сеть". Более помехоустойчивой будет та сеть, которая будет сохранять работоспособность при более высоком уровне внешних помех. Количественно величина помехоустойчивости оценивается по величине мощности помехового сигнала (белого шума), при какой работотспособность интерфейса нарушается. Для RS485 количественную оценку проще всего производить по величине мощности помехи, уже наведенной в линию. Как видите, наличие или отсутствие "мусора" на свободной линии совершенно отсутствует в этом определении и относится к помехоустойчивости фиолетово. Все определяется именно работотспособностью. Правильно сконструированному интерфейсу совершенно безразлично наличие или отсутствие мусора на свободной линии, который вас так страшит. Тогда как в неграмотно сконструированном интерфейсе работотспособность определяется растяжками, а помехоустойчивость составляет величину, примерно в 100 раз меньшую, чем у правильно сконструированного интерфейса. Поскольку в правильно сконструированном интерфейсе для нарушения его работоспособности помеха должна пересилить не жалкую резисторную растяжку, а выход работающего передатчика RS485. И, соответственно, правильно сконструированному интерфейсу растяжки вообще говоря не нужны. Можно их поставить, можно убрать, можно растянуть в обратную сторону - для помехоустойчивости это не имеет ровно никакого значения. Краткое (но достаточно внятное для грамотных людей) описание одного из вариантов помехоустойчивого интерфейса (протокола) я привел в посте #28 на этой ветке. Для не совсем грамотных можно добавить, что передатчик должен оставаться постоянно включенным в течении всего фрейма, т.е. его нельзя выключать где-то в середине фрейма а затем включать снова. При реализации на RS485 описанный протокол как раз и обеспечит в сто раз большую помехоустойчивость, чем ламерское фуфло, которому нужны растяжки.

Самопальные сети RS-485, работоспособность которых зависит от наличия растяжек, имеют помехоустойчивость примерно в 100 раз меньше чем те, которым растяжка не нужна и которые способны безошибочно работать с непрерывным потоком на входе. Я с таким доморощенным поделием, которое работало только при наличии растяжек, столкнулся как-то лет 15 назад. На столе в лаборатории все работало, а вот когда поставили на портовый кран в Китае - стало дико глючить. Автор поделия мотался в командировки в Китай, все уменьшал резисторы подтяжек и заменял кабели на экранированные. Но надежной работы так и не добился, а дотумкать, отчего его система глючит, так и не смог, несмотря на мои подсказки. С тех пор еще несколько раз встречался с аналогичным убожеством, плодом инженерного недоумия.

Я делаю так. Поток разбит на фреймы, символ 0xF0 обнуляет текущий буфер приема и явлется началом фрейма. Последовательная передача двух 0xF0 подряд обеспечивает битовую синхронизацию (т.е прочистку UART) и прочистку буфера приема. После этого фрейм принимается без ошибок. Внутри фрейма символы 0xF0 заменяются Esc-последовательностью из двух байт (байт-стаффинг). Непрерывный поток всегда идет, например, по радиоканалу - когда передатчик не работает, то приемник все равно ловит эфир. Для RS485 непрерывный поток появляется, когда кабель проложен в месте, где много помех. Протокол, который не способен работать в условиях непрерывного потока на входе UART - это радиолюбительское убожество.

Даже если есть фантомная запитка интерфейсной стороны Vdd2, то, согласно даташиту на ADM2486, при отсутствии питания на стороне проца Vdd1 драйвер обязан быть выключен. Тут что-то другое. Над посмотреть осциллом сигналы DE. Или светодиодики на них навесить. И еще притянуть резисторами к земле входы RTS на всякий случай. Поскольку ADM2486 живет пока Vdd1 не упадет ниже 1 В, а при этом питании проц уже не работает.

в лучшем случае, т е. максимум. Чаще - оно живет гораздо меньше. Странно, что такие вещи приходится пояснять.

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

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

Ну а вам забыли привести полный список узлов, на который этот ток может оказывать влияние. Поэтому вы находитесь в блаженной уверенности, что "решаются эти проблемы относительно просто". Мне лично достаточно того, что хоть не гарантируется работа хоть какого-то узла. Будь это АЦП, компаратор, Brown-out Detector, RTCC или PLL, гадать на сей счет и экономить гроши за счет внешних диодов - в ущерб надежности - я и сам не буду, и другим не стану советовать.

Роль встроенных диодов на входе МК состоит в том, чтобы во время транспортировки и хранения МК предотвратить пробой затворов входных MOSFET транзисторов. Они отнюдь не предназначены для того, чтобы защищать входы МК от чего бы то ни было в рабочем режиме. Если в рабочем режиме через эти диоды протекает заметный ток, то этот ток может вызвать срабатывание паразитной тиристорной структуры, которую данные диоды образуют вкупе с остальными транзисторами МК. Срабатывание этого паразитного тиристора приводит к катастрофическим последствиям: МК "закорачивает" питание через себя, после чего МК может просто сгореть, если шина питания способна обеспечить достаточно большой ток. При малых токах питания МК не сгорает, однако утрачивает работоспособность, привести его в рабочее состояние можно только после выключения питания. Ранние ИС серьезно страдали от этого эффекта, они защелкивались от каждого кошкина бздеха. Впоследствии JEDEC ввело стандарты, согласно которым паразитный тиристор должен быть довольно нечувствительным. Стандарты требуют, чтобы паразитный тиристор не срабатывал, если через входны диоды защиты от статики протекает ток до 20 мА. Что происходит в тех случаях, когда в рабочем режиме черех эти диоды протекает ток менее 20 мА, изготовители ИС как правило вообще не оговаривают. Вместо этого они вводят в даташиты типовое требование, чтобы напряжение на любом входе не превышало напряжений земли и питания более чем на +-0.3 В. Понятно, что при соблюдении этого требования защитные диоды на входах МК просто не откроются. После настойчивых расспросов служб тексуппорта многих фирм, разным людям с трудом удавалось выдавить из них ответ на вопрос, какой величины ток через защитные диоды будет безопасен в рабочем режиме. Как правило ответ был такой: не более 0.5 мА, при превышении этого тока работоспособность МК не гарантируется. 0.5 мА - это очень мало, построить надежную защиту в расчете на такой ток довольно трудно. Если в схеме стоят внешние диоды, они безболезненно выдержат ток порядка 1 А, защита получится надежной. А резистор между входом МК и внешними диодами как раз и будет гарантировать, что через диоды защиты МК ни при каких обстоятельствах не будет протекать ток более 0.5 мА.

Несомненно, помогут. Причем, совершенно необязательно Шоттки. Обычные кремниевые диоды (например, BAV99) помогут ничуть не хуже. С диодам у вас пуленопробиваемая защита входа от каких угодно издевательств.

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

Согласен с ув. Microwatt в том, что ток через оптроны можно было бы несколько уменьшить для облегчения их режима - я бы выбрал 5-6 мА. А в остальном, на мой взгляд, все правильно. Защита достаточная, работать будет, помехоустойчивость должна получиться очень хорошая. Я бы, пожалуй, еще каждый фототранзистор зашунтировал бы керамическим кондерчиком примерно 10 нФ, поставленным неподалеку от него, чтобы наводки их не попортили.

Поставить микруху. Один копеешный гейт типа 74HCT в корпусе SC-70.

Судя по названиям сигналов, это самый обычный синхронный последовательный интерфейс: LVcc - питание (Lens Vcc) DGND - земля (Digital GrouND) RW1 - чтение/запись (Read/Write), скорей всего 1=чтение, 0=запись, но могут быть и другие варианты LCK - клок (Lens ClocK) LIO - двунаправленные данные (Lens Input/Output) Можно предположить, что мастер начинает обмен с того, что ставит низкий уровень на RW1 (т.е. задает режим записи) и потом выдает байт или два с командой и адресом. После этого, если команда записи, он продолжает удерживать RW1 в низком уровне и выдает один или несколько байт данных. А если команда чтения, то переводит RW1 в высокий уровень и читает один или несколько байт данных. Как-то так...

Измерения проводятся в линейном режиме, фототранзистор не находится в насыщении. Получить этот режим совсем не трудно - при заданном сопротивлении нагрузки RL выставляем напряжение питания Vcc = 2V + (RL * 2mA), а затем постепенно уменьшаем ток светодиода до тех пор, пока фототранзистор не выйдет из насыщения и напряжение коллектор-эмиттер станет равно 2V. После этого можно проводить измерение времянки, изменяя ток светодиода на некую очень малую величину. Однако большого практического смысла этот график не имеет, поскольку почти никто не работает с такими оптронами в линейном режиме. А в дискретном режиме времена tf и tr определяются в основном глубиной насыщения фототранзистора и в разы превышают то, что указано в даташитах. То есть, график показывает идеальный наилучший предельный случай. Для получения максимального быстродействия необходимо держать фототранзистор в неглубоком насыщении, как можно ближе к линейному режиму. Соответственно, все определяется разбросом параметра CTR - приходится ставить такой RL, чтобы транзистор находился в насыщении при даже минимальном CTR.