Выбрать подходящий интерфейс и протокол

@tymburo · Регистрация: 11.10.2012

Author24 — интернет-сервис помощи студентам

Всем привет!

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

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

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

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

Итак, каковы требования:
1. Все устройства вешаются на одну общую шину. А значит нужно организовать адресацию.
2. Главное устройство должно слать данные другим устройствам, другие устройства должны сами (то есть выступать ведущими) слать данные главному устройству. Слать данные друг другу им не нужно.
3. Физически интерфейс должен быть помехоустойчивый и максимальная длина кабеля должна быть где-то около 500 метров, а лучше километр (не знаю насколько это рационально для системы охраны, но препод настаивает на этом).
4. Ограничений к скорости передачи нет, ибо данных передавать ерунда: одна посылка вряд ли будет больше 2-6 байтов.
5. Было бы не очень хорошо тащить больше 3-5 проводов в кабеле.
6. Ах да, ну и не обязательно: думаю, было бы здорово, если бы интерфейс можно было бы несложно совместить с UART на борту контроллера.

Итак:
1. Какой мне лучше выбрать физический интерфейс?
2. Какие есть стандарты подходящих протоколов передачи поверх этого интерфейса?

Заранее спасибо за помощь!

@ZPS · 16.10.2012, 00:09

Сообщение от tymburo

Сообщение от soumt_imobti

Классика жанра это переключатели на девайсе для выбора его адреса.

да? я вчеракак раз задумался об этом и придумал именно эту идею, однако мне показалось, что это как-то очень топорно, не интеллектуально и не современно :)
Отмирающая классика.
В охранке уже давно отказались - максимум 3 адресных джампера для маленьких систем.
В крупных системах все модули имеют уникальный серийник в явном или неявном виде.
Например, системы paradox все свои модули адресуют по серийникам - первые 3 цифры (HEX) тип модуля дальше 5 его уникальный номер с завода. в хексе это, если не ошибаюсь около 1млн комбинаций. В системах DSC, вечном конкуренте парадокса, серийники идут не явно - для вписывания модуля в систему, надо активировать поиск с клавы и нажать кнопку на модуле - они друг друга услышат, модуль впишется в память под простым порядковым номером. Но если копнуть систему глубже, серийники проявляются, они используются на транспортном уровне, а номерами прикрыты видимо для удобства (весьма сомнительного).

В пожарной охране, протокол xp95 например, датчики адресуются разными способами даже у одного производителя - мой любимый вариант, это 2 крутилки - десятки и единицы. Максимум 99 девайсов на линии. А вот модуля, которые вешаются на линию имеют адреса от 128 и выше и выставляются дип-выключателями (128+выключатели). При этом датчики той же системы от другого производителя, программируются со специального устройства - вкручиваешь туда датчик, забиваешь номер с клавы и он записывается. Есть девайсы, которые автоматически находятся по порядку на линии, а потом по этому временному адресу уже можно править и адреса и настройки.

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

Даю подсказку:
Если прибор идет в серию и забивать номера ручками уже слишком трудоёмко, можно впаять в плату 1-wire девайсы с уникальными номерами и работать с частью этого номера как со своим серийником.

@ZPS · 16.10.2012, 00:21

Сообщение от PRS

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

Не самый правильный в реальном бою :)
Монтажники умудряются путать. Я предпочитаю за монтажниками проходить и сам всё списываю - где по факту что стоит. У парадокса очень грамонтая в этом плане система - на модуле наклейка с серийным адресом и у наклейки отрывной лепесток-наклейка с копией (говно-фото прилагается)
Когда все блоки смонтированы, я беру лесенку, план здания или проект и иду по всей системе - проверяю где именно находится модуль (при монтаже часто сдвигают из-за других коммуникаций), какой именно модуль, сколько на нем по факту зон, есть ли питание, подписи и тп. Отрываю лепесток и клею его на план возле иконки модуля.
Когда весь объект пройден, я иду к компу и по имеющейся схеме программирую систему четко зная какой модуль где.
Когда модуля ставят монтажники, они часто такое делают, что страшно - особенно если в одном ящике 3-4 модуля зонных стоит.

@ZPS · 16.10.2012, 00:39

Сообщение от ShodS

Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии

Спасибо :) у меня примерно те же критерии - без кварца и устойчиво. Но я решил 2 жилы использовать под данные. одна единицы, другая нули. Линии дергаются по очереди, если обе притянуты к нулю - ошибка (наводка, сбой модуля), либо сброс - держу обе линии 2 секунды, модули сбрасываются... но это временно отладочное. Скорость не критична - мастер четко задает 30мкс длину бита и 100мкс между битами. Слейв тупо мониторит линию и если приятнуто дольше 20мкс - бит, если притянуто больше 50мкс- сбой. длина пакета фиксирована - если бит следующей посылки пришел слишком рано - сбой, если слишком долго тишина - сбой. и тд. Вообщем c wiegomd почти всё скопировано :) Мозгов для рассчетов не хватает, всё буду на реальных линиях подгонять - замедлять скорость, если будут сбои. Но пока на 100м витой парой и 5 модулей бегает без сбоев.
Впрочем, это всё тут оффтопик.

@PRS · 16.10.2012, 01:24

ZPS таких монтажников надо сильно, часто и вдумчиво анально карать наказывать.

@ZPS · 16.10.2012, 01:53

Сообщение от PRS

ZPS таких монтажников надо сильно, часто и вдумчиво анально карать наказывать.

