Помехозащищенный RS-485 Опции

[Atlantis-]

Здравствуйте!
Мне нужно соединить два STM32F1 5-ти метровым кабелем. При этом один из МК будет подключен к USB, питаться тоже все будет от USB и предполагается гальваническая развязка по USB.
В итоге по 5-ти метровому проводу будут передаваться данные (скорость 1 Mbps) и питание.
Предполагается, что кабель должен быть максимально помехозащищен и желательно, чтобы под влиянием помех как минимум не вылетало USB.
Собственно предполагаю использовать RS-485 и исходя из этого есть вопросы:
1. Какой приемопередатчик RS-485 лучше выбрать? Видел много всяких типа MAX485, ST485, ADM485 и остальные
2. Нужна ли гальваническая развязка? При условии, что питание и земля все равно будут общими.
3. Во многих приемопередатчиков пишут, что есть встроенная защита, надо ли ставить дополнительно TVS-диоды?
4. Поскольку питание от USB, можно ли как то прикинуть ток потребляемый RS-485? Например так можно I=q/t=q*f=C*U*f ?
5. На что надо обратить внимание, какие есть тонкости при организации такой линии связи? Впервые сталкиваюсь с этим, поэтому извиняюсь за, может быть, глупые или детские вопросы.

[skripach]

1 Какой вам больше нравится, соответствующий вашей скорости передачи.
2 Нет.
3 Встроенная защита и TVS бывают разные, не известно от чего вы хотите защититься. Ёмкость мощных TVS может быть проблемой на Мбитных скоростях.
4 Ток зависит от "растяжек", терминаторов, длины линии, выбранных драйверов... Я думаю стоит ориентироваться на пру десятков мА.
5 Ёмкость линии, терминаторы. 1 Мбит не так уж много, 5м не так уж далеко.

[zltigo]

ок зависит от "растяжек", терминаторов, длины линии, выбранных драйверов... Я думаю стоит ориентироваться на пру десятков мА.

Пару десятков, говорите? Драйвера (только передатчики) с 5V питанием, на короткую линию согласованную 100 омами, только в линию будут гнать до 100mA, не считая всего остального. Ну а ток при коротком замыкании линии обычен под 200mA.

[Atlantis-]

1 Какой вам больше нравится, соответствующий вашей скорости передачи.
2 Нет.
3 Встроенная защита и TVS бывают разные, не известно от чего вы хотите защититься. Ёмкость мощных TVS может быть проблемой на Мбитных скоростях.
4 Ток зависит от "растяжек", терминаторов, длины линии, выбранных драйверов... Я думаю стоит ориентироваться на пру десятков мА.
5 Ёмкость линии, терминаторы. 1 Мбит не так уж много, 5м не так уж далеко.

1. Я видел, существуют трансиверы с питанием 3,3 вольта. Это как то снижает помехозащищенность? Еще нашел статью, в которой описывают "полностью защищенные трансиверы" MAX13443E. По скорости мне подходит и защита радует, но цена...в 5-10 раз обычных. Стоит оно того?
2. Точно не надо? На форуме писали, что без развязки может сбиваться процессор или вообще сгореть.

Сообщение отредактировал Atlantis- - Sep 3 2015, 06:04

[skripach]

1. Я видел, существуют трансиверы с питанием 3,3 вольта. Это как то снижает помехозащищенность?
2. Точно не надо? На форуме писали, что без развязки может сбиваться процессор или вообще сгореть.

1. Я бы использовал именно 3.3в драйверы, в 5вольтовых нет никакой нужды. На помехозащищенность думаю если и влияет, то не значительно. К тому же с учетом замечания zltigo применение 3.3в драйверов позволит снизить общее потребление.
2. Объясните как по-вашему влияет гальваническая изоляция на "горючесть" процессора?

[HardEgor]

1. Я видел, существуют трансиверы с питанием 3,3 вольта. Это как то снижает помехозащищенность?

Никак не меняют. Уровни по стандарту RS-485 в любом случае одинаковы

Еще нашел статью, в которой описывают "полностью защищенные трансиверы" MAX13443E. По скорости мне подходит и защита радует, но цена...в 5-10 раз обычных. Стоит оно того?

Та защита имеет смысл на длинных линиях в сотни-тысячи метров, у вас всего 5 метров.

2. Точно не надо? На форуме писали, что без развязки может сбиваться процессор или вообще сгореть.

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

[Atlantis-]

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

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

1. Я бы использовал именно 3.3в драйверы, в 5вольтовых нет никакой нужды. На помехозащищенность думаю если и влияет, то не значительно. К тому же с учетом замечания zltigo применение 3.3в драйверов позволит снизить общее потребление.

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

[=AK=]

желательно, чтобы под влиянием помех как минимум не вылетало USB.

Это самое сложное. USB время от времени может вылетать сам по себе, безо всяких помех, просто от багов в софте Виндовс. Худо-бедно можно использовать WinUSB, при этом очень желательно подстраховаться самодельным вочдогом, который сделает детач-аттач при потере связи по USB.

У меня в лаборатории на столе лежит некое устройство, которое верещит, когда обнаруживает, что в USB потерялись 8 или более SOF-ов подряд. Как известно, спецификация USB допускает потерю до 5 SOF-ов. Так вот, в среднем несколько раз в неделю это устройство верещит, иногда несколько раз в день. Без каких бы то ни было помех. Ну а как там виндовс на такие потери и прочие глюки USB реагирует - это можно только догадываться. Виндовый СDС класс драйвер - это полное дерьмо, он накрывается медным тазом в среднем примерно раз в месяц, COM порт исчезает, а детач-аттач не помогает, надо физически передергивать кабель.

