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

А этот "лом" или "костыль" в современном помещении, насыщенном наводками от 50Гц до я не знаю куда (неплохо выглядят 30-50кГц от электронных балластов, разных ионизаторов воздуха и т.п.) может сбить и прибор, запитанный от батарейки.

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

Хоть я и верю в особо убойные блоки, к которым "без валидола нельзя" - мне они просто не попадались.
При том, что на столе обычно стоит "первый попавшийся" блок питания.
Раньше - какой-нибудь 286-ой или "поиск" уже окончательно отжил своё и из него просто вымародёрен блок, так как никто не претендует на замену в нём мамки и получение в наследство его монитора.
Сейчас - взятый у того, кто на фирме за это дело отвечает ("если сейчас под рукой запасного нет, то как будешь заказывать компы - закажи для меня блок питания" - т.е. _я_ специально блоки не отбирал, брались из общего потока).

на БП пульсациии я мерял - 50мВ при частое 50Гц+многоКГц

Если комуто вдруг интересно будет(тк как в асме я не силен) ложу три сгенеренных компиляторами файла
linavr_new - gcc-4.3.0 + binutils-2.18 + libc-1.6
linavr_old - gcc-3.4.6 + binutils-2.15.92.0.2 + libc-1.4.6
winavr - gcc-4.1.2 + binutils-2.17 + libc-1.4.6

Измерял-правильное слово. И какое средство измерения Вы применяли? Выбросы на частоте нескольких мегагерц зафиксировали? Или школьный вольтметр не позволяет этого сделать?

Это что, игра найдите десять отличий? Я нашел одно в коде откомпилированном gcc-4.3.0 есть работа с ватшдогом в gcc-4.1.2 нет. Если код разный, то я не могу сказать что дело только в компиляторе. В следующий раз посылайте исходники.

Да еще. Компилируют проект с отключенной оптимизацией только те, кто не знает слова volatile.

Анатолий.

Нет конечно. А зачем?
Ни разу. Ни дома, ни работе.

Тот же самый USB-разъём взгляните как выглядит. Сначала идут контакты питания, а затем сигнальные. Та же песня и с PCMCI. Как Вы думаете, почему? А потому, что сначала уравниваются потенциалы внешнего устройства с компьютером, на периферию подается питание, сразу же выходы внешнего устройства переводятся в Z-состояние и только потом начинается "болтовня" периферейной платы с ПК.
Чуток OFF. С незаземленным компьютером проблема была один раз. Когда системный блок стоял рядом с батареей центрального отопления. На него запрыгнула кошка, которую только что "постирали". Какое же было её удивление, когда одна лапка была на системнике, а вторую она поставила на батарею.

Счастливец...Зайдите как-нибудь в любой сервисный центр компьютерной фирмы...

Блаженны верующие...

2Flasher

у вас плохой день? наехать охота?
Школьный вольтметр называется С1-76

2aesok

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

"Пгемного благодаген"... Спасибо за совет

а отличия есть. пример функции полученной новым

и старым

компиляторами

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

Автору темы, для решения вопроса, следует выложить принципиальную схему(если он конечно не против), хотя бы цепи питания от входного разъема до МК. С этого и начнём, дальше будет видно...

2Flasher, я действительно неправ с пунктуацией в первом посте -приношу извинения.

схема, софт?невопрос


чета в одном посте не добавилоНажмите для просмотра прикрепленного файла

Попробуй подключить к схеме аккумулятор или крону, решает вопрос о помехе в питании и погоняй девайс. А вообще в качестве стабилизатора, я бы использовал ШИМ + танталы по цепи питания.

Критика схемы:
Зачем нужно- пояснять не буду- хто знает- сам поймет.
1) МАХ232 - со стороны PC последовательно резисторы 100 Ом и кондеры 100пик между выходом и входом максимки.
2)С15 убрать, С13 уменьшить до 4,7мкф
3)Вход 12 вольт на кренку пустить через резистор пару ом. Параллельно входу кренки поставить что-то типа 1,5КЕ18А
4) вместо 6N137 можете еще глянуть в сторону H11L1
5) внешний супервизор- ну просто нах не нужен.
6) Набуя там hc245 - науке неизвестно...
Про все остальное- автор может в асю стукнуть при желании- поможем.

