[Dima1060 0]

А нагрузочный резистор зачем же тогда, а резисторы смещения?

Все так, но все равно при включенном передатчике помехе труднее пробиться. На линии будет 5 вольт, а нагрузочные резисторы смещают только на 0,2 вольта.

 

Не понимаю, ПК отправляет в USB команду инициализации и тут же получает ответ мол ОК, или не ОК. Это дает гибкость, ведь если управление с ПК, то и настроечные команды надо с ПК отправлять. Если контроллер инициализируется разово, тогда он это и сам может сделать (нет смысла посылать эти команды с другого контроллера).

USB-МК принимает команды от ПК и передает их по RS-485, а тот уже настраивает у себя что надо. Я имел ввиду, что не прокатит USB-запрос с передачей данных, потому что надо успеть команду передать по RS-485 и ответ принять и процесс "переваривания" команды бывает долгим.

Если контроллер инициализируется разово, тогда он это и сам может сделать (нет смысла посылать эти команды с другого контроллера).

У меня висит датчик ускорения, ему для инициализации надо прописать 6 регистров. Я их прописываю не из ПК, а из ПК просто идет команда "настроить" и контроллер прописывает нужные регистры. Вы это имели ввиду?

[Alexashka 0]

Я имел ввиду, что не прокатит USB-запрос с передачей данных, потому что надо успеть команду передать по RS-485 и ответ принять и процесс "переваривания" команды бывает долгим.

Ну тут вариантов реализации несколько, например сделать отдельно команду записи параметров, команду чтения их из акселерометра в буфер и команду передачи собственно буфера в ПК. Т.е. посылается к примеру команда конфигурации МСУ: "1000, 100, 200, 50", что означает установить чувствительность каналов 1-4 соответственно этим значениям. Приходит ответ: "команду отправил", это значит USB отправил команду подопечному МСУ и получил подтверждение (получения). Далее через какое-то время (скажем 100мсек) посылается новая команда "чтение конфигурации", снова получаем ответ:"команду отправил", в это время МСУ начинает вычитывать значение из акселерометра...Через фиксированное время посылаем теперь уже команду чтения буфера (они уже прочитаны и сидят в ОЗУ), на что теперь уже получаем данные: "1000, 100, 200, 50". Может это несколько сложновато, зато всё контролируется с ПК и протокол получается универсальным как для передачи команд, так и запроса данных. Контроллер USB при этом не выполняет никаких самостоятельных действий (чего он и не должен делать), а лишь функцию ретранслятора пакетов.

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

 

У меня висит датчик ускорения, ему для инициализации надо прописать 6 регистров. Я их прописываю не из ПК, а из ПК просто идет команда "настроить" и контроллер прописывает нужные регистры. Вы это имели ввиду?

Если значения регистров не предполагается менять время от времени, тогда регистры можно прописать сразу при старте МСУ, не понятно зачем для этого нужно посылать специальную команду.

[=AK= 12]

После сброса, включения питания, USB-МК настроен как передатчик (в смысле, находящийся на его стороне ресивер настроен как передатчик), второй МК настроен как приемник, ждет команд.

USB-МК отправляет команду (или серию команд), направление передачи пока не переключаем, поскольку ответа не будет.

Когда все во втором МК настроено, USB-МК посылает первый запрос данных, в прерывании по окончанию передачи - переключается на прием.

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

 

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

 

1. Если помех мало, то ничего не произойдет. Резисторы подтяжки удерживают линию связи в пассивном состоянии, если нет помех, то вообще никто ничего не заметит. Если же помехи есть, то вероятность появления ложного сигнала пропорциональна "плотности" помех, а также пропорциональна длительности "опасного" интервала.

 

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

 

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

 

3. Если длительность "опасного" интервала больше, чем в п.2, то в момент переключения коварная помеха может создать как минимум ложный старт-бит. Конечно, чем длиннее интервал переключения, тем больше вероятность, что это произойдет. Тем не менее, ложный старт-бит может появится, а значит, UART может принять ложный байт. Что с ним делать? Протоколы типа Modbus RTU устроены так, что ложно принятый в это время байт будет гарантированно отброшен. Самопальные протоколы такого как правило не умеют, они надеются на резисторы подтяжки, плюс, иногда (как в вашем случае) надеются на то, что вероятность этого события мала, поскольку длительность "опасного" интервала мала.

 

Однако это паллиатив, т.е. всего лишь припарка, не более того. Правильное решение - когда ложный сигнал будет принят, но он будет отброшен. После этого совершенно не играет роли, насколько долог или короток был "опасный" интервал.

[Сергей Борщ 129]

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

[Ruslan1 17]

Фигня какая-то. Если оба передатчика включены и выдают одинаковый уровень (а в паузах они выдают одинаковый уровень) - никакого криминала нет.

Нет, это потенциально опасный подход.

Абсолютного равенства сигналов не бывает. Причин много, например- разное питание(пусть даже в пределах отклонения стабилизаторов на одинаковое напряжение, а ведь может быть и связка 3.3В-5В), разные типы драйверов, разная температура. Так что переток будет всегда. А переток-это плохо (и КПД падает, и перекос линии по напряжению возрастает).

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

[zltigo 1]

Абсолютного равенства сигналов не бывает.

А они ни нафиг и не нужны - посмотрите хоть как выглядят выходы драйверов. Даже конфликты не проблема. Для особых параноиков есть CAN драйвера.

 

 

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

Если головы не плечах нет, то да.