1. Какой приемопередатчик RS-485 лучше выбрать? Видел много всяких типа MAX485, ST485, ADM485 и остальные

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

2. Нужна ли гальваническая развязка? При условии, что питание и земля все равно будут общими.

Развязка крайне желательна. В том числе по земле и питанию. Без развязки USB будет вылетать намного чаще.

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

3. Во многих приемопередатчиков пишут, что есть встроенная защита, надо ли ставить дополнительно TVS-диоды?

На 5 м - не надо.

4. Поскольку питание от USB, можно ли как то прикинуть ток потребляемый RS-485? Например так можно I=q/t=q*f=C*U*f ?

При работе на линию с терминаторами с обоих сторон куча тока уйдет в терминаторы. Пример: размах сигнала 2.5В, линия с волновым сопротивлением 120 Ом, два терминатора по 120 Ом - нагрузка 60 Ом, 2.5/60 = 41 мА на одни только терминаторы.

5. На что надо обратить внимание, какие есть тонкости при организации такой линии связи? Впервые сталкиваюсь с этим, поэтому извиняюсь за, может быть, глупые или детские вопросы.

Чтобы обеспечить хороший уровень помехоустойчивости обмена по RS485, необходимо использовать соответствующий протокол, например, Modbus RTU. С самопальным протоколом, который "надеется" на одни только растягивающие резисторы, помехоустойчивость будет хуже в сотни раз. Впрочем, даже такой уровень помехоустойчивости, сам по себе достаточно вшивый, скорей всего окажется на порядок или на два лучше, чем помехоустойчивость USB.

[Atlantis-]

Развязка крайне желательна. В том числе по земле и питанию. Без развязки USB будет вылетать намного чаще.

Развязка по USB есть - ADUM4160 и по питанию - трансформатор, я спрашивал нужна ли еще дополнительно развязка по RS-485 при условии, что питание все равно будет передаваться по тому же кабелю.

Чтобы обеспечить приемлемый уровень помехоустойчивости обмена по RS485, необходимо использовать соответствующий протокол, например, Modbus. С самопальным протоколом, который "надеется" на одни только растягивающие резисторы, помехоустойчивость будет хуже в сотни раз. Впрочем, даже такой, достаточно вшивый, уровень помехоустойчивости может оказаться на порядок или на два лучше, чем помехоустойчивость USB.

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

[=AK=]

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

Я вам об этом и толкую. Вшивые самопальные протоколы RS-485 не обеспечивают доставку данных в условиях сильных помех, у них вообще все пакеты будут "битыми" и окажутся отброшенными. А Modbus RTU в таких условиях будет работать как ни в чем ни бывало.

[Atlantis-]

Я вам об этом и толкую. Вшивые самопальные протоколы RS-485 не обеспечивают доставку данных в условиях сильных помех, у них вообще все пакеты будут "битыми" и окажутся отброшенными. А Modbus RTU в таких условиях будет работать как ни в чем ни бывало.

Не совсем понял. Если пройдет помеха и данные исказятся, то не сойдется контрольная сумма и пакет будет отброшен в любом случае. Как это будет работать как ни в чем ни бывало?

[=AK=]

Не совсем понял. Если пройдет помеха и данные исказятся, то не сойдется контрольная сумма и пакет будет отброшен в любом случае. Как это будет работать как ни в чем ни бывало?

Не диво, этого не понимают большинство создателей самопала для RS-485.

На шине RS-485 есть два состояния:
1) когда все передатчики выключены (бОльшую часть времени шина находится именно в этом состоянии)
2) когда один из передатчиков включен.

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

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

У cоздателей Modbus RTU было достаточно мозгов, чтобы создать протокол, на который вообще никак не действуют помехи в первом состоянии. В нем, чтобы испортить пакет данных, помеха должна пересилить включенный передатчик. Помехоустойчивость RS-485 c Modbus RTU сравнима с помехоустойчивостью RS-422 и даже превышает ее, поскольку передатчики RS-485 мощнее.

[Atlantis-]

На шине RS-485 есть два состояния:
1) когда все передатчики выключены (бОльшую часть времени шина находится именно в этом состоянии)
2) когда один из передатчиков включен.

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

Так можно в самопальном протоколе один из передатчиков всегда держать включенным?

[=AK=]

Так можно в самопальном протоколе один из передатчиков всегда держать включенным?

Это называется RS-422, у него передатчики вообще не переводятся в третье состояние, они всегда включены. Для него можно любой протокол использовать, он изначально помехоустойчивый. Но это обмен точка-точка, с раздельными витыми парами, одна - на прием, другая - на передачу, дуплекс. А вы вроде как RS-485, то есть шину, многоточку, полудуплекс, собирались использовать? В полудуплексе вам поневоле придется выключать передатчик, иначе будете слышать только себя.

[zltigo]

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

Помехоустойчивость канала связи и протокол это все-же разные вещи.

, например, Modbus RTU.

Как человек почти вся жизнь занимающийся всевозможными связными потоколами могу точно сказать, что Modbus RTU есть натуральное дерьмо. Это, конечно, не означает, что хуже "изобрести" нельзя, но на профессионально рожденный пртокол он ни как не тянет. Ну и протоколах - автор не говорил, ни то, что у него пакетный обмен ни то, что master-slave. Так что о протоколе разговор отдельный. Ну и на "5 метров" дуплексный RS422 почти наверняка будет предпочтительный.