Хм... А сколько там, по-вашему, ДОЛЖНО БЫТЬ, в незаземленном варианте-то? И какое сопротивление было у мультиметра, котрым вы намеряли эти 110 В?



Некоторые моменты в схеме позволяют уверенно утверждать, что автор схемы не читал статью "Помехоустойчивые устройства"

Открываем схему любого компового блока питания. На входе между фазовым и нулевым проводом стоят на корпус(который должен подключаться к заземлению) конденсаторы 4700 *2kV. Для переменного тока частотой 50Гц эти конденсаторы имеют реактивное сопротивление = 1 / (2 * Pi * F * C) 670кОм.
Образуется делитель напряжения , со средней точкой на корпусе, если его не заземлить. Китайский мультиметр имеет входное сопротивление несколько Мом...дальше объяснять?


Насчет второго замечания- когда сможете изготовлять устройства с 4 группой жесткости по электромагнитной совместимости- обсудим тонкости за баночкой пива вместе

По схеме можно сказать одно, половину деталей можно смело выкинуть в результате хватит и 88меги, а вот то что необходимо на схеме не наблюдается. Особенно умиляют подтяжки на 485 - 47К, а так же транзистор. который и нафиг там не нужен, да и резисторы по SPI - 4,7К внушают уважение

Да. Пожалуйста, не останавливайтесь на полдороги. Недоговоренности могут привести к ошибкам.


Я дал ссылку на статью, которую, насколько я могу судить, автор схемы не читал, но которую ему, как мне кажется, полезно было бы прочесть. Объясните, каким таинственным образом моя рекомендация почитать статью связана с тем, прошли ли мои изделия испытания на 4 группу или нет? Пока что речь идет о том, что устройство и на 1 группу не тянет, поскольку зависает даже при очевидном отсутствии внешних помех.

Рекомендацию принял на свой счет Так что ссори, если что не так. Статья довольно жиденькая и многие ошибки она никак не поможет найти. Поэтому максимум- пару выводов автор может взять на будущее. здесь больше вопрос целесообразности схемотехнических решений.
Продолжу про БП. Корпус его во многих реализациях соединен с общим проводом выходных цепей, а уж если он находится в компьютере- то тем более соединен. Таким образом на устройстве присутствует потенциал половины сетевого напряжения относительно заземления и всего что не имеет этого потенциала. Ток КЗ между землей и корпусом 110В/680 Ком. -десятые доли миллиампера. Так что при касании устройства чем-то еще пойдет ток через схему либо до уравнивания потенциалов либо постоянно. Отчего схема, конечно , может обидется...

Подтяжки как подтяжки... Вы зато посмотрите на супернавороченный "терминатор"! При таком терминаторе (с высоким импедансом на постоянке) хватит и 47К.

Теперь насчет транзистора. Как я вижу, изолированное питание для RS-485-ой части ("+5Viso") схема получает отдельно, по одному кабелю с самой линией? Мы с таким сталкивались. Получается, при отрубании питания процессорной части с сохранением питания линии выход оптрона включения драйвера (в данной схеме "ISO2") в "неактивном" состоянии, т.е. транзистор оптрона закрыт, и если он напрямую подключен к DE драйвера RS-485, то подтяжка к "+5Viso" заставляет драйвер включаться на постоянную передачу.... Весь обмен на линии останавливается, объект стоит, электрики бегают, операторы матерятся, мастера смены пинают программистов... ...И все это из-за отсутствия инвертора между выходом оптрона и входом DE драйвера RS-485. Разработчики этой схемы, судя по наличию инвертора (в виде Q1) тоже с такой проблемой сталкивались . Другое дело, что "забыли" КРЕНку сделать на "+5Viso", а по линии подавать вольт 12, но это уже другие проблемы...

У нас, например, сделан в каждом модуле на питание RS-485 персональный DC/DC от основного питания всей схемы.

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

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

Какое напряжение вы ожидаете увидеть между землей и вторичной если возьмете обычный трансформатор 220В 50Гц? А если возьмете маломощный импульсный блок питания, тапример, так наз. "plug pack" (т.е. маломощный БП, совмещенный с сетевой вилкой)?


Как вы думаете, может ли "обидеться" схема, если вместо БП компьютера используется любой другой БП (конечно, при прочих равных, т.е. при отсутствии заземления)?


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

По поводу транзистора в 485 тута уже объяснили)) таки были проблемы с переходом в состояние передачи.
HC245 нужны для того чтобы они выгорали - их легче менять чем атмегу, плюс вместо них можно ставить улн2803.
Подтяжки на 485ом на 47к нужны чтобы при переходе всех модулей в режим приема линии не принимала нестабильных состояний.

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

По поводу оптрона - посмотрю, сенк.
Резисторы в цепи 232, угу я в курсе про них, но данные железяки используются в нестандартных местах... К примеру кабель с 232-м до следующего устройства может быть 5,7,15 метров.

Супервизор зачем? Я - параноик)


тоже так хотел, уже и накидал схемку, как вдруг:
Я: шеф пали какая железяка у нас терь будет!
Шеф: должно быть маленькое и дешевое!
Я: Ммм, ладно.

Прблема вот здесь (castet_switch_rs1.7ucom.linavr_new.lss):


При в ходе в обработчик прерывания сохраняються регистры r1, r0, SREG, r24, r29, r28. Дальше по коду идет вызов функции Inputs_Test, которая:

Изменяет регистры r31, r30, r24, r25.

Тоесть, обработчик прерываня сохраняет не все регистры которые в нем изменяються.

gcc-4.1.2 генерирует правильный код:


Прада зачем было нужно лесть с отверткой в кварц я не понял.

Анатолий.

Хм... Вы в курсе, что ULN2803 имеют выходы с открытым коллектором, т.е. ток нагрузки втекает в выходы, а то, что у вас нарисовано на выходе 245-х дает вытекающий ток? Странные у вас "замены".


Приемники RS485 всегда имеют петлю гистерезиса (т.е. являются триггерами Шмитта). Поэтому для них принципиально не существует "нестабильных состояний", их выход стабильно находится или в 0, или в 1.

Я догадываюсь, что говоря о "нестабильных состояниях" вы на самом деле имели ввиду "неопределенные состояния". Действительно, когда все приемопередатчики RS485 находятся в режиме приема, и разность напряжений между сигнальными линиями мала, на выходе любого приемника может быть как 0, так и 1, заранее сказать нельзя, что именно. При этом даже малая помеха, наведенная на линию связи, способна вызвать переключение и инициировать начало прииема ложного пакета данных. Для определенности и уменьшения влияния помех предпочтительно использовать приемопередатчики с так наз. failsafe фичей. Читайте аппноту TI Interface Circuits for TIA/EIA-485 (RS-485), там это подробно разобрано начиная со стр. 2-5. Обратите внимание на рекомендуемые номиналы резисторов подтяжки.

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

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

Подтяжки драйвера RS-485, кстати тоже неправильно сделаны. Линия A должна подтягиваться к "+", B - к общему ("-"), а не наоборот.

Имейте ввиду, что оптрон инвертирует сигнал.

Однако, даже если бы он не инвертировал. Объясните, почему, собственно, на входе UARTа вам хочется в паузах между пакетами видеть высокий уровень, а не низкий. Зачем?

L78M05 имеет небольшой выходной ток. Стоит подумать над необходимостью предохранителей F1, F2.
Они сработают при выходе из строя L78M05, но тогда достаточно одного на входе, да еще необходимо чем то ограничить напряжение на выходе стабилизатора, иначе в предохранителях уже не будет смысла. Зачем так поставлен F3? Защиту по входному питанию стоит поставить.
По зависаниям, если не менялась разводка, вряд ли кто поможет. Ищите отличия в платах, деталях.