Других нет. Я грамотный монтажник, но я не беру монтаж - работать в пыли, грязи и физически напряжно за зарплату в 2 раза ниже чем мой доход сейчас - ну его нафиг. Работодатель берет 2 людей за те же деньги что стою я (без учета, что я за грязь/пыль ещё и 1,5 коэфицент затребую) - шабашники пашут, экономя работодателю кучу денег, не грузят его умными замечаниями вроде "так кабель класть нельзя, минимальный радиус 4 диаметра, в угол забивать нельзя". На выходе получается 6-20к евро экономии на рабочей силе и полный бардак - что-то в обрыве, где-то скорости нет, где-то косяки в программе. Вызывают меня, я день-два ползаю исправляю, привожу всё в порядок, получаю свои несколько сотен евро, а "начальник" считает чистую прибыль - мои услуги редко обходятся ему больше 500 евро, а экономии тысячи. + есть всегда надежда, что шабашники построят нормально и мои услуги не понадобятся. Очень мало клиентов сами мониторят ситуацию и зарубают экономию, чаще они сами заинтересованы в "подешевле" - я когда вижу, что проблема вызвана осознанной и не обоснованной экономией на рабочей силе, наказываю и наказываю сильно - принцип такой.

@tymburo · 16.10.2012, 03:06

ShodS, спасибо за описание вашего интерфейса! Чем-то похоже на I2C, только по одной линии.

Сообщение от itysiy

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

а что, неплохой вариант! несколько увеличит надежность. но вот эксперименты действительно стоило бы провести и посмотреть как все реально выходит, а не в теории.

@Sym · 16.10.2012, 03:49

Сообщение от soumt_imobti

Думаю с хорошим кабелем, да терминаторами, на 9600 можно до километра говорить.

На километровом кабеле, отраженный сигнал будет такой слабый что никак не повлияет на его приём, это же ему надо пройти аж 3 километра, каждый раз ослабляясь на порядок, прежде чем наложится отраженный сигнал на действительный.
Терминаторы скорее для короткого кабеля до 100 метров и высокой скорости, 115200, 900 000. Мне так терминаторы не нравятся тем что ослабляют не только отраженный, но и полезный сигнал, не идеальное, компромиссное решение.
Идеальное решение, похоже, это Ethernet. Другое дело что гигабит полнодуплексный не нужен, если бы эзернет был не только 1000-100-10 мбит, но и 1 мбит, 0.1, 0.01 мбит и по двум проводам...

@Sym · 16.10.2012, 04:10

Сообщение от ZPS

Сообщение от ShodS

Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии

Спасибо :) у меня примерно те же критерии - без кварца и устойчиво. Но я решил 2 жилы использовать под данные. одна единицы, другая нули. Линии дергаются по очереди, если обе притянуты к нулю - ошибка (наводка, сбой модуля), либо сброс - держу обе линии 2 секунды, модули сбрасываются... но это временно отладочное. Скорость не критична - мастер четко задает 30мкс длину бита и 100мкс между битами. Слейв тупо мониторит линию и если приятнуто дольше 20мкс - бит, если притянуто больше 50мкс- сбой. длина пакета фиксирована - если бит следующей посылки пришел слишком рано - сбой, если слишком долго тишина - сбой. и тд. Вообщем c wiegomd почти всё скопировано :) Мозгов для рассчетов не хватает, всё буду на реальных линиях подгонять - замедлять скорость, если будут сбои. Но пока на 100м витой парой и 5 модулей бегает без сбоев.
Впрочем, это всё тут оффтопик.

Очень странный протокол. Сбой что в Modbus, что в Ethernet определяется про контрольной сумме, есть протокол DCON где контрольная сумма просто арифметическая сумма всех символов в посылке, CRC чуть сложнее, но по сути тоже самое. Искать ошибки выделяя для этого отдельный проводник очень расточительно, и менее надежно, если вероятность в CRC32 пропустить сбойную посылку одна 4х миллиардная, то у вас неизвестно, помеха вполне может навести + на одну жилу, - на другую и сбойная инструкция пройдет в устройство, вроде маловероятно, но вероятность как-раз сложно прикинуть, зависит от длины линии, типа помех... сплошное шаманство )))
И другая сторона медали, у вас малейшее отклонение во времени прихода импульса дает сбой, в RS485, Ethernet физический уровень вытягивает любой сигнал, самый слабый, старательно отделяя 0 от 1 на фоне шума, а ошибки надежно вычисляются через CRC. Получается и устойчивей к помехам и защищенней и быстрее, и проводов меньше.

@Sym · 16.10.2012, 04:16

Сообщение от ZPS

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

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

@Sym · 16.10.2012, 04:45

Сообщение от ShodS

Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии.

Лучше бы сделали симметричный Line+ и Line-, что дало бы ацкое повышение в плане помехоустойчивости, так сейчас модно :) всёравно проводов 4 штуки. Если прокачать мастера, то можно этим Line и запитать Slave устройства, 2 провода лучше чем 4, меньше контактов и проще монтаж. В манчестере и полярность роли не играет, монтажникам даже + и - не надо будет различать.

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

Когда протокол выбирал, то сразу отбросил UART, CAN, 1WIRE:
UART - изза того что синхронизация побайтовая, малейшее расхождение частот мастера и слэйва (особенно на повышенных скоростях) будет косить обмен, а потому надо ставить кварц в адресных устройствах, что меня не устраивает.

Если частоты такие нестабильные, можно между байтами делать паузу, чтобы слейвы ориентировались по старт биту, там тогда до 10% можно отклонятся. Можно UART программно ловить, делая коррекцию частоты по приему каждого бита.

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