[Atlantis-]

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

Полудуплекс: один МК шлет команду (передатчик1 вкл), выключает передатчик после окончания передачи, второй МК принимает команду и сразу врубает свой передатчик.

[zltigo]

В полудуплексе вам поневоле придется выключать передатчик, иначе будете слышать только себя.

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

[Atlantis-]

В полудуплексе вам поневоле придется выключать передатчик, иначе будете слышать только себя.

Какое то время да, а причем тут протокол?

[=AK=]

Полудуплекс: один МК шлет команду (передатчик1 вкл), выключает передатчик после окончания передачи, второй МК принимает команду и сразу врубает свой передатчик.

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

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

[zltigo]

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

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

[=AK=]

Учите матчасть. В RS-422 не существут высокоимпедансного состояния передатчиков, они всегда включены.

[Atlantis-]

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

За счет заданных таймаутов между кадрами?

[zltigo]

Учите матчасть. В RS-422 не существут высокоимпедансного состояния передатчиков, они всегда включены.

Не пишите, пожалуйста, диких глупостей. Особенно умиляет "учите матчасть" в сязи с тем, что стандарт RS422 номирует ТОЛЬКО уровни сигналов и ничего более.
Неотключаемые выходы передатчиков и незапрещаемые приемники, конечно, встречаются иногда у производителей запихивающих 422 интрефейсы 8 pin корпуса, но за добрых 30 лет я их не использовал ни разу, за ненеадобностью. Ну и само собой разумеется, что у 422 приемников так-же есть варианты с ассимитричными порогами, для тех-же целей, что и у 485.

[=AK=]

За счет заданных таймаутов между кадрами?

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

стандарт RS422 номирует ТОЛЬКО уровни сигналов и ничего более

Ваши высказывания про якобы "далеко не всегда включенные передатчики RS-422" являются чистым бредом. Нет там таких уровней сигнала, есть или 0 или 1. И если производители делают микросхемы, совместимые с RS-422, но имеющие вдобавок еще третье состояние передатчика, то сам стандарт RS-422 от этого ни на йоту не изменяется.

[zltigo]

За счет заданных таймаутов между кадрами?

Да нет, за супер-пупер помехозащищенность тут пытаются выдать САМУЮ МИНИМАЛЬНЕЙШУЮ меру по синхронизации начала фрейма.
Ну а по хорошему ловля маркера начала фрейма из мусора при высоком уровне помех должна начинаться с захвата сначала битовой, а потом байтовой синхронизации, и только после этого уже смотреть на начало фрейма. Надеяться на то, что включенный передатчик является гарантией отсутствия помехи на стороне приемника это оптимистично.

Ваши высказывания про якобы "далеко не всегда включенные передатчики RS-422" являются чистым бредом. Нет там таких уровней сигнала, есть или 0 или 1.

Не недо пытаться выкручиваться. В RS485 тоже "нет таких уровней сигнала, есть или 0 или 1". Сюрприз!!!
Просто везеде есть совершенно реальное состояние - ОТКЛЮЧЕННАЯ линия, она же оборванная . И никакой стандарт не может этого факта отменить.

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

Золотые слова ! НЕ МЕНЯЕТСЯ, по причине того, что он НИКАК не требует НЕОТКЛЮЧЕНИЯ передатчика. Так что и производители и пользователи совершенно законно, сообразуясь со своими разумениями и потребностями, или ИСПОЛЬЗУЮТ, или нет, отключение передатчика в ПОЛНОМ согласии со стандартом.

[=AK=]

Не недо пытаться выкручиваться. В RS485 тоже "нет таких уровней сигнала, есть или 0 или 1". Сюрприз!!!
Просто везеде есть совершенно реальное состояние - ОТКЛЮЧЕННАЯ линия, она же оборванная . И никакой стандарт не может этого факта отменить.

RS-422 прямым текстом оговаривает соединение "точка-точка", на рисунках приводит двунаправленное дуплексное подключение, а для передатчика определяет только уровни 0 и 1 и требует низкое выходное сопротивление, не более 100 Ом. И никакой "отключенной линии" там нет. Так что ваши поделки, напоминающие RS-422, но переводящие передатчик в высокоимпедансное состояние, стандарту RS-422 не соответствуют.

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

Вы бы хоть почитали что-нибудь по этой теме, чтобы немножко подковаться и не нести невежественную ахинею типа "стандарт RS422 номирует ТОЛЬКО уровни сигналов и ничего более", или что RS-422 "НИКАК не требует НЕОТКЛЮЧЕНИЯ передатчика", и т.п. У http://www.ti.com/, помнится, неплохие были аппноты для начинающих, вам это как раз подойдет.

[Ruslan1]

RS-422 прямым текстом оговаривает соединение "точка-точка"

Вы, извиняюсь, в стандарт-то заглядывали? Зачем такие удивительные придумки вслух говорить?
Вам стандарт процитировать или сами найдете про наличие "одного или более приемников" на линии ?

Вы бы хоть почитали что-нибудь по этой теме, чтобы немножко подковаться и не нести невежественную ахинею

Именно! Даже добавить нечего. Только читать нужно не "что-нибудь" на заборе, а соответствующие документы.

[=AK=]