Попробуйте все функции которые вызываються из прерываний объявить с атрибутом "always_inline"

Анатолий.

2aesok, МЕГАСЕНК. как думаете в мейллист команде гцц стоит написать об этом, или это ключами компилятора решается? Попробую совет.



управлять же можно разными железками. бывают такие которым нужен ТТЛ, есть такие которым нужен мощный выход ОК. в зависимости от этого используется та или иная ревизия. также ревизию с 245ми проще(почти только программно) перевести на 16входов(ЗЫ. встречалась правка ТЗ прямо на объекте).


протокол работает хорошо и ошибки отсеиваются без проблем. я просто перестраховываюсь(этим блокам 3года от роду)


есть на 1 ампер. Вылетает эта штука не сразу при достижении одного ампера.


при работе с улн он ограничивает ток нагрузки.


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


проблема найдена - разный код, сгенерированный разными компиляторами

нет не нужно, поздно уже писать.

Анатолий.

Анатолий,

А этот баг присутсвует в версии 4.2.2?

Нет, только в 4.3.0

Анатолий.

Чтобы при неактивном канале было НЕАКТИВНОЕ логическое состояние - чтобы не только активность в канале определялась без лишних вопросов, но и чтобы неактивный канал не вызывал разнотолков. Тем более если у Вас аппаратный УАРТ с определением состояния линии BREAK, то Вы на коне, а если программный - придётся натрудить не только мозолей на пальцах, но и места в памяти программ, которой не завсегда много, ну а если какой-нить простенький аппаратный УАРТ, то научиться обходить его типа "убогость" может оказаться сложнее, чем реализовать весь программно. Итого - использование определения сигнала линии BREAK избыточно и нецелесообразно в относительно простых программно-аппаратных решениях. Ну и далее - переход из BREAK в режим передачи должен сопровождаться выдерживанием передающим хостом некоего таймаута не менее 1-го байта или вариантов с заполнением канала некими символами (0xFF) перед непосредственно передачей, а последнее налагает некоторые ограничения на реализации протоколов.
IMNHO, при неактивном состоянии линии её удержание в состоянии логического нуля не просто нецелесообразно, но и неоправданно усложняет само использование канала.
IMHO линию нужно держать при неактивном состоянии в логической единице, что избавит всех от ненужных хлопот.
ЗЫ. Программы, у которых "срывает крышу" от всяких несуразиц в канале - на помойку, независимо от того, какой уровень в канале при неактивном состоянии.

Спасибо, успокоили.

В неактивном канале нужное вам состояние на входе UART-а обеспечивается подтягивающими резисторами. Предположим, вы поставили резисторы по 1к, т.е. один резистор тянет на +5, другой - на землю. Какой мощности должна быть наведенная помеха для того, чтобы на входе UART-а появился ложный "старт"? В первом приближении, помеха должна иметь можность 5В^2/2k=12.5 мВт (у автора топика с его 47к подтяжками будет еще меньше, но это не суть важно). После этого ваша софтинка примет помеховый сигнал за истинный, поскольку вы надеетесь на резисторы и на то, что такой помехи не будет. Начнется ложный прием, а пришедший вслед за этим настоящий пакет данных будет испорчен.

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

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

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

Теперь оценим, какой мощности должна быть помеха, чтобы испортить настоящий пакет данных в таком протоколе. Работающий передатчик RS485 обязан уметь выдавать на линию не менее 60 мА тока (реально выдает раза в два больше). Мощность помехи, необходимая для того, чтобы пересилить выход передатчика, должна быть 5В*60мА=300мВт. Почти в 20 раз больше, чем с резисторами.

Вот настолько и будет лучше помехоустойчивость правильного протокола по сравнению с дешевыми самопалами, которым нужно, "чтобы при неактивном канале было НЕАКТИВНОЕ логическое состояние" (с). Разница в десятки-сотни раз.




Добавьте к программам протоколы, у которых "срывает крышу" от всяких несуразиц в канале.