Да, специфический, редкий протокол, помоему это модбас переросток или Ethernet недоросток :)

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

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

От 1WIRE позаимствовал физическое устройство линии, т.е. линия однопроводная (относительно общего провода), в мастере организована подтяжка к питанию резистором около 1К. Мастер и все адресные устройства передают инфу посредством транзисторного ключа на линии. Это минимизировало потребление слэйвов, оно складывается из потребления контроллера и базового тока ключа во время его открывания, так что можно безболезненно на линию весить много слэйвов (светик используется только во время программирования)

У вас линия не симметричная и готовьтесь каждый манчестерский импульс разряжать километровую линию в 50 000 пф и сопротивлением в 1000 ом, это очень долгий процесс, займет аж 0.05 секунды. При симметричной линии можно запускать импульсы как волны, не дожидаясь перезарядки линии.

Цитата:

В новой версии (в разработке), обмен идет на скоростях 1,2,4,8,16 KByt. Слэйвы устроены так, что читают одновременно на 2-х скоростях, на заданной с мастера и на скорости 1KByt, так что если по каким то причинам слэйв отвалился, мастер попытается с ним связаться на минимальной скорости, если получится, слэйв будет переводится на пониженные скорости работы.

для UART тоже самое можно было бы сделать, тем более если принимать его программно.

Цитата:Ну и алгоритм обмена:
Все посылки пакетные, пакету предшествует пауза размером в половину времени необходимого для передачи байта или более.
После обнаружения паузы, все слэйвы ждут начала передачи, Первый байт в пакете - адрес слэйв устройства (1-254), и тот слэйв который идентифицировал свой адрес, продолжает прием, остальные отваливаются. Отваливаются также в случае если видят сброшенным в пакете бит ответа, т.е. этот пакет - ответ слэйва, потому остальным слэйвам он не нужен. После передачи мастера, опять пауза, потом пакет от слэйва (если он предусмотрен), потом пауза, ну и т.д. Структура пакета одинакова при передаче хоть от мастера, хоть от слэйва, разница только в маркере направления передачи, ну и соответственно это отражается на CRC.

modbus rtu? :) CRC тоже разная бывает, у 1-wire 8 bit, modbus 16 bit, ethernet 32 bit, чем больше тем надежнее. 1 байт маловато иногда.

@Sym · 16.10.2012, 04:55

Сообщение от tymburo

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

У меня сегодня отвалилось устройство сбора данных с теплосчетчика по радиосвязи, оказалось между счетчиком и приемником началась стройка, накопали там холм грунта 4 метра высотой, радиосигнал ослаб и связь оборвалась. Расстояние небольшое, метров 500, антенны низко, в окошках подвалов, вроде было открытое поле и тут возникло препятствие :)
С другой стороны проводную связь тоже рвут и грозы порты выжигают, тоже самое по сути.

@ZPS · 17.10.2012, 01:45

Сообщение от sym

Сообщение от ZPS

Слейв тупо мониторит линию и если приятнуто дольше 20мкс - бит, если притянуто больше 50мкс- сбой. длина пакета фиксирована - если бит следующей посылки пришел слишком рано - сбой, если слишком долго тишина - сбой. и тд.

Очень странный протокол. Сбой что в Modbus, что в Ethernet определяется про контрольной сумме, есть протокол DCON где контрольная сумма просто арифметическая сумма всех символов в посылке...

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

19.10.2012, 10:16

а что если на базе RS485 попробовать , для всей этой большой системы, туда прикрутить протокол DMX512?
было бы интересно использовать готовые модули и микросхемы DMX
плюс перспективы на будущее
печально ,но
самодельный протокол заглохнет после первой работы..

\

@tymburo · 29.10.2012, 20:35

Апаю тему.

Наконец дошли руки до того чтобы заняться организацией интерфейса и сразу встал такой вопрос:

Как надежно организовать передачу данных?

Напомню, что я решил использовать RS485, который на контроллере хочу подцепить к UART.

Система будет с одним мастером, остальные слэйвы.

Вот что я в общих чертах сообразил:

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

А значит, нужно еще отправлять число байт в пакете или какой-то признак конца.

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

@Sym · 29.10.2012, 20:43

Сообщение от tymburo

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

А значит, нужно еще отправлять число байт в пакете или какой-то признак конца.

Вы описали modbus протокол, проще всего:

http://ru.wikipedia.org/wiki/Modbus

Modbus ASCII — для обмена используются только ASCII символы. Для проверки целостности используется однобайтовая контрольная сумма. Начало и конец сообщения помечаются специальными символами (начало сообщения ": ", конец сообщения CR/LF).
...
Общая структура пакета следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):

адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы;

код функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство;

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

блок обнаружения ошибок — контрольная сумма для проверки отсутствия ошибок в кадре.

Максимальный размер для последовательных сетей RS232/RS485 — 256 байт
...

используется довольно давно:

Modbus был разработан компанией Modicon (в настоящее время принадлежит Schneider Electric) для использования в её контроллерах с программируемой логикой. Впервые спецификация протокола была опубликована в 1979 году.

@tymburo · 29.10.2012, 21:56

А какие еще есть варианты организации и где про них можно было бы подробно почитать?

@omooro · 30.10.2012, 00:47

Я недавно думал над подобными велосипедами, протокол поверх полудуплексного rs485. У старых велосипедов колеса как ни посмотри оказываются круглее :)

В голову шли идеи о том, что можно даже адрес не передавать, а ориентироваться по задержке от пакета синхронизации. Ну и ещё какая-то срамота.

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

По теме, мне нравиться ASCII протокол, если скорость не важна.