RS-422 прямым текстом оговаривает соединение "точка-точка"

Вы, извиняюсь, в стандарт-то заглядывали? Зачем такие удивительные придумки вслух говорить?

Еще один "знаток" выискался...

Вам стандарт процитировать или сами найдете про наличие "одного или более приемников" на линии ?

Приемников может быть до десяти штук. А соединение остается быть "точка-точка".

[Ruslan1]

Приемников может быть до десяти штук. А соединение остается быть "точка-точка".

Замечательно. Соединение "один передатчик-много приемников" является соединением "точка-точка". Спасибо за разъяснение.

[=AK=]

Замечательно. Соединение "один передатчик-много приемников" является соединением "точка-точка". Спасибо за разъяснение.

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

[zltigo]

Вы бы хоть почитали что-нибудь по этой теме, чтобы немножко подковаться и не нести невежественную ахинею типа "стандарт RS422 номирует ТОЛЬКО уровни сигналов и ничего более", или что RS-422 "НИКАК не требует НЕОТКЛЮЧЕНИЯ передатчика", и т.п.

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

В рамках стандарта RS-422 - таки да. Я вполне понимаю создателей стандарта, которые не стали париться с жеванием соплей типа что "иногда также и точка-многоточка".

Нет НЕ понимаете, поскольку НЕ ЗНАЕТЕ термина interconnection применненного в стандарте. Учите языки и профессиональную терминогию.

[Dog Pawlowa]

В своем универсальном RS485/RS422 модуле я просто добавил настройку singlepoint/multipoint, потому что некоторые производители оборудования требуют постоянную активность моего передатчика, а в некоторых системах это невозможно по причине множества слэйвов.
И что характерно, все называют этот интерфейс RS422

[=AK=]

И что характерно, все называют этот интерфейс RS422

Инженерный жаргон. Я вот тоже, конденсаторы предпочитаю "кондерами" называть, для краткости.

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

Я на таких в реальной жизни тоже насмотрелся. Как говорил Окуджава по этому поводу, "мне давно пора уже орден получить"

[Atlantis-]

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

[Ruslan1]

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

Нормальный драйвер, нет подвоха.
Дешево это сколько? Посмотрел на Дижикее- очень даже недешево, $1.42 мелким оптом. Например, ST1480ABDR - подешевле, $1.15.
Если цена жмет- то смотрите 5-вольтовые. Они штатно управляются от 3.3- вольтовой логики, а питание 5 вольт у Вас уже есть (USB).

[gte]

Учите матчасть. В RS-422 не существут высокоимпедансного состояния передатчиков, они всегда включены.

Вы в топике на аппноты TI ссылались.
Так посмотрите, имеют их передатчики TI RS-422 Z - состояние или нет.
Вот, например, AM26LV31E. "This device is designed to meet TIA/EIA-422-Band ITU Recommendation V.11 drivers with reduced supply voltage." Имеет Z состояние.

[Atlantis-]

Нормальный драйвер, нет подвоха.
Дешево это сколько? Посмотрел на Дижикее- очень даже недешево, $1.42 мелким оптом. Например, ST1480ABDR - подешевле, $1.15.
Если цена жмет- то смотрите 5-вольтовые. Они штатно управляются от 3.3- вольтовой логики, а питание 5 вольт у Вас уже есть (USB).