47k недают покоя)) вы же учитывайте что на линии не одно устройство, а до 32. в даташите на st485 указаны 22k. а увеличил я их чтобы немного снизить потребление тока. для линий я использую экранированую витую пару пятой категории.

У вас каждый оптрон жрет по 10 мА ни за понюх табаку, а вы на спичках пытаетесь экономить. Замените хотя бы ISO2 на обычный транзисторный оптрон (заодно Q1 можно будет выбросить, если грамотно включить), потребление уменьшится на 10 мА при прочих равных. Вы же, надеюсь, не дергаете сигнал прием/передача с частотой 1 МГц?

С двойным экраном? Один из фольги, второй из медной плетенки? Тогда ладно...

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

Насчет "устойчивости" протокола...

Вот вы когда дорогу переходите на светофоре. Тоже, в принципе, придерживаетесь определенного протокола: "Красный - стоять, зеленый - идти". Вполне нормальный, достаточно помехоустойчивый протокол. НО. Когда загорается зеленый и вы собираетесь пойти - вы смотрите на дорогу? Вы убеждаетесь в отсутствии "лихачей", стареньких подслеповатых дедушек на "Москвичах", блондинок?

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



Внимательно изучите схему. В этом включении - не инвертирует!


Потому что "исторически так сложилось" © М.С.Горбачев. В "неактивном" состоянии на линии UART предполагается уровень "MARK" (равный -12В в RS-232 или лог. "1" в ТТЛ). Стартовый бит начинается с перехода "MARK -> SPACE".

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


нет, конечно)) максимум вроде около 100-150Гц

по протоколу. протокол у меня простой:
Заголовок
Адресат
Команда
Данные постоянной длины
CRC16

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

Наличие или отсутствие растяжек никак не влияет на работу правильного протокола, поэтому "улучшить его работу" растяжками невозможно. "Чувствительность" к наличию растяжек есть полная гарантия того, что протокол плохой.


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


Я писал, что нужно два элемента:
- "Задержка перед отправкой пакета", когда передатчик включен, но данных не передает. Длительность паузы - порядка 2-3 байт-интервалов.
- Гарантия малых пауз между соседними байтами в пакете. Если приемник видит большую паузу между байтами, текущий пакет немедленно выбрасывается как ложный, а приемник мгновенно приводится в состояние готовности к приему нового пакета.

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

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


Что такое "Заголовок"?
Если его выбросить то формат у вас совпадает с modbus rtu. Когда "Адресат" идет первым, то по первому же байту можно определить предназначен ли этот пакет конкретному устройству или нет и вести предварительную отбраковку еще в прерывании.

Нет, не работает. В ситуации, когда помеха запускает UART ложным старт-битом незадолго до байта заголовка (soh), ваш пакет бyдет испорчен, поскольку заголовочный байт не будет принят. Значит, при определенном уровне помех, когда ложный запуск происходит часто, связи вообще не будет, все пакеты бyдут испорчены. Правильный протокол в этой ситуации будет работать как ни в чем не бывало.