@Sym · 30.10.2012, 17:45

Сообщение от omooro

В голову шли идеи о том, что можно даже адрес не передавать, а ориентироваться по задержке от пакета синхронизации. Ну и ещё какая-то срамота.

Задержки идея хорошая, но если передавать данные на комп с виндовсом, все задержки теряются, так как в виндах квант времени около 10 мс. Страдает даже modbus rtu, теоретически работать на компе не должен, но работает, похоже производители контроллеров задежки игнорируют. Комп не может проверить, пришел ответ через 0.5 мс или через 20 мс.

@omooro · 30.10.2012, 18:26

Сообщение от sym

Задержки идея хорошая, но если передавать данные на комп с виндовсом, все задержки теряются, так как в виндах квант времени около 10 мс. Страдает даже modbus rtu, теоретически работать на компе не должен, но работает, похоже производители контроллеров задежки игнорируют. Комп не может проверить, пришел ответ через 0.5 мс или через 20 мс.

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

Так же и на примем, идет синхропакет-запрос, а затем ответы от разных устройств с разной (но заранее заданной) задержкой.

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

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

@Sym · 30.10.2012, 21:11

Сообщение от omooro

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

Так же и на примем, идет синхропакет-запрос, а затем ответы от разных устройств с разной (но заранее заданной) задержкой.

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

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

Интересный вариант, но логика работы уже сложнее. Насчет скорости надо прикинуть, всёравно теже ответы к ведущему устройству, таже информация, только в более сложной форме. Надо считать по битам, быстрее ли это вообще будет )

@ZPS 0 / 0 / 0 Регистрация: 16.02.2010 Сообщений: 511
	16.10.2012, 00:09	41
	Сообщение от tymburo Сообщение от soumt_imobti Классика жанра это переключатели на девайсе для выбора его адреса. да? я вчеракак раз задумался об этом и придумал именно эту идею, однако мне показалось, что это как-то очень топорно, не интеллектуально и не современно :) Отмирающая классика. В охранке уже давно отказались - максимум 3 адресных джампера для маленьких систем. В крупных системах все модули имеют уникальный серийник в явном или неявном виде. Например, системы paradox все свои модули адресуют по серийникам - первые 3 цифры (HEX) тип модуля дальше 5 его уникальный номер с завода. в хексе это, если не ошибаюсь около 1млн комбинаций. В системах DSC, вечном конкуренте парадокса, серийники идут не явно - для вписывания модуля в систему, надо активировать поиск с клавы и нажать кнопку на модуле - они друг друга услышат, модуль впишется в память под простым порядковым номером. Но если копнуть систему глубже, серийники проявляются, они используются на транспортном уровне, а номерами прикрыты видимо для удобства (весьма сомнительного). В пожарной охране, протокол xp95 например, датчики адресуются разными способами даже у одного производителя - мой любимый вариант, это 2 крутилки - десятки и единицы. Максимум 99 девайсов на линии. А вот модуля, которые вешаются на линию имеют адреса от 128 и выше и выставляются дип-выключателями (128+выключатели). При этом датчики той же системы от другого производителя, программируются со специального устройства - вкручиваешь туда датчик, забиваешь номер с клавы и он записывается. Есть девайсы, которые автоматически находятся по порядку на линии, а потом по этому временному адресу уже можно править и адреса и настройки. Как техник, я голосую за объединение вариантов - идеальным будет серийный номер вшитый с завода, но должна оставаться возможность смены номера через программатор или особый режим с основной платы - это очень удобно, когда надо заменить сдохший (от грозы/от времени) модуль - не надо лезть в программу и тревожить систему, просто вбил тот же серийник, переключил провода и подал питание - система думает, что модуль просто временно отключали. Даю подсказку: Если прибор идет в серию и забивать номера ручками уже слишком трудоёмко, можно впаять в плату 1-wire девайсы с уникальными номерами и работать с частью этого номера как со своим серийником. 0

@ZPS 0 / 0 / 0 Регистрация: 16.02.2010 Сообщений: 511
	16.10.2012, 00:21	42
	Сообщение от PRS С выбором адреса переключателями самое правильное. Можно заранее запрограммировать/настроить блоки и задать им адреса. А затем монтажник может ставить эти блоки по местам, используя план здания/местности. Не самый правильный в реальном бою :) Монтажники умудряются путать. Я предпочитаю за монтажниками проходить и сам всё списываю - где по факту что стоит. У парадокса очень грамонтая в этом плане система - на модуле наклейка с серийным адресом и у наклейки отрывной лепесток-наклейка с копией (говно-фото прилагается) Когда все блоки смонтированы, я беру лесенку, план здания или проект и иду по всей системе - проверяю где именно находится модуль (при монтаже часто сдвигают из-за других коммуникаций), какой именно модуль, сколько на нем по факту зон, есть ли питание, подписи и тп. Отрываю лепесток и клею его на план возле иконки модуля. Когда весь объект пройден, я иду к компу и по имеющейся схеме программирую систему четко зная какой модуль где. Когда модуля ставят монтажники, они часто такое делают, что страшно - особенно если в одном ящике 3-4 модуля зонных стоит. 0

@PRS 0 / 0 / 0 Регистрация: 12.07.2011 Сообщений: 2
	16.10.2012, 01:24	44
	ZPS таких монтажников надо сильно, часто и вдумчиво анально карать наказывать. 0

