caxapa.ru :: там в драйверах всё (см схемы вх каскадов)

Adept (05.05.2019 17:16, просмотров: 191) ответил my504 на На схеме слабая подтяжка линии к пассивным потенциалам дифпары не обозначена или ее нет вовсе?

там в драйверах всё (см схемы вх каскадов) http://caxapa.ru/919232.html

...делать нужно так, как нужно. А как ненужно - делать не нужно (С) Винни-Пух :)

Ответить

- И что из этого следует? Отсутствие подтяжки к пассивному уровню приводит к тому, что в шине ВО ВРЕМЯ ЕЕ ТРЕТЬЕГО СОСТОЯНИЯ активно генерируются рандомные помехи. Встроенные делители на полпитания как раз ухудшают ситуацию, патамушта и создают my504(328 знак., 05.05.2019 20:18 - 20:26)
  - кем генерируются - приёмниками (передатчики в это время отключены)?? Вы шутите?? Adept(554 знак., 05.05.2019 21:19)
    - В целом верно, в деталях ошибаетесь. Подтяг А на "+" и B на "-" рекомендуют с целью получения гарантированного состояния при считывании входов, когда все передатчики в Z. Без подтяга может "гулять". De_User(05.05.2019 23:53 - 06.05.2019 00:21)
      - что там деется на шине, пока передатчики молчат, драйверу, да и мне, честно говоря, - фиолетово. Начнётся передача - всё будет читаться корректно. Adept(77 знак., 06.05.2019 00:25)
        
        Как обнаруживаете начало/конец передачи, при таком подходе? - AlexBi(08.05.2019 12:07)
        
        С вероятностью 99,9% ТС просто везёт с драйверами. Подозреваю: ни разу не проверена работоспособность, если шина установлена в Z наоборот (подтянув "А" на GND, "B" на "+" по ~470R). - De_User(08.05.2019 18:35)
        
        а не пофигу , в Z там шина или нет? Когда мастер начнёт передачу в линию (а только он является инициатором обмена) всё сразу станет на свои места :) - Adept(08.05.2019 18:38)
        
        Понятно. Не проверено, фактов нет, только "понты". - De_User(08.05.2019 19:16)
        
        что проверять-то?? поборют выходы драйверов подтяжку 470 ом?? - и не проверяя скажу - однозначно поборют :)) - Adept(08.05.2019 19:21)
        
        Но как решается задача поиска начала? Все стало на место или это все еще мусор? - AlexBi(08.05.2019 19:12)
        
        решается всё протоколом :) линия гарантированно "устаканится" во время передачи начала (0x0FF) синхрослова 0xFF55, и синхробайт (0x55) уже будет приниматься корректно. Если же по каким-то совершенно неведомым причинам синхронизация не случится, то Adept(508 знак., 08.05.2019 19:31 - 19:36)
        
        После начала передачи все устаканится, но этого надо "триггер готовности к приёму взводится по таймауту отсутствия принятых байт более 250мкс", а этого может не быть, если нет растягивающих резисторов. Ради этого они и нужны. AlexBi(148 знак., 08.05.2019 20:22)
        
        перестраховаться можно, конечно, мож и не помешает (но есть там и свои минусы, в частности при замыкании A*B на линию питания 12В), но вот объясните мне, как вставшая раком линия, не даст таймеру таймаута получения байт отщёлкать его 250мкс ??? - Adept(08.05.2019 20:31 - 20:33)
        
        Линия не встанет. Достаточно высокочастотный шум создаст поток нулей и единиц, которые будут приниматься, пусть и с ошибками фрейма, не важно, таймаут приема не сформируется. Если нет растягивающих резисторов, то мощность шума, создающего такие AlexBi_(26 знак., 08.05.2019 22:15, )
        
        теоретически возможно, со стремящейся к нулю вероятностью (мало того, что на протяжении 250мкс должны формироваться правильные битовые последовательности стартбит-даные-стопбит, но ещё и синхробайт должен сформироваться. Adept(694 знак., 08.05.2019 23:31 - 23:39)
        
        Что значит "правильная байтовая последовательность"? Не нужна правильная, достаточно перепада 1->0 что бы начался прием байта, а после начала он обязательно примется, пусть и с ошибкой, но этого хватит что бы таймер паузы перезапустился (на AlexBi_(319 знак., 09.05.2019 00:00, )
        
        байт должен приняться за интервал менее 250мкс, что маловероятно, и это уже если засинхронизировались. Пока нет синхронизации, таймер сбрасывается на каждой неудачной попытке синхронизации и алгоритм опять готов к поиску синхрослова (синхробайта). Adept(266 знак., 09.05.2019 00:16)
        
        Да просто там всё, как "ситцевые трусы" :) Adept(2437 знак., 08.05.2019 18:25 - 18:34)
        
        О разном пишем. То, что алгоритм сделан продумано, вызывает уважение. Зато в производстве ВСЁ должно быть проверено. Если пакет успешно принимается во втором варианте (IDLE=LOW), то всё в порядке De_User(08.05.2019 19:59)
        
        Он не сможет приняться, т.к аффтамату незашто отсчитать пол-бода от начала старт-бита. Потому весь байт уйдёт в утиль с ашыпкой фрейма. И ваше, ситуаццыя крайне располагает к огребанию всевозможных глюков. - mse homjak(08.05.2019 20:13 - 20:16)
        
        +1. Проверить легко на прекращение обмена и чуть сложнее на замедление (увеличение количества непринятых пакетов). De_User(232 знак., 08.05.2019 21:21 - 23:21)
        
        у меня на ногу МК выведен маркер повторных транзакций (молчит - как рыба об лёд :)) (замыкаю пинцетом AB - мигает, причём, если замыкаю на конце линии - мигает, т.е. какие-то пакеты проходят, а если у мастера - то горит, т.е. ни ходит ничего) - Adept(08.05.2019 21:27)
        
        работать будет, 100%, как я уже говорил и без этого, но то, что, в принципе, нужно соблюдать стандарт, - согласен. Может и посталю "растяжку", но не менее 1к (т.к. 12В питание шины внешнее, и Adept(180 знак., 08.05.2019 20:11)
        
        Если подтяг A и B опасен, тогда без него. Ясный день, что можно (за счёт скорости) таймингами обеспечить. Тогда после окончания времени приёма ответа от Slave (по таймеру) мастер должен перейти в режим передачи и выставить необходимый уровень De_User(117 знак., 08.05.2019 21:02)
        
        там постоянно идёт перекличка устройств (сканирование шины). Мастер шлёт скан-пакеты каждую миллисекунду. Какие там ещё понадобятся таймауты и установки уровней от него??? 60-70% времени идут короткие Roll-Call-транзакции, Adept(184 знак., 08.05.2019 21:09 - 21:11)
        
        Я только за. Только проверьте, пожалуйста работу с "инверсной" и неправильной растяжкой ("А" на GND, "B" на "+" по ~470R). Для гарантии отсутствия сюрпризов при большом количестве устройств на шине. - De_User(08.05.2019 21:16)
        
        вот прям сейчас проверил (8 слейвов, дифсигнал 2 вольта) повесил по 300 ом (никакого негатива - всё чётко работает , ну съехал, конечно средний уровень (подтягивал к +12 вольтам, т.к. до пяти неудобно добираться, ибо всё уже в корпусе) - Adept(08.05.2019 21:24)
        
        Для себя ещё бы проверил с другой полярностью подтяга ("А" на "+", "B" на GND). - De_User(08.05.2019 23:31)
        
        и так и сяк проверял, но уболтали-таки, наверное сделаю растяжку, но через 1-2К и к 12 вольтам питания шины через мостик, хотя, опять же.... Adept(1491 знак., 08.05.2019 23:51 - 09.05.2019 00:01)
        
        Если через растяжку могут подать "что попало", лучше БЕЗ таковой. На один контакт ток 1,2 А? ЕМНИП провод в шлейфе штатно ~0,5 А выдерживает, максимум 0,8...1,0 А {28 AWG (7 x 0,127 мм) сечение ~0,08 мм}. - De_User(09.05.2019 00:00 - 00:06)
        
        там пара жил и пара контактов, соответсвенно. На грани.... Ну и предполагается, что шлейф на 3М двусторонне скотче на металлоконструкции, т.е. с хорошим теплоотводом и 0,6 А на жилу выдержит сколь укодно долго (а там это импульсный ток, на Adept(53 знак., 09.05.2019 00:03)
        
        Падение напряжения прикинули на 40 метров? У меня сопротивление двух жил порядка 4 Ом получилось, итого потери по 5В на каждой паре при токе 1,2А. Из 12В, так и быть, 2В должно остаться. Are you kidding? - De_User(09.05.2019 00:11)
        
        40 метров (или более), это если вытянуть всё в одну линию. Там предполагается звезда, каждый луч метров по 10-15, где-то. Всего предполагается 50-200 слейвов, равномерно распределённых по лучам, количество лучей - 4-10 (такое вот размытое ТЗ:(( Adept(543 знак., 09.05.2019 00:22 - 00:38)
        
        Куда солдата не целуй, везде ж... Такое без изолированных DC-DC буржуи не делают, КМК. В станках другой вариант: RS422, дифференциальный передатчик + оптрон на приёмной стороне (с R и противодиодом на входе). De_User(79 знак., 09.05.2019 00:56 - 01:33)
        
        пока вроде вытанцовывается нормально и с классическим 485-м без развязок, т.к. территориально всё довольно компактно, тем более там диалоговый обмен, с доморощенной опторазвязкой геморно и дорого, с настоящими изолированными 485-ми и того хуже :(( Adept(180 знак., 09.05.2019 01:39 - 01:43)
        
        "Собираюсь жить вечно. Пока все идет нормально!" - De_User(09.05.2019 01:52)
        
        "Стремлюсь к бессмертью, и пока успешно." (с) Наталья Резник - =AK=(09.05.2019 07:56, ссылка)
        
        Поздравляю! Ура! Один недостаток - после фактов на пару поводов ~~поболтать~~ пообщаться меньше :) - De_User(08.05.2019 22:37 - 23:22)
        
        тут главное с количеством стартовых байт не обсчитаться. У меня на скорости 4800 для этого (успокоения линии) предназначен 1-й байт. Там может быть что угодно. А вот второй байт - очень строго. Там только вполне определенный должен быть, Лагунов(91 знак., 08.05.2019 12:47)
        
        Уникальный байт, если вдруг встретится в посылке, заменяете на два? Обратное сворачивание (из двух байтов сделать один) делаете "на лету", что бы обнаруживать конец посылки? Или информация в посылке исключает появление уникального байта? Хотя, на AlexBi(230 знак., 08.05.2019 17:42)
        
        ну во-первых все действия только по возникновению паузы в байтах. Она должна быть гарантирована. И после этого этого просмотр буфера. В котором 1-й байт игнорируется. Второй смотрится. Если он "правильный", то смотрим дальше - сумма (а перед ней Лагунов(342 знак., 08.05.2019 18:47)
        
        Пауза в байтах гарантирована за счет чего? Передатчик не выключается после последнего байта на время гарантированной паузы? "Второй байт", т.е. уникальный байт, ищется от конца принятой посылки (перед посылкой может приниматься мусор)? Какого AlexBi(96 знак., 08.05.2019 19:09)
        
        мастер в паузах держит линию в нормальном состоянии (А>В). Т.е. не выключается. Все слейвы во время паузы очищают буфер и счетчик байт у них в "0". После запроса мастером нужного слейва тот отвечает. Те, кого опрос не касается (третий байт в Лагунов(592 знак., 09.05.2019 08:57)
        
        +1 - De_User(09.05.2019 18:33)
        
        А если старт-бит будет засран (первый фронт то есть, то нет его), пакет корректно прочитается? При единичных узлах и короткой линии такая неоднозначность маловероятна, разумеется. De_User(06.05.2019 00:29 - 00:37)
        
        пофигу, т.к. у меня по протоколу начало пакета с синхрослова FF55, причём FF - именно для "выравнивания" уровней, синхронизация далее начинается с 55, применяю поголовно, во всех проектах где есть обмен данными - никогда никаких траблов Adept(491 знак., 06.05.2019 00:43 - 00:50)
        
        Вообще то выглядит как то странно. Вы качаете с диким рейтом пустой трафик, имеете определенные проблемы, а поставить ДВА РЕЗИСТОРА Вам в падлу... И с топологией шлейфа какой то деревянный велосипед. В общем, на мой взгляд, пионерщина. - my504(06.05.2019 08:36)
        
        в наших АЗС-ких протоколах тоже первый байт только для прихода линии в исправное состояние. - Лагунов(06.05.2019 06:00)
        
        Всё в этой жизни, в той или иной степени, - "пионерщина" :))) А проблем, в общем-то (после замены дохлого драйвера) как бы и нет :)) ("Дикий битрейт" нужен для адекватного времени реакции любого устройства, при большом их количестве, а трафик да, Adept(334 знак., 06.05.2019 09:45 - 09:49)
        
        Одним байтом не обойтись. Нужно, как минимум, два. А у ТС пакеты достаточно короткие. Кроме того, придется создавать избыточность, поскольку синхробайт ничем от остальных байтов не отличается. - my504(06.05.2019 09:17)
        
        ну у него конечно, а у нас-то 9600 макс. :-) - Лагунов(06.05.2019 12:37)
        
        отличается тем, что он идёт после таймаута (таймаут в приёме байт в 250мкс сбрасывает счётчик байт пакета и приёмный алгоритм опять ожидает синхрослова) - Adept(06.05.2019 09:51)
        
        Спасибо! Тогда да, одно из двух: или первый байт не гарантирован (пожертвован в целях синхронизации пакета), или резисторы паять. Кстати, включение драйвера на передачу тоже может фронт создавать, что может воспринято как начало пакета. - De_User(06.05.2019 00:52 - 01:05)
        
        Кстати, интересное наблюдение, когда делал проект по MFi, то увидел, что у них тоже в iAP синхрослово FF55, ровно для тех же целей ("спионерили" у меня :)), так что это вполне нормальное решение. Adept(06.05.2019 01:50 - 01:53)

Схемы, платы, компоненты