С одной стороны, нельзя чтобы оба передатчика оказались включены одновременно, это криминал.

Не криминал. Максимум неопределенность состояния линии.

С другой стороны, промежуток времени, когда оба передатчика выключены, должен быть коротким.

Он может быть любым.

А насколько коротким? Что произойдет за время, пока оба передатчика выключены?

А все равно, что произойдет. Как максимум произойдет то же самое, что и обрыв линии, который есть совершенно реальная ситуаци от которой тоже надо ПРОТОКОЛЬНО защищаться.

Резисторы подтяжки удерживают линию связи в пассивном состоянии

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

 

Все "проблемы" решаются включеним передатчика ДО начала передачи за время большее передачи одного байта.

[Plain 184]

О чём здесь всё ещё спор? Два МК, линия связи с парой терминаторов и куча датчиков, и на всё в сумме — лишь 2 Вт с USB? Ясно же, что здесь только LVDS реален, да ещё, чтобы протащить, а не растерять по дороге неназванные ватты до системы сбора через терминаторы и по неназванному сопротивлению кабеля, из него требуется делать ЛЭП, т.е. соответственно повышать и понижать напряжение.

[=AK= 12]

Все "проблемы" решаются включеним передатчика ДО начала передачи за время большее передачи одного байта.

 

Так сделано в Модбас RTU, который вы еще недавно обсдавали пометом

 

Как человек почти вся жизнь занимающийся всевозможными связными потоколами могу точно сказать, что Modbus RTU есть натуральное дерьмо.

 

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

 

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

[Сергей Борщ 129]

необходимо произвести некие действия, а имено - определить, что появилась пауза

Достаточно просто проверить, что принятый мусор не совпадает с признаком начала пакета. Соответственно весь геморрой с отслеживанием времени и обеспечением непрерывности пакета становится не нужен и ModbusRTU идет лесом из любой проектируемой конструкции, где не требуется стыковка с другими устройствами, которые ничего кроме ModbusRTU не умеют.

[=AK= 12]

Достаточно просто проверить, что принятый мусор не совпадает с признаком начала пакета.

Ну а если совпадает? Одного "признака начала" недостаточно. "Байт-стаффинг" - это более точное указание на то, что требуется. Я уже писАл, что байт-стаффинг проще, чем Модбас. Более того, предлагал ТС использовать COBS.

 

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

[zltigo 1]

Так сделано в Модбас RTU, который вы еще недавно обсдавали пометом

Не надо смешивать теплое с мягким. Обеспечение тишины 3,5 символьной тишины для разделения фреймов и односимвольной тишины, как длинного стопа, для обеспечения гарантированной отстройки любых валидных байтов от мусора в линии это разные вещи.

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

Не смотря на все выше написоннае Вами, НИКАКОГО наличия никакой паузы, если это не задуманый через анус модбас, просто НЕ требуется. Совсем не требуется.

При помощи байт-стаффинга проблема решается проще,

А вот это уже ПРАВИЛЬНЫЕ слова.

[=AK= 12]

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

[zltigo 1]

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

http://electronix.ru/forum/index.php?showt...t&p=1383243

:)

 

[demiurg_spb 0]

О любимое занятие радиолюбителей поставить резисторы для подтяжки :).

Вообще-то если уж очень свербит, то давно уже есть приемники с ассиметричными порогами.

Да у миландра есть такие и мы применяем на волне импорта-замещения.

С импортными не сталкивался. Назовите одну-другую модельку, пожалуйста.

 

Ну и в продолжение темы, расскажу быль.

Не далее как пару месяцев назад столкнулись с необычным поведением драйвера ST S485EC.

Этот драйвер по нашему мнению - фейлсэйф и имеет растяжки >50К на линиях А и B к питанию и земле.

Так вот, если поставить терминатор 120 Ом, получается делитель из трёх резисторов и между линиями A и B оказывается потенциал менее 200мВ.

А напряжение менее 200мВ воспринимается, как неопределённое состояние, на ноге RO передатчика устанавливается логический 0 и мы ловим старт бит.

Вопрос - зачем так сделано (зачем ноль)?

Стоит убрать терминатор, ложные старт биты уходят.

Для себя сделали вывод, что терминатор без нормальных растяжек (~600 Ом) - зло.

С драйвером миландра со смещённым порогом таких косяков нет.

[Dima1060 0]

О чём здесь всё ещё спор? Два МК, линия связи с парой терминаторов и куча датчиков, и на всё в сумме — лишь 2 Вт с USB? Ясно же, что здесь только LVDS реален, да ещё, чтобы протащить, а не растерять по дороге неназванные ватты до системы сбора через терминаторы и по неназванному сопротивлению кабеля, из него требуется делать ЛЭП, т.е. соответственно повышать и понижать напряжение.

Сам прибор вместе с датчиками где-то 150 мА потребляет. К этому добавляются потребление приемопередатчиков, терминаторов, подтягивающих резисторов, USB-МК и ток через кабель. Кабель - 5-ти метровый USB. Пока потребление не мерял, но макет работает, правда пока без гальванической развязки.

 

Что касается Modbus и прочего, то дело в том, что у меня пакет данных от датчика составляет 12 байт плюс могу рассчитать контрольную сумму. Это траффик от датчика до МК1. Там чистый UART и скорость не хочется задирать, она там и так 350 кбит/с. Далее, к МК1 подсоединены несколько датчиков (8). То есть если приделывать к пакетам большие обрамления в МК1, то опять же придется повышать скорость передачи по RS-485 (передача на МК2).