@tymburo 0 / 0 / 0 Регистрация: 11.10.2012 Сообщений: 87
	16.10.2012, 03:06	46
	ShodS, спасибо за описание вашего интерфейса! Чем-то похоже на I2C, только по одной линии. Сообщение от itysiy В голову пришла мысль использовать сгенерированное число еще и для задания случайной задержки перед следующим забором случайного числа из АЦП. а что, неплохой вариант! несколько увеличит надежность. но вот эксперименты действительно стоило бы провести и посмотреть как все реально выходит, а не в теории. 0

@omooro 0 / 0 / 0 Регистрация: 11.06.2010 Сообщений: 351
	30.10.2012, 00:47	57
	Я недавно думал над подобными велосипедами, протокол поверх полудуплексного rs485. У старых велосипедов колеса как ни посмотри оказываются круглее :) В голову шли идеи о том, что можно даже адрес не передавать, а ориентироваться по задержке от пакета синхронизации. Ну и ещё какая-то срамота. У ТС требования другие, так что озвучивать выбор под мои требования смысла нет. По теме, мне нравиться ASCII протокол, если скорость не важна. 0

@tymburo 0 / 0 / 0 Регистрация: 11.10.2012 Сообщений: 87
		1
	Выбрать подходящий интерфейс и протокол 14.10.2012, 19:40. Показов 35920. Ответов 59 Метки нет (Все метки) Всем привет! Делаю вот сейчас курсовой проект, в будущем планируется развить все это дело до диплома. И, уже чисто для себя, параллельно намереваюсь собирать в железе все то, что придумываю в курсаче. Чтобы было менее абстрактно, я делаю систему безопасности, состоящую из главного координирующего устройства и цепляющихся к нему устройств. Таких как, например, коммутаторы мощных нагрузок (сигнализации) и концентраторы, к которым, в свою очередь, цепляются охранные извещатели, умеющие только замыкать или размыкать свои контакты при срабатывании. Итак, проблема состоит в следующем: нужно организовать связь между всеми этими устройствами и главным устройством. Велосипед изобретать не только не хочется, но это еще и не рационально. Посмотрел в вики, есть куча подобных интерфейсов и реализованных поверх них протоколов (они, как я понял, входят в группу "промышленных интерфейсов"). Итак, каковы требования: 1. Все устройства вешаются на одну общую шину. А значит нужно организовать адресацию. 2. Главное устройство должно слать данные другим устройствам, другие устройства должны сами (то есть выступать ведущими) слать данные главному устройству. Слать данные друг другу им не нужно. 3. Физически интерфейс должен быть помехоустойчивый и максимальная длина кабеля должна быть где-то около 500 метров, а лучше километр (не знаю насколько это рационально для системы охраны, но препод настаивает на этом). 4. Ограничений к скорости передачи нет, ибо данных передавать ерунда: одна посылка вряд ли будет больше 2-6 байтов. 5. Было бы не очень хорошо тащить больше 3-5 проводов в кабеле. 6. Ах да, ну и не обязательно: думаю, было бы здорово, если бы интерфейс можно было бы несложно совместить с UART на борту контроллера. Итак: 1. Какой мне лучше выбрать физический интерфейс? 2. Какие есть стандарты подходящих протоколов передачи поверх этого интерфейса? Заранее спасибо за помощь! 0

@ZPS 0 / 0 / 0 Регистрация: 16.02.2010 Сообщений: 511
	16.10.2012, 00:39	43
	Сообщение от ShodS Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии Спасибо :) у меня примерно те же критерии - без кварца и устойчиво. Но я решил 2 жилы использовать под данные. одна единицы, другая нули. Линии дергаются по очереди, если обе притянуты к нулю - ошибка (наводка, сбой модуля), либо сброс - держу обе линии 2 секунды, модули сбрасываются... но это временно отладочное. Скорость не критична - мастер четко задает 30мкс длину бита и 100мкс между битами. Слейв тупо мониторит линию и если приятнуто дольше 20мкс - бит, если притянуто больше 50мкс- сбой. длина пакета фиксирована - если бит следующей посылки пришел слишком рано - сбой, если слишком долго тишина - сбой. и тд. Вообщем c wiegomd почти всё скопировано :) Мозгов для рассчетов не хватает, всё буду на реальных линиях подгонять - замедлять скорость, если будут сбои. Но пока на 100м витой парой и 5 модулей бегает без сбоев. Впрочем, это всё тут оффтопик. 0

@ZPS 0 / 0 / 0 Регистрация: 16.02.2010 Сообщений: 511
	16.10.2012, 01:53	45
	Сообщение от PRS ZPS таких монтажников надо сильно, часто и вдумчиво анально карать наказывать. Других нет. Я грамотный монтажник, но я не беру монтаж - работать в пыли, грязи и физически напряжно за зарплату в 2 раза ниже чем мой доход сейчас - ну его нафиг. Работодатель берет 2 людей за те же деньги что стою я (без учета, что я за грязь/пыль ещё и 1,5 коэфицент затребую) - шабашники пашут, экономя работодателю кучу денег, не грузят его умными замечаниями вроде "так кабель класть нельзя, минимальный радиус 4 диаметра, в угол забивать нельзя". На выходе получается 6-20к евро экономии на рабочей силе и полный бардак - что-то в обрыве, где-то скорости нет, где-то косяки в программе. Вызывают меня, я день-два ползаю исправляю, привожу всё в порядок, получаю свои несколько сотен евро, а "начальник" считает чистую прибыль - мои услуги редко обходятся ему больше 500 евро, а экономии тысячи. + есть всегда надежда, что шабашники построят нормально и мои услуги не понадобятся. Очень мало клиентов сами мониторят ситуацию и зарубают экономию, чаще они сами заинтересованы в "подешевле" - я когда вижу, что проблема вызвана осознанной и не обоснованной экономией на рабочей силе, наказываю и наказываю сильно - принцип такой. 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	16.10.2012, 03:49	47
	Сообщение от soumt_imobti Думаю с хорошим кабелем, да терминаторами, на 9600 можно до километра говорить. На километровом кабеле, отраженный сигнал будет такой слабый что никак не повлияет на его приём, это же ему надо пройти аж 3 километра, каждый раз ослабляясь на порядок, прежде чем наложится отраженный сигнал на действительный. Терминаторы скорее для короткого кабеля до 100 метров и высокой скорости, 115200, 900 000. Мне так терминаторы не нравятся тем что ослабляют не только отраженный, но и полезный сигнал, не идеальное, компромиссное решение. Идеальное решение, похоже, это Ethernet. Другое дело что гигабит полнодуплексный не нужен, если бы эзернет был не только 1000-100-10 мбит, но и 1 мбит, 0.1, 0.01 мбит и по двум проводам... 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	16.10.2012, 04:10	48
	Сообщение от ZPS Сообщение от ShodS Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии Спасибо :) у меня примерно те же критерии - без кварца и устойчиво. Но я решил 2 жилы использовать под данные. одна единицы, другая нули. Линии дергаются по очереди, если обе притянуты к нулю - ошибка (наводка, сбой модуля), либо сброс - держу обе линии 2 секунды, модули сбрасываются... но это временно отладочное. Скорость не критична - мастер четко задает 30мкс длину бита и 100мкс между битами. Слейв тупо мониторит линию и если приятнуто дольше 20мкс - бит, если притянуто больше 50мкс- сбой. длина пакета фиксирована - если бит следующей посылки пришел слишком рано - сбой, если слишком долго тишина - сбой. и тд. Вообщем c wiegomd почти всё скопировано :) Мозгов для рассчетов не хватает, всё буду на реальных линиях подгонять - замедлять скорость, если будут сбои. Но пока на 100м витой парой и 5 модулей бегает без сбоев. Впрочем, это всё тут оффтопик. Очень странный протокол. Сбой что в Modbus, что в Ethernet определяется про контрольной сумме, есть протокол DCON где контрольная сумма просто арифметическая сумма всех символов в посылке, CRC чуть сложнее, но по сути тоже самое. Искать ошибки выделяя для этого отдельный проводник очень расточительно, и менее надежно, если вероятность в CRC32 пропустить сбойную посылку одна 4х миллиардная, то у вас неизвестно, помеха вполне может навести + на одну жилу, - на другую и сбойная инструкция пройдет в устройство, вроде маловероятно, но вероятность как-раз сложно прикинуть, зависит от длины линии, типа помех... сплошное шаманство ))) И другая сторона медали, у вас малейшее отклонение во времени прихода импульса дает сбой, в RS485, Ethernet физический уровень вытягивает любой сигнал, самый слабый, старательно отделяя 0 от 1 на фоне шума, а ошибки надежно вычисляются через CRC. Получается и устойчивей к помехам и защищенней и быстрее, и проводов меньше. 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	16.10.2012, 04:16	49
	Сообщение от ZPS Как техник, я голосую за объединение вариантов - идеальным будет серийный номер вшитый с завода, но должна оставаться возможность смены номера через программатор или особый режим с основной платы - это очень удобно, когда надо заменить сдохший (от грозы/от времени) модуль - не надо лезть в программу и тревожить систему, просто вбил тот же серийник, переключил провода и подал питание - система думает, что модуль просто временно отключали. Это по типу Ethernet, MAC адрес прошит в устройстве изначально, каждый брэндовый производитель оборудования покупает диапазон маков и вносится в базу. Но при желании почти все маки меняются, и не надо тревожить админов меняя сгоревшую сетевую карту, по мак адресу выдается IP адрес и работа продолжается. 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	16.10.2012, 04:45	50
	Сообщение от ShodS Линия 3-х проводная: +12v, COM, ну и соотв-но Line. Т.к. кабели обычно 4-х жильные, то на общий я цепляю две жилы, это еще больше увеличивает нагрузочную способность линии. Лучше бы сделали симметричный Line+ и Line-, что дало бы ацкое повышение в плане помехоустойчивости, так сейчас модно :) всёравно проводов 4 штуки. Если прокачать мастера, то можно этим Line и запитать Slave устройства, 2 провода лучше чем 4, меньше контактов и проще монтаж. В манчестере и полярность роли не играет, монтажникам даже + и - не надо будет различать. С другой стороны манчестер медленней UART, так как передает 2 импульса на бит, вместо 1. Когда протокол выбирал, то сразу отбросил UART, CAN, 1WIRE: UART - изза того что синхронизация побайтовая, малейшее расхождение частот мастера и слэйва (особенно на повышенных скоростях) будет косить обмен, а потому надо ставить кварц в адресных устройствах, что меня не устраивает. Если частоты такие нестабильные, можно между байтами делать паузу, чтобы слейвы ориентировались по старт биту, там тогда до 10% можно отклонятся. Можно UART программно ловить, делая коррекцию частоты по приему каждого бита. CAN - неоправданно сложный (хотя при желании можно конечно разобраться), он заточен под многомастерную сеть, что совсем лишнее для меня. К тому же это усложнит и удорожит адресные модули. К тому же не вижу вообще, кто бы им овладел нормально, один только Komoptj2010 Да, специфический, редкий протокол, помоему это модбас переросток или Ethernet недоросток :) 1WIRE - на коротких линиях пойдет конечно, но вот на длинных..... а я планировал линии в сотни метров, возможно до километра или более, тут уж лучше от 1WIRE подальше держаться..... От него и на коротких лучше подальше держаться, 10 метров надежно дальше как повезет. От 1WIRE позаимствовал физическое устройство линии, т.е. линия однопроводная (относительно общего провода), в мастере организована подтяжка к питанию резистором около 1К. Мастер и все адресные устройства передают инфу посредством транзисторного ключа на линии. Это минимизировало потребление слэйвов, оно складывается из потребления контроллера и базового тока ключа во время его открывания, так что можно безболезненно на линию весить много слэйвов (светик используется только во время программирования) У вас линия не симметричная и готовьтесь каждый манчестерский импульс разряжать километровую линию в 50 000 пф и сопротивлением в 1000 ом, это очень долгий процесс, займет аж 0.05 секунды. При симметричной линии можно запускать импульсы как волны, не дожидаясь перезарядки линии. Цитата: В новой версии (в разработке), обмен идет на скоростях 1,2,4,8,16 KByt. Слэйвы устроены так, что читают одновременно на 2-х скоростях, на заданной с мастера и на скорости 1KByt, так что если по каким то причинам слэйв отвалился, мастер попытается с ним связаться на минимальной скорости, если получится, слэйв будет переводится на пониженные скорости работы. для UART тоже самое можно было бы сделать, тем более если принимать его программно. Цитата:Ну и алгоритм обмена: Все посылки пакетные, пакету предшествует пауза размером в половину времени необходимого для передачи байта или более. После обнаружения паузы, все слэйвы ждут начала передачи, Первый байт в пакете - адрес слэйв устройства (1-254), и тот слэйв который идентифицировал свой адрес, продолжает прием, остальные отваливаются. Отваливаются также в случае если видят сброшенным в пакете бит ответа, т.е. этот пакет - ответ слэйва, потому остальным слэйвам он не нужен. После передачи мастера, опять пауза, потом пакет от слэйва (если он предусмотрен), потом пауза, ну и т.д. Структура пакета одинакова при передаче хоть от мастера, хоть от слэйва, разница только в маркере направления передачи, ну и соответственно это отражается на CRC. modbus rtu? :) CRC тоже разная бывает, у 1-wire 8 bit, modbus 16 bit, ethernet 32 bit, чем больше тем надежнее. 1 байт маловато иногда. 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	16.10.2012, 04:55	51
	Сообщение от tymburo По поводу радиосвязи - у меня была идея использовать ее, но не как главное средство связи. У меня сегодня отвалилось устройство сбора данных с теплосчетчика по радиосвязи, оказалось между счетчиком и приемником началась стройка, накопали там холм грунта 4 метра высотой, радиосигнал ослаб и связь оборвалась. Расстояние небольшое, метров 500, антенны низко, в окошках подвалов, вроде было открытое поле и тут возникло препятствие :) С другой стороны проводную связь тоже рвут и грозы порты выжигают, тоже самое по сути. 0

@ZPS 0 / 0 / 0 Регистрация: 16.02.2010 Сообщений: 511
	17.10.2012, 01:45	52
	Сообщение от sym Сообщение от ZPS Слейв тупо мониторит линию и если приятнуто дольше 20мкс - бит, если притянуто больше 50мкс- сбой. длина пакета фиксирована - если бит следующей посылки пришел слишком рано - сбой, если слишком долго тишина - сбой. и тд. Очень странный протокол. Сбой что в Modbus, что в Ethernet определяется про контрольной сумме, есть протокол DCON где контрольная сумма просто арифметическая сумма всех символов в посылке... Это я описал физический уровень. На него сверху наложена некоторая логика и там есть проверка - контрольная сумма по битам считается и передается отдельно для адреса и отдельно для данных. На тестовых платах есть светодиоды, которые светятся некоторое время после получения ошибки на физическом и на логическом уровне - по ним я могу мониторить примерно насколько стабилен такой вариант. Если не устроит, перейду на какую-нибудь проверенную годами классику. Впрочем, переход на однопроводную линию уже маячит - анализ рынка подсказывает, что таких вариантов линий будет много и под них всё равно что-то надо делать. 0

Скрипич
	19.10.2012, 10:16	53
	а что если на базе RS485 попробовать , для всей этой большой системы, туда прикрутить протокол DMX512? было бы интересно использовать готовые модули и микросхемы DMX плюс перспективы на будущее печально ,но самодельный протокол заглохнет после первой работы.. \

	30.10.2012, 21:11

@tymburo 0 / 0 / 0 Регистрация: 11.10.2012 Сообщений: 87
	29.10.2012, 20:35	54
	Апаю тему. Наконец дошли руки до того чтобы заняться организацией интерфейса и сразу встал такой вопрос: Как надежно организовать передачу данных? Напомню, что я решил использовать RS485, который на контроллере хочу подцепить к UART. Система будет с одним мастером, остальные слэйвы. Вот что я в общих чертах сообразил: Передача, по-видимому, будет пакетной. В пакете должен быть один байт адреса и, я думаю, изменяющееся число байт данных. Для простых команд от мастера к слейву хватит скорее всего и одного байта, но если, к примеру, слейв будет отправлять пакет мастеру с кучей информации и отчетом о том что вообще вокруг него происходит, то байт понадобится больше. А значит, нужно еще отправлять число байт в пакете или какой-то признак конца. Я уже придумал парочку вариантов и парочку придумал мой друг, однако все они мне кажутся набором костылей и велосипедов. Хотелось бы узнать, как грамотно и надежно (то есть с обработкой различных ошибок и сбоев) организовать передачу и как вообще обычно передачу организовывают. 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	29.10.2012, 20:43	55
	Сообщение от tymburo Передача, по-видимому, будет пакетной. В пакете должен быть один байт адреса и, я думаю, изменяющееся число байт данных. Для простых команд от мастера к слейву хватит скорее всего и одного байта, но если, к примеру, слейв будет отправлять пакет мастеру с кучей информации и отчетом о том что вообще вокруг него происходит, то байт понадобится больше. А значит, нужно еще отправлять число байт в пакете или какой-то признак конца. Вы описали modbus протокол, проще всего: http://ru.wikipedia.org/wiki/Modbus Modbus ASCII — для обмена используются только ASCII символы. Для проверки целостности используется однобайтовая контрольная сумма. Начало и конец сообщения помечаются специальными символами (начало сообщения ": ", конец сообщения CR/LF). ... Общая структура пакета следующая (в зависимости от реализации, некоторые из полей могут отсутствовать): адрес ведомого устройства — адрес подчинённого устройства, к которому адресован запрос. Ведомые устройства отвечают только на запросы, поступившие в их адрес. Ответ также начинается с адреса отвечающего ведомого устройства, который может изменяться от 1 до 247. Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство, адреса в диапазоне 248…255 — зарезервированы; код функции — это следующее однобайтное поле кадра. Оно говорит ведомому устройству, какие данные или выполнение какого действия требует от него ведущее устройство; данные — поле содержит информацию, необходимую ведомому устройству для выполнения заданной мастером функции или содержит данные, передаваемые ведомым устройством в ответ на запрос ведущего. Длина и формат поля зависит от номера функции; блок обнаружения ошибок — контрольная сумма для проверки отсутствия ошибок в кадре. Максимальный размер для последовательных сетей RS232/RS485 — 256 байт ... используется довольно давно: Modbus был разработан компанией Modicon (в настоящее время принадлежит Schneider Electric) для использования в её контроллерах с программируемой логикой. Впервые спецификация протокола была опубликована в 1979 году. 0

@tymburo 0 / 0 / 0 Регистрация: 11.10.2012 Сообщений: 87
	29.10.2012, 21:56	56
	А какие еще есть варианты организации и где про них можно было бы подробно почитать? 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	30.10.2012, 17:45	58
	Сообщение от omooro В голову шли идеи о том, что можно даже адрес не передавать, а ориентироваться по задержке от пакета синхронизации. Ну и ещё какая-то срамота. Задержки идея хорошая, но если передавать данные на комп с виндовсом, все задержки теряются, так как в виндах квант времени около 10 мс. Страдает даже modbus rtu, теоретически работать на компе не должен, но работает, похоже производители контроллеров задежки игнорируют. Комп не может проверить, пришел ответ через 0.5 мс или через 20 мс. 0

@omooro 0 / 0 / 0 Регистрация: 11.06.2010 Сообщений: 351
	30.10.2012, 18:26	59
	Сообщение от sym Задержки идея хорошая, но если передавать данные на комп с виндовсом, все задержки теряются, так как в виндах квант времени около 10 мс. Страдает даже modbus rtu, теоретически работать на компе не должен, но работает, похоже производители контроллеров задежки игнорируют. Комп не может проверить, пришел ответ через 0.5 мс или через 20 мс. Предполагалось, что управляющее устройство шлет данные одним куском в котором блоки предназначенные для разных устройст разделены заполнителем, например 0xFF. В начале блока синхропакет. Какая будет задержка отправки этого куска данных неважно, главное чтобы переадавалось без разрывов. Ведомые устройства видя синхрокапет запускают таймер и отключается от примема на определенный период времени. Так же и на примем, идет синхропакет-запрос, а затем ответы от разных устройств с разной (но заранее заданной) задержкой. Неторопливойть ведущего не должна помешать, на уровне передачи данных. Но мне все таки кажется это не надежным, особенно если надо делать передачу и примем сотню раз в секунду. Аппаратная проверка 9-го бита (для примера) как-то более грубо выглядит, меньше вероятность того, что все развалится из-за ошибки или неверной конфигурации. Хотя использовать задержки на прием мне все ещё кажется хорошей идеей, чтобы избежать посылки запросов каждому устройству. 0

@Sym 1 / 1 / 0 Регистрация: 16.12.2016
	30.10.2012, 21:11	60
	Сообщение от omooro Предполагалось, что управляющее устройство шлет данные одним куском в котором блоки предназначенные для разных устройст разделены заполнителем, например 0xFF. В начале блока синхропакет. Какая будет задержка отправки этого куска данных неважно, главное чтобы переадавалось без разрывов. Ведомые устройства видя синхрокапет запускают таймер и отключается от примема на определенный период времени. Так же и на примем, идет синхропакет-запрос, а затем ответы от разных устройств с разной (но заранее заданной) задержкой. Неторопливойть ведущего не должна помешать, на уровне передачи данных. Но мне все таки кажется это не надежным, особенно если надо делать передачу и примем сотню раз в секунду. Аппаратная проверка 9-го бита (для примера) как-то более грубо выглядит, меньше вероятность того, что все развалится из-за ошибки или неверной конфигурации. Хотя использовать задержки на прием мне все ещё кажется хорошей идеей, чтобы избежать посылки запросов каждому устройству. Интересный вариант, но логика работы уже сложнее. Насчет скорости надо прикинуть, всёравно теже ответы к ведущему устройству, таже информация, только в более сложной форме. Надо считать по битам, быстрее ли это вообще будет ) 0