Не будет ничего испорчено. Последовательность такая:
Передатчик посылает 1-2 байта преамбулы 0xFF, открывающую стаффинг последовательность, RTU пакет, закрывающую стаффинг последовательность, и байт преамбулы. Использую этот подход в радио каналах и серьезно задумываюсь над переносом этого протокола в 485 сети потому что жесткие времянки модбаса слегка достают уже (при том что против формата RTU пакетов я ничего не имею - формат грамотный).
Плюсы:
1. Передатчик волен вставлять любые паузы между символами (актуально когда хост - компьютер с не реал-тайм драйвером UART'a),
2. Четко выделяется начало и конец пакета, к обработке можно переходить немедленно после приема закрывающего флага, не нужно считать CRC в прерывании на слейве.
3. Опять же хост - тот же компьютер с не риалтайм приемником вместо непрогнозируемого таймаута четко распознает конец пакета - что уменьшает время реакции.

Минусы
Избыточность. (в худшем случае 2х кратное увеличение количества передаваемых данных на 1 пакет).

Если передатчик посылает всего 1 байт преамбулы 0xFF:
- Помеха, которая создаст ложный старт-бит незадолго до этого, запустит UART
- В момент прихода байтa преамбулы 0xFF, UART, находящийся где-то в середине приема байта, "не увидит" 0xFF, а увидит некий ложный байт. Пакет будет испорчен.

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

байт(0xAB), которым начинается каждый пакет

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

Но если вся сеть своя, и подключение чужих устройств не планируется, то есть НЕСРАВНЕННО ЛУЧШИЙ СПОСОБ - использование CAN-овских приёмопередатчиков. В этом случае приёмник может остановить передачу глючного пакета. Вообще при использовании CAN-овских приёмопередатчиков сплошные достоинства, и никаких недостатков - я когда-то давно эту тему поднимал. Кстати будет работать (не очень хорошо) сеть, где часть приёмопередатчиков RS485, а часть CAN.

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

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

Нет не так. Правильнее сказать так - это срабатывает не в 100% случаев. Но в случае не срабатывания этого приёма - сработает "классический" способ.

Приёмники можно не подбирать - применительно к АВР можно проинициализировать USART ведущего с U2X=1, а ведомого с U2X=0. При этом приёмник ведущего начнёт приём при более коротком (на 10%) импульсе помехи. Ещё можно не ставить у ведущего подтягивающих резисторов и т.д.

Я вобщем-то и говорил, что такой способ был-бы вне конкуренции при использовании CAN-овских приёмопередатчиков. При этом приёмник, приняв помеху за стартовый бит, сам остановил-бы передачу ведущего. Но и при использовании RS485 результат лучше, чем при байт стаффинге и при передаче 1 перед передачей. Его можно ещё улучшить если параллельно приёмнику подать сигнал на вход прерывания или захвата.

А насчёт способа с двумя FF - он не будет работать при контроле четности (или нечётности?) т.к. бит чётности будет 0. И приёмник может до бесконечности принимать его за стартовый бит (если передатчик использует 1 стоп-бит).

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

не будет пакет испорчен, так как приемник не ловит преамбулу. Преамбула используется для синхронизации. Приемник "ловит" (лучше сказать выделяет из потока мусора) только стаффинг последовательность.
Один байт 0xFF даст возможность приемнику правильно принять стаффинг последовательность, т.к. гарантируется высокий уровень (СТОП) в линии на протяжении минимум 9 битов.


Первый байт, а не второй "прочищает" приемник.
Если для устойчивого приема достаточно преамбулы в 1 байт, то два байта будет более чем достаточно.
Что же касается временных затрат на посылку преамбулы и стаффинг последовательности - да они имеют место быть, но см. выше, такой подход в некоторых случаях (мастер PC) наоборот повышает скорость обмена, за счет:
1. пресечения таймаутов между пакетами;
2. простого распознаваения конца пакета - упрощение rx flow-control'a;

+ сводится к нулю количество потерянных пакетов, из-за неверно сформированных таймаутов, когда одно из устройств сети работает под управлением не real-time ОС (например мастер ПК под Windows) и используются передатчики с FIFO большого объема, но не позволяющие разместить пакет целиком.


С одним 0xFF. AK просто не до конца смоделировал работу.
Пусть помеха включила приемник за 2 бита до инициализации преамбулы.
Тогда на линии будет следующий (12-ти битовый) фрейм:

0 x 0 1 1 1 1 1 1 1 1 1 [ стаффинг ]
x - неопределенный бит
после x начинается фрейм преамбулы 0xFF

приемник примет байт 0xFD/0xFC вместо 0xFF, и проигнорирует его, передатчик будет удерживать высокий уровень на линии т.к. передается 0xFF + 1(2)СТОП(а), и не даст приемнику начать прием до тех пор пока не сформируется СТАРТ бит стаффинг фрейма, т.о. в 485 сети достаточно всего лишь одного байта преамбулы.

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