ST1480ABDR в Компэле нет((

Вот аналогичные, гораздо дороже
http://www.maximintegrated.com/en/products...s/MAX3486E.html
2,5 Mbps 10 USD есть в Компэл

http://www.maximintegrated.com/en/products...s/MAX3078E.html
тоже 10

http://www.maximintegrated.com/en/products.../MAX14840E.html
40 мегабит, 6 баксов

Сообщение отредактировал Atlantis- - Sep 4 2015, 07:35

[zltigo]

40 мегабит...

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

[Ruslan1]

ST1480ABDR в Компэле нет((

Да нормальный драйвер ST3485, берите. И Компэл хорошая контора
У этих 8-ножек полная совместимость по выводам, так что в будущем примените любой другой, если чем-то не устроит (цена, доставабельность, параметры).

[zltigo]

Да нормальный драйвер ST3485, берите. И Компэл хорошая контора
У этих 8-ножек полная совместимость по выводам, так что в будущем примените любой другой, если чем-то не устроит (цена, доставабельность, параметры).

Хотелось-бы только, что бы автор подумал, а действительно ему нужен RS485, или это просто первые попавшиеся ему цифры? Я уже высазывал предположение, что ему скорее всего при его двух устройствах и 5 метрах кабеля, RS422 разумнее будет.

[=AK=]

Вы в топике на аппноты TI ссылались.
Так посмотрите, имеют их передатчики TI RS-422 Z - состояние или нет.
Вот, например, AM26LV31E. "This device is designed to meet TIA/EIA-422-Band ITU Recommendation V.11 drivers with reduced supply voltage." Имеет Z состояние.

Что мне на них смотреть, я их предтеч DS26LS31/32 уже в далеком 1985г использовал. Для шины, которая изначально создавалась под RS-485. Поскольку к моменту выхода моего изделия советская промышленность уже должна была наладить выпуск их аналога, а вот нужного мне аналога SN75176 в тот же срок еще не было.

Я уже говорил раньше, и еще раз повторю: производитель в полном праве выпускать передатчик с третьим состоянием и писать, что он "соответствует RS-422". Потому что, если его вход EN намертво посадить на питание, а вход ~EN - на землю, то получится самый натуральный передатчик RS-422, без малейшего изьяна. А вот если во время работы постоянно дергать эти входы, то включая, то выключая выход передатчика, то это будет уже не RS-422, а ублюдочный вариант RS-485.

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

[zltigo]

а ублюдочный вариант RS-485.

Назовите сие AK-422 и трактуйте, как хотите, хоть прописывайте расстрел за отключение разъема, или выхода передатчика, раз это событие угробит все Ваши чудесные "протоколы". Но нормальные решения должны считаться и обрывыми линий, и с выключеним питания на встречной стороне, и с отключеним передатчика, как частым случаем. И четко разрешать проблемы возникающие в таких ситуациях. Не научились с 1985 года проектировать ДЕЙСТВИТЕЛЬНО надежные системы передачи данных использующие такие интрефейcы? Ну так это Ваши проблемы и не надо проецировать их на всех разработчиков. Так-что отключение выхода передатчика есть совершенно естественная ситуация, хотя-бы по этой причине никак не запрещаемая ни мохнатым RS-422, ни V.11 и используемая, например, как писал в первом посте на эту тему, для экономии энергии. И только авторы "ублюдочных" протокольных решений могут не понимать этого и до истерики требовать наличия тока в линии "всегда".
И вообще RS-xxx это не стандарты, это отраслевые рекомендации, где до кучи записаны некие описания некоторых решений, причем сумбурные и неполные. Стандарты это тот-же V.11. B нем действительно застандартизировано то, что нужно и выкинуты всякие частности и глупости не по делу. Пора уже давно забыть о ставших просто жаргонизмами RS....

[Atlantis-]

Хотелось-бы только, что бы автор подумал, а действительно ему нужен RS485, или это просто первые попавшиеся ему цифры? Я уже высазывал предположение, что ему скорее всего при его двух устройствах и 5 метрах кабеля, RS422 разумнее будет.

А в чем его преимущество? В постоянно включенном передатчике?
Там же полный дуплекс нужен, а это две витых пары плюс питание - у нас таких кабелей нет, придется дополнительно искать, заказывать. А для RS-485 можно использовать например USB кабель - та же витая пара и питание.

[zltigo]

А в чем его преимущество? В постоянно включенном передатчике?

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

а это две витых пары плюс питание - у нас таких кабелей нет, придется дополнительно искать

Точно искать? Уверены? A 4 витые пары нигде "случайно" встречать не приходилось Две под питание, две под данные.

[=AK=]

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

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

Можно взять за основу Модбас, в котором все есть, или можно использовать байт-стаффинг, что гораздо проще, поскольку не требует сравнительно строгого тайминга. Среди байт-стаффингов советую ТС обратить внимание на элегантный и эффективный COBS. Организация "мастер-слэйв" в парном соединении является абсолютно естественной и не требующей никаких усилий для реализации. Так что ТС вполне волен выбрать полудуплекс, если ему так хочется, хотя с полным дуплексом (т.е. RS-422) на кабеле Cat5 или Cat6 реализация будет немножко проще. Главное, чтобы при этом ТС не слушал идиотских советов "выключать передатчик для экономии энергии", иначе ставить дуплекс становится бессмысленным.

[=AK=]

Так-что отключение выхода передатчика есть совершенно естественная ситуация, хотя-бы по этой причине никак не запрещаемая ни мохнатым RS-422, ни V.11 и используемая, например, как писал в первом посте на эту тему, для экономии энергии.

Я уже писал, что RS-422 требует, чтобы выходное сопротивление передатчика не превышало 100 Ом. Вы неспособны дотумкать, что из этого следует, что передатчик RS-422 нельзя выключать. А для экономии энергии умные люди не передатчиком дрыгают, а ставят RC-терминаторы.

[Herz]

=AK=, Вы уже слишком увлеклись грубостями и оскорблениями. Не заставляйте делать оргвыводы.

[Ruslan1]

zltigo, не пытайтесь ответить на весь генерируемый =AK= текст. У него какие-то личные счеты к RS-485 или к кому-то из людей, его применявших. Как результат- =AK= обливает грязью и оскорбляет всех, кто что-то пытается возразить, так как видит в их лице своих обидчиков.
Это идея фикс. Возможно, не лечится. Нужно просто не замечать и не реагировать, он побуянит немного и успокоится.

А в чем его преимущество? В постоянно включенном передатчике?
Там же полный дуплекс нужен, а это две витых пары плюс питание - у нас таких кабелей нет, придется дополнительно искать, заказывать. А для RS-485 можно использовать например USB кабель - та же витая пара и питание.

Преимущество полного дуплекса- не нужно никаких договоренностей о процедуре доступа к линии. Просто подключаете драйверы для раскачки линии - и вперед. Любой полудуплекс требует усилий для приближения к тому качеству, которое дуплекс дает без всяких усилий.
Полудуплекс нужен для экономии ресурсов (проводов, защитных цепей, контактов), но достигается это усложнением программной части. Для коротких линий смысла в полудуплексе нет.

Кабель- Идеальным является езернет витая пара: низкая цена, доступность, наличие любых типов подходящих по качеству и конструктиву разъемов.
USB кабель - не советую.

[=AK=]

=AK=, Вы уже слишком увлеклись грубостями и оскорблениями

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

[Plain]

нужно соединить два STM32F1 5-ти метровым кабелем ... питаться тоже все будет от USB ... предполагаю использовать RS-485

Выше уже сказали — бесполезный нагрев, и теоретических 500 мА вообще может на всё не хватить, так что ставьте LVDS, на чём давно и успешно работают USB, SATA, PCI-E и т.п., и будете счастливы. Соответствующих защит и драйверов — в "Чип и Дип" вагон и тележка.

[zltigo]

так что ставьте LVDS...

Для требуемых 5 метров это разумное решение. Но только несколько наcтораживает слово "помехозащищеный" в названии темы, хотя автор никак не конкретизровал это требование. Но вообще кроме LVDS вариантов дифференциальных приемопередатчиков еще немало есть.

Нужно просто не замечать и не реагировать...

Согласен.

[Herz]

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

Мне не хотелось бы здесь устраивать "разбор полётов". Не в тему.
Надеюсь, Вы сами, спокойно перечитав ветку, обнаружите, что дискутировали слишком эмоционально.

Вы с такой точки зрения никогда не пытались рассматривать сообщения на форуме?

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

Инженерный жаргон. Я вот тоже, конденсаторы предпочитаю "кондерами" называть, для краткости.

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

По случаю, выскажусь ещё раз в осуждение жаргона. Как Вы сами замечаете, "проще" и "короче" - не всегда значит "лучше" и понятнее".
Создание "гнилых" протоколов - лишь частный случай небрежности в исполнении, связанной с небрежностью в рассуждениях и формулировках.
Склонность к жаргону, ИМХО, - вид распущенности, мешающий действовать аккуратно как в общении, так и в работе.
Но в разделе для начинающих, где не все - люди взрослые и ответственные, на жаргон ещё смотрю сквозь пальцы. Хотя, желал бы, чтобы мэтры подавали хороший пример для подражания. Ибо убеждён: схема, "сколхоженная" из резюков и кондюков со "вкряченными" туда микрухами и работать обречена соответственно. А автору, тачающему такую "электронику" - никогда не стать грамотным инженером.

[Atlantis-]

Для требуемых 5 метров это разумное решение. Но только несколько наcтораживает слово "помехозащищеный" в названии темы, хотя автор никак не конкретизровал это требование. Но вообще кроме LVDS вариантов дифференциальных приемопередатчиков еще немало есть.

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

[Ruslan1]

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

RS-485 очень устойчивый. Сделать линию связи более устойчивой тоже просто- применить Ethernet кабель с двойным экраном и грамотно соединить земли и экраны.
Говорю про RS485 потому что его знаю. Возможно, другие синфазные интерфейсы тоже не хуже, у меня нет опыта их использования.

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

[Atlantis-]

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

Структура такая: короткий кабель USB воткнут в ПК и соединен с промежуточным блоком (в этом блоке есть развязка по USB и питанию), далее кабель 5 метров (предполагаемый RS-485), на другом конце которого интерфейсный блок к которому присоединяются датчики.
Я тут подумал - самым слабым звеном кажется даже не 5-метровый кабель, а провод от датчика до интерфейсного блока. Там просто UART, а не дифф. пара.

[=AK=]

Я тут подумал - самым слабым звеном кажется даже не 5-метровый кабель, а провод от датчика до интерфейсного блока. Там просто UART, а не дифф. пара.

Для перестраховки там тоже можете поставить шинники RS-422.

Самым слабым звеном будет USB. Вместо него лучше всего было бы использовать Эзернет.

[Atlantis-]

Для перестраховки там тоже можете поставить шинники RS-422.

Там кабель надо тонкий, гибкий. Я нашел только экранированный трехпроводной. Ну и размер датчика ограничен.

[zltigo]

Структура такая: короткий кабель USB воткнут в ПК и соединен с промежуточным блоком

USB это очень тоскливо, тем более, когда о помехах речь идет. Что там такое "промежуточный блок" делает между UART и USB, что PC сделать не может? Убрать его, в PC сразу RS422/485 гальванически развязанный порт в вперед...

Там кабель надо тонкий, гибкий. Я нашел только экранированный трехпроводной. Ну и размер датчика ограничен.

Да 5 метров можно хоть руками сделать, тем более, что изделие, похоже, штучное.

[Atlantis-]

USB это очень тоскливо, тем более, когда о помехах речь идет. Что там такое "промежуточный блок" делает между UART и USB, что PC сделать не может? Убрать его, в PC сразу RS422/485 гальванически развязанный порт в вперед...

все так, но у меня задание сделать именно USB устройство

Да 5 метров можно хоть руками сделать, тем более, что изделие, похоже, штучное.

можно, если без экрана
самодельный экранированный провод не гибкий, заводские тоже трудно найти тонкие и гибкие

Но вообще кроме LVDS вариантов дифференциальных приемопередатчиков еще немало есть.

какие например?

[Владимир]

все так, но у меня задание сделать именно USB устройство

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

[zltigo]

какие например?

Если не забанили в интернете, то найдете - начиная с LVPECL, VML, CML, MLVDS, BLVDS, LVDM...

самодельный экранированный провод не гибкий...

Сильное заявление . Самодельный на то и самодельный, что может быть ЛЮБЫМ!

все так, но у меня задание сделать именно USB устройство

Вам шашечки, или ехать? На худой конец, тот-же USB-RSxxx гальванически развязаный.

А вообще еще есть массовая дешовая оптика.

[Dog Pawlowa]

тот-же USB-RSxxx гальванически развязаный.

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

[Atlantis-]

Сильное заявление . Самодельный на то и самодельный, что может быть ЛЮБЫМ!

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

Вам шашечки, или ехать? На худой конец, тот-же USB-RSxxx гальванически развязаный.

А вообще еще есть массовая дешовая оптика.

В смысле вместо МК поставить преобразователь USB-RSxxx ? А в чем преимущество будет? Гальваническая развязка у меня тоже есть (правда USB). И если не ошибаюсь преобразователь USB-RSxxx определится как виртуальный COM-порт, а мне надо изохронный канал.

[zltigo]

Гальваническая развязка у меня тоже есть (правда USB).

Вы в этом ТОЧНО уверены???

И если не ошибаюсь преобразователь USB-RSxxx определится как виртуальный COM-порт

Ошибаетесь. Это только один вариант использования.

, а мне надо изохронный канал.

Ни одно из понятий определяемых помянутым Вами термином "изохронный" у меня лично НИКАК не вяжется с "Структура такая: короткий кабель USB воткнут в ПК .... которому присоединяются датчики ... просто UART"
Что сказать-то хотели???

[Atlantis-]

Вы в этом ТОЧНО уверены???

да, ADUM4160 по линиям данных USB и трансформатор по питанию

Ни одно из понятий определяемых помянутым Вами термином "изохронный" у меня лично НИКАК не вяжется с "Структура такая: короткий кабель USB воткнут в ПК .... которому присоединяются датчики ... просто UART"
Что сказать-то хотели???

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

[zltigo]

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

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

[Atlantis-]

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

я имел ввиду, что нужен изохронный канал USB

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

[zltigo]

я имел ввиду, что нужен изохронный канал USB

В общем пока вижу совершенно непродуманую систему куда, очевидно, для большего барадака еще и USB приянули.
Если Вам нужно "реальное время", то оно должно обеспечиваться контроллером, а не какой-то PC с неведомой операционкой подключенной по USB.
Пакеты с информацией от датчиков должны приходить в PC уже с ОТМЕТКАМИ времени сделаными контроллером датчиков.

[Atlantis-]

В общем пока вижу совершенно непродуманую систему куда, очевидно, для большего барадака еще и USB приянули.
Если Вам нужно "реальное время", то оно должно обеспечиваться контроллером, а не какой-то PC с неведомой операционкой подключенной по USB.
Пакеты с информацией от датчиков должны приходить в PC уже с ОТМЕТКАМИ времени сделаными контроллером датчиков.

Такое жесткое "реальное время" не требуется, просто нужно увидеть на экране воздействие на датчик не через 3 секунды, как это возможно в Bulk-канале.
От датчиков приходят данные с заданной частотой и пока, на макете, все устраивает. Просто нужно удлиннить кабель до ПК.

[=AK=]

я имел ввиду, что нужен изохронный канал USB

А нужен ли?

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

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

[Atlantis-]

А нужен ли?

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

да, так и будет

[Atlantis-]

Вы в этом ТОЧНО уверены???

Сейчас появилась идея делать USB без развязки, а развязку сделать на другом конце RS-485. То есть будет так: USB-USB процессор-трансивер-кабель RS-485-трансивер-гальваническая развязка-процессор-датчики
В такой конфигурации есть какой то изъян?

[zltigo]

Сейчас появилась идея делать USB без развязки, а развязку сделать на другом конце RS-485. То есть будет так: USB-USB процессор-трансивер-кабель RS-485-трансивер-гальваническая развязка-процессор-датчики
В такой конфигурации есть какой то изъян?

Если выбирать из многих зол меньшее, то нет .

[Dog Pawlowa]

В такой конфигурации есть какой то изъян?

У Вас что, никогда мышь "не отваливалась"?!
Ну люди падают с луны и прямо сюда! ;)

[Atlantis-]

У Вас что, никогда мышь "не отваливалась"?!
Ну люди падают с луны и прямо сюда!

Честно - никогда) а Вы это к чему?
принтер подвисает иногда, там кабель 5 метров

[Alexashka]

Честно - никогда) а Вы это к чему?
принтер подвисает иногда, там кабель 5 метров

При включении Теслы (примерно 2м от компа) мышь и клава отваливаются изредка, USB-осциллограф - сразу.

[Atlantis-]

При включении Теслы (примерно 2м от компа) мышь и клава отваливаются изредка, USB-осциллограф - сразу.

Это же зависит как то от длины кабеля USB?

При такой структуре:

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

длина USB соединения будет около 1 см - от процессора до разъема, USB процессор и трансивер разместятся в корпусе USB штекера.

[Alexashka]

Это же зависит как то от длины кабеля USB?

От длины и качества кабеля, качества разводки, скорости работы порта (низкоскоростной/полноскоростной), чипов и пр.и пр.

[Panych]

По поводу помехозащищенности и развязок. Уже звучали намёки в вопросах к ТС, но всё же не было конкретизировано подключение земель и экранов.
Если датчики заземлены изначально вдали от развязки USB, это одно. Тут скорее всего понадобится дополнительная гальваническая развязка.
Если все компоненты системы изолированы и заземляются только в месте развязки, это вроде как другое.
Нет?

[Владимир]

USB-осциллограф - сразу.

пытались таким смотреть сетевые блоки питания такими осциллографами (маленькие, модно в операционную, точнее в подсобку туда взять). Если не изолированный-- потеря USB после каждого второго (загнул конечно но очень регулярно, и смотря куда соваться), тыка щупом . Раз в полгода-- смерть USB. С питанием такого осциллографа изоляцией (через трансформатор) полегче но в принципе не спасает. --в зависимости от мощи.
Конечно коагулятор и рядом не лежал по мощности. Но все же я бы не рисковал. Тем более медицина. Прерывать операцию из-за временной потери USB как-то не очень. Доктора будут точно не довольны.

[dinam]

Напишу немного практических результатов. Применяем видеокамеры собственной разработки с питанием по USB. Используем USB High Speed, устоявшийся поток данных иногда 45Мбайт/сек. Часто используется внешний запуск камер или 2-4 синхронно работающие камеры. Для синхронизации применяю XR3178EID и ADM485AR. Также используем самодельные драйверы шаговых двигателей на токи до 2,5 А и фронтами длительностью порядка 50-100нсек. Часто все эти провода уложены вместе в общий кабель канал. Кабели USB паяем сами, провода к ШД обязательно в экране, всю установку обязательно заземляем. Только такой комплекс мер позволяет стабильно работать нашим установкам на производстве. Но всё же самым слабым местом по надежности это USB. Всё таки этот протокол не промышленный и не предназначен для работы в условиях сильных помех. Поэтому я бы на вашем месте для начала определился с надежностью работы USB. Ну там статикой пощелкал или рядом с устройством разместил более-менее мощный какой-нибудь генератор помех.

[Atlantis-]

По поводу помехозащищенности и развязок. Уже звучали намёки в вопросах к ТС, но всё же не было конкретизировано подключение земель и экранов.
Если датчики заземлены изначально вдали от развязки USB, это одно. Тут скорее всего понадобится дополнительная гальваническая развязка.
Если все компоненты системы изолированы и заземляются только в месте развязки, это вроде как другое.
Нет?

Датчики не заземлены, все изолировано. Заземление как таковое осуществляется только через USB.

То есть будет так: USB-USB процессор-трансивер-кабель RS-485-трансивер-гальваническая развязка-процессор-датчики

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

К опытному образцу с точки зрения зависания USB претензий не было, хотя там конструкция: кабель USB 3 метра - прибор - кабель датчика 1 метр - датчик

[Владимир]

К опытному образцу с точки зрения зависания USB претензий не было,

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

[Atlantis-]

Подскажите пожалуйста один момент при применении RS-485. Там надо переключать направление передачи данных.
У меня два МК, первый соединен с USB и по сути передает второму МК команды и принимает от него данные.
Я пока придумал такую логику, интересно насколько она верна.
После сброса, включения питания, USB-МК настроен как передатчик (в смысле, находящийся на его стороне ресивер настроен как передатчик), второй МК настроен как приемник, ждет команд.
USB-МК отправляет команду (или серию команд), направление передачи пока не переключаем, поскольку ответа не будет.
Когда все во втором МК настроено, USB-МК посылает первый запрос данных, в прерывании по окончанию передачи - переключается на прием.
Соответственно, второй МК после принятия такого запроса сразу же переключается на передачу, запускает таймер, который отсчитав 1 мс переключает МК на прием. Соответственно, время 1 мс выбрано потому что запросы данных будут приходить от USB-МК именно с такой частотой.

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

[Ruslan1]

Atlantis, зачем все это? Не нужно еще один протокол изобретать, их есть уже готовых и проверенных временем и миллионами применений.
Берите любой протокол мастер-слейв, да хоть тот же дубовый Modbus и делайте общение на нем.
Или CANopen. да много их разных.
Огромный плюс использования стандартного протокола в слейве - возможность подключения устройства не только к Вашему мастеру, но и к любому другому с таким же протоколом, или к компьютеру (для тестирования и отладки, например). Если Вы не эксперт в написании протоколов, то плюсов в использовании готового будет гораздо больше.

Upd: непонятно, зачем вообще USB девайс в Вашей системе и почему не подключить RS-485 напрямую к компьютеру, но это уже другой вопрос.

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

Проблемы на ровном месте. 5 метров кабеля по операционной развешивать. Сделайте в вашем концентраторе датчиков сразу Wi-Fi. И скорости нормальные и гальваноразвязка и модулей встраиваемых сейчас развелось на все вкусы.

[zltigo]

Проблемы на ровном месте. 5 метров кабеля по операционной развешивать. Сделайте в вашем концентраторе датчиков сразу Wi-Fi.

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

[Alexashka]

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

Зачем таймер? Отправил ответ и сразу переключился на прием.

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

[Atlantis-]

Зачем таймер? Отправил ответ и сразу переключился на прием.

Тогда большой промежуток времени оба приемопередатчика будут в режиме "приемник", то есть будут ловить помехи

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

это даа, но трудно реализуемо...ответ то придет, только его надо еще на ПК отправить. для этого видимо придется еще один Endpoint делать, чтобы путаницы не было.

[Alexashka]

Тогда большой промежуток времени оба приемопередатчика будут в режиме "приемник", то есть будут ловить помехи

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

это даа, но трудно реализуемо...ответ то придет, только его надо еще на ПК отправить. для этого видимо придется еще один Endpoint делать, чтобы путаницы не было.

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

[Atlantis-]

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

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

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

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

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

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

[Alexashka]

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

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

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

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

[=AK=]

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

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

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

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

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

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

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

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

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

[Ruslan1]

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

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

[zltigo]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Plain]

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

[=AK=]

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

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

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

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

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

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

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

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

[=AK=]

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

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

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