0 / 0 / 0
Регистрация: 11.10.2012
Сообщений: 87
|
|
1 | |
Выбрать подходящий интерфейс и протокол14.10.2012, 19:40. Показов 35914. Ответов 59
Метки нет (Все метки)
Всем привет!
Делаю вот сейчас курсовой проект, в будущем планируется развить все это дело до диплома. И, уже чисто для себя, параллельно намереваюсь собирать в железе все то, что придумываю в курсаче. Чтобы было менее абстрактно, я делаю систему безопасности, состоящую из главного координирующего устройства и цепляющихся к нему устройств. Таких как, например, коммутаторы мощных нагрузок (сигнализации) и концентраторы, к которым, в свою очередь, цепляются охранные извещатели, умеющие только замыкать или размыкать свои контакты при срабатывании. Итак, проблема состоит в следующем: нужно организовать связь между всеми этими устройствами и главным устройством. Велосипед изобретать не только не хочется, но это еще и не рационально. Посмотрел в вики, есть куча подобных интерфейсов и реализованных поверх них протоколов (они, как я понял, входят в группу "промышленных интерфейсов"). Итак, каковы требования: 1. Все устройства вешаются на одну общую шину. А значит нужно организовать адресацию. 2. Главное устройство должно слать данные другим устройствам, другие устройства должны сами (то есть выступать ведущими) слать данные главному устройству. Слать данные друг другу им не нужно. 3. Физически интерфейс должен быть помехоустойчивый и максимальная длина кабеля должна быть где-то около 500 метров, а лучше километр (не знаю насколько это рационально для системы охраны, но препод настаивает на этом). 4. Ограничений к скорости передачи нет, ибо данных передавать ерунда: одна посылка вряд ли будет больше 2-6 байтов. 5. Было бы не очень хорошо тащить больше 3-5 проводов в кабеле. 6. Ах да, ну и не обязательно: думаю, было бы здорово, если бы интерфейс можно было бы несложно совместить с UART на борту контроллера. Итак: 1. Какой мне лучше выбрать физический интерфейс? 2. Какие есть стандарты подходящих протоколов передачи поверх этого интерфейса? Заранее спасибо за помощь!
0
|
14.10.2012, 19:40 | |
Ответы с готовыми решениями:
59
Выбрать подходящий RAID-контроллер Не могу выбрать подходящий парсер для файла 'can' Не могу выбрать подходящий парсер для файла 'FileTest' База данных, массив и другие варианты хранения информации. Как выбрать подходящий |
0 / 0 / 0
Регистрация: 13.07.2012
Сообщений: 566
|
|
15.10.2012, 03:45 | 21 |
Сообщение от tymburo
Хотя, насчет того насколько он надежен я не ручаюсь. Думаю товарищи подскажут.
0
|
0 / 0 / 0
Регистрация: 21.10.2011
Сообщений: 1,860
|
|
15.10.2012, 03:49 | 22 |
да в данном применении классическое понятие надежности ГСЧ не требуется чуть более чем совсем. главное, чтобы период был достаточно большим и в разных девайсах инициализировать различными начальными значениями. не криптографию ведь мутим.
0
|
0 / 0 / 0
Регистрация: 16.02.2012
Сообщений: 699
|
|
15.10.2012, 04:48 | 23 |
Сообщение от _pv
0
|
1 / 1 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
|
|
15.10.2012, 08:21 | 24 |
Сообщение от tymburo
0
|
0 / 0 / 0
Регистрация: 01.09.2012
Сообщений: 125
|
|
15.10.2012, 12:11 | 25 |
пардон, если не совсем по теме, но вообще топикстартеру должно быть полезным
мультимастерность в подобных вещах, насколько я сталкивался, является краеугольным камнем. В связи с этим в умном доме, который я как-то делал, решили использовать Ethernet на базе модулей WIZ811 (Ethernet<->SPI (или параллельная шина)), и со связью проблем практически не было Но хотелось бы поинтересоваться у знающих товарищей: 1. Кто-нибудь знает про реализацию CSMA/CD на RS-485? Насколько я знаю, modbus этого не обеспечивает. 2. Насколько хорошо работает CAN на длинных линиях? По слухам (сам не ковырялся), больше 200-300 метров начинаются какие-то проблемы.
0
|
0 / 0 / 0
Регистрация: 21.08.2011
Сообщений: 1,057
|
|
15.10.2012, 13:11 | 26 |
Можно обойтись ГСЧ на стороне мастера. Надежность к коллизиям имеет только шина с одним мастером. Для поиска девайсов на шине можно использовать алгоритм 1-Wire. Что касается присвоения оборудованию уникальных адресов, то присваивать их рандомно не самая лучшая идея: иди разберись потом где стоит сгоревший 12322 и кто коммутирует эту релюху: 7776 или 4455? Классика жанра это переключатели на девайсе для выбора его адреса. Добавление новых устройств тоже простое: смотришь на адрес последнего подключенного и выставляешь на 1 больше.
Вариант с равноправными узлами лучше делать на тайм-слотах, как в CAN - это дает гарантию времени доставки. Рандомные задержки просто сделать, но в аварийной ситуации, когда идут множественные срабатывания всех датчиков сеть будет надежно заблокирована. Можно использовать задержки только если уверен, что одновременно сработает только 1-2 устройства.
0
|
0 / 0 / 0
Регистрация: 11.10.2012
Сообщений: 87
|
|
15.10.2012, 14:48 | 27 |
Сообщение от tid_fom
Хотя вот вариант с АЦП товарища itysiy по-моему очень изобретательный и классный. Только не могут ли помехи, генерируемые одним и тем же источником, приводить к слишком большой системности последовательности?
0
|
0 / 0 / 0
Регистрация: 06.06.2011
Сообщений: 2,514
|
|
15.10.2012, 14:51 | 28 |
Сообщение от modmozy
2. с пропорциональным уменьшением скорости вроде бы всё должно быть не хуже чем у rs485. картинка из стандарта вроде. 10кбит на 5км: <Изображение удалено>
Сообщение от soumt_imobti
там если даже два узла начнут передавать одновременно, передающий узел с низшим приоритетом как только обнаружит что кому-то мешает сразу же это делать перестанет, не испортив при этом пакет передаваемый узлом с более высоким приоритетом, приоритет определяется идентификатором сообщения.
0
|
0 / 0 / 0
Регистрация: 11.10.2012
Сообщений: 87
|
|
15.10.2012, 15:00 | 29 |
Сообщение от soumt_imobti
По поводу способов разрешения коллизий... Вы правы, абсолютная надежность действительно только если мастер один. Кроме того, это проще, а значит сама система надежнее, что очень важно для системы безопасности. Что касается задержек, то можно использовать различные ухищрения и приоритет важности чтобы их минимизировать. Задержка же в одну секунду, мне кажется, вполне допустима. Плюс ко всему, опрос организовать проще, чем разбираться с арбитражем, а затем его еще кучу времени отлаживать и устраивать различные стресс-тесты линии. Это для меня. А для реальности - это дешевле.
0
|
0 / 0 / 0
Регистрация: 11.10.2012
Сообщений: 87
|
|
15.10.2012, 15:12 | 30 |
Сообщение от _pv
И еще после прочтения описания "умного двора" от ShodS я подумал об использовании однопроводного интерфейса. Вроде 1-Wire или что-то в этом роде. Можно просто модулировать биты несущую аля "токовая петля".
0
|
0 / 0 / 0
Регистрация: 12.07.2011
Сообщений: 2
|
|
15.10.2012, 15:47 | 31 |
Сообщение от tymburo
Я САН на 500м без проблем гонял. Скорость 10кБ/с. С выбором адреса переключателями самое правильное. Можно заранее запрограммировать/настроить блоки и задать им адреса. А затем монтажник может ставить эти блоки по местам, используя план здания/местности.
0
|
0 / 0 / 0
Регистрация: 21.08.2011
Сообщений: 1,057
|
|
15.10.2012, 16:56 | 32 |
Переключатели для адреса: дешево, наглядно, не требует инструментов для конфигурации. Подумайте о злом небритом дядьке монтажнике, что ему будет удобнее: подключать каждый модуль к компу и прошивать адрес или зубочисткой переставить дипы, которые играют роль как устройства ввода, так и дисплея? (тачскрин, ага :)).
Если допустима задержка до секунды, то конечно, зачем огород городить с мультимастером? Мастер опрашивает устройства, за секунду успеет тысячу опросить только так. Если совсем хочется просто тогда ASCII Modbus. Удобен тем, что для отладки и управления требуется только терминал. Для длинных линий с низким битрейтом важны хорошие электрические параметры линии, а не протокол. Но конечно сигналы ACK и NACK тоже нужны. Думаю с хорошим кабелем, да терминаторами, на 9600 можно до километра говорить.
0
|
1 / 1 / 0
Регистрация: 01.02.2010
Сообщений: 2,010
|
|
15.10.2012, 20:48 | 33 |
Сообщение от ZPS
Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии. Когда протокол выбирал, то сразу отбросил UART, CAN, 1WIRE: UART - изза того что синхронизация побайтовая, малейшее расхождение частот мастера и слэйва (особенно на повышенных скоростях) будет косить обмен, а потому надо ставить кварц в адресных устройствах, что меня не устраивает. CAN - неоправданно сложный (хотя при желании можно конечно разобраться), он заточен под многомастерную сеть, что совсем лишнее для меня. К тому же это усложнит и удорожит адресные модули. К тому же не вижу вообще, кто бы им овладел нормально, один только Komoptj2010 бьется, бьется об этот CAN, помоему уже разбился об него, давно чегото не видно его..... 1WIRE - на коротких линиях пойдет конечно, но вот на длинных..... а я планировал линии в сотни метров, возможно до километра или более, тут уж лучше от 1WIRE подальше держаться..... В обчем сойстряпал свой протокол (от всего понемногу оттяпал), основанный на кодировании "манчестер". Синхронизируется каждый бит, при этом рассогласование частот мастера и слэйва могут быть достаточно ощутимыми, можно использовать внутренний RC на слэйвах, все прет на ура (мало того, я так обнаглел, что и в мастере кварц не поставил)..... От 1WIRE позаимствовал физическое устройство линии, т.е. линия однопроводная (относительно общего провода), в мастере организована подтяжка к питанию резистором около 1К. Мастер и все адресные устройства передают инфу посредством транзисторного ключа на линии. Это минимизировало потребление слэйвов, оно складывается из потребления контроллера и базового тока ключа во время его открывания, так что можно безболезненно на линию весить много слэйвов (светик используется только во время программирования) В новой версии (в разработке), обмен идет на скоростях 1,2,4,8,16 KByt. Слэйвы устроены так, что читают одновременно на 2-х скоростях, на заданной с мастера и на скорости 1KByt, так что если по каким то причинам слэйв отвалился, мастер попытается с ним связаться на минимальной скорости, если получится, слэйв будет переводится на пониженные скорости работы. Ну и алгоритм обмена: Все посылки пакетные, пакету предшествует пауза размером в половину времени необходимого для передачи байта или более. После обнаружения паузы, все слэйвы ждут начала передачи, Первый байт в пакете - адрес слэйв устройства (1-254), и тот слэйв который идентифицировал свой адрес, продолжает прием, остальные отваливаются. Отваливаются также в случае если видят сброшенным в пакете бит ответа, т.е. этот пакет - ответ слэйва, потому остальным слэйвам он не нужен. После передачи мастера, опять пауза, потом пакет от слэйва (если он предусмотрен), потом пауза, ну и т.д. Структура пакета одинакова при передаче хоть от мастера, хоть от слэйва, разница только в маркере направления передачи, ну и соответственно это отражается на CRC. Код
Структура пакета: 1 байт - адрес слэйв устройства (1-254) 1 байт - биты 0-3: размер блока данных (0-15), передающихся далее за этим байтом (если 0 то значит далее сразу идет CRC) биты 4-6: биты данных (если например достаточно передать до 3-х бит данных, при этом блок данных может отсутствовать) бит 7: маркер направления передачи 1-пакет от мастера, 0-пакет от слэйва N байт - блок данных 1-15 байт 1 байт - CRC аналог CRC в протоколе 1WIRE
0
|
0 / 0 / 0
Регистрация: 12.07.2011
Сообщений: 2
|
|
15.10.2012, 21:48 | 34 |
А можно узнать чем САН сложный? Пришел пакет - получил прерывание и спокойненько смотришь что в нем. Даже торопиться особо не нужно, обычно есть 3-4 ящика (буфера для них). Плюс аппаратная фильтрация - лишнее отсекается само, даже дергаться не нужно.
0
|
0 / 0 / 0
Регистрация: 18.03.2010
Сообщений: 1,112
|
|
15.10.2012, 22:02 | 35 |
Вот на этой картинке можно посмотреть как это реализовано схемотехнически.
0
|
1 / 1 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
|
|
15.10.2012, 22:26 | 36 |
Сообщение от PRS
0
|
1 / 1 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
|
|
15.10.2012, 22:31 | 37 |
Сообщение от tymburo
Хотя вот вариант с АЦП товарища itysiy по-моему очень изобретательный и классный. Только не могут ли помехи, генерируемые одним и тем же источником, приводить к слишком большой системности последовательности? я тоже об этом подумал, пока писал. В голову пришла мысль использовать сгенерированное число еще и для задания случайной задержки перед следующим забором случайного числа из АЦП. Но все же в самом младшем из десяти бит АЦП, который в AVR даже в нормальном режиме работы всякая бяка, чего уж говорить о болтающемся в воздухе входе. Надо бы эксперименты провести и посмотреть распределение случайных чисел по всему диапазону.
0
|
1 / 1 / 0
Регистрация: 01.02.2010
Сообщений: 2,010
|
|
15.10.2012, 23:35 | 38 |
Сообщение от PRS
Это как английский, если не знаеш - он сложный..... а как балакаеш то ерунда..... А незнаком, потому как он мне не нужен пока, я выше перечислил почему. А вообще, если он не сложный, то чего тогда товарищь тут уже 4 страницы исписал, а никто ему так и не помог практически????? Интересно, а вообще есть тут на сайте примеры успешного применения CAN? Чет помоему даже и нету..... вот тебе и не сложный.....
0
|
1 / 1 / 0
Регистрация: 01.02.2010
Сообщений: 2,010
|
|
15.10.2012, 23:41 | 39 |
Сообщение от OmykymForti
Вот у меня схема адресного модуля на тиньке 13-й.
0
|
0 / 0 / 0
Регистрация: 12.07.2011
Сообщений: 2
|
|
15.10.2012, 23:47 | 40 |
Сообщение от itysiy
Сообщение от ShodS
0
|
15.10.2012, 23:47 | |
15.10.2012, 23:47 | |
Помогаю со студенческими работами здесь
40
Какой выбрать протокол Выбрать протокол взаимодействия с сервером Какой протокол лучше выбрать в моей ситуации? Какой протокол выбрать для связи датчиков и сервера на МК? Помогите выбрать физический протокол для линии данных сеть умного дома на stm32: какой протокол выбрать? Какой интерфейс связи выбрать? Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |