Arduino.ru

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

В "Проектах" уже есть такая тема, почитайте http://arduino.ru/forum/proekty/ocherednoi-umnyi-dom-na-etot-raz-modulnaya-sistema

Я там подключился к обсуждению вот с этой страницы: http://arduino.ru/forum/proekty/ocherednoi-umnyi-dom-na-etot-raz-modulnaya-sistema?page=13  Повторять все сказанное там не стану, только коротко:

- шинные формирователи (трансиверы) надо ставить не RS-485, а CAN, потому что RS-485 не расчитан на коллизии на шине

- скорость обмена надо выбрать низкую, например, 19.2 кбит/сек, тогда провода можно соединять как угодно, а терминатор достаточно поставить один где-то в центре; чтобы уменьшить "звон" лучше ставить трансиверы с замедленными фронтами переключения, например, MCP2551

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

triac, Logik  Спаюсибо за ссылку, я все перечитаю.

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

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

С терминологией у меня уже плохо, позабывал все, хотя я программист уже 15 лет, направление совсем в другую сторону. Главное что вы меня поняли.

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

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

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

 

 

Питание у него 5В.  А годится для работы в автомобилях с 12В и 24В бортовым питанием. Другими словами, держит кз интерфейсных линий на 24 В.  Он вообще держит до +-42 В.

А зачем это надо, если на 100% все эти проблемы решаются если просто использовать CAN трансивер? Который со стороны микроконтроллера вообще ничем не отличается. К тому же не дороже RS485 трансивера и более устойчив ко всяким издевательствам. Проще говоря, его сжечь труднее.

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

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

triac,  

спасбио это уже интереснее раз 5вольтовый...

Начинаю гуглить но много мусора попадает по arduino can bus

Есть ли более правильное у него название ? примеры реализации ?

я пока не могу найти ни придельную дальность, ни топологии, ни аналоги MCP2551

Библиотеки для работы по CAN ?

Если не затрудниит, не могли бы тыкнуть ? 

спасибо 

tosic,

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

Я вам не предлагаю CAN bus, упаси господи. С ней геморроя не оберешься. Я всего лишь предлагаю вместо трансиверов RS485 использовать трансиверы CAN, это все. А обмен делать при помощи обычного UART, никаких CAN контроллеров и библиотек не надо.

На скорости 19.2 кбит/сек при произвольной топологии суммарная длина кабеля не более примерно 1 км.

Аналоги можете посмотреть здесь: http://ru.farnell.com/w/c/semiconductors-ics/drivers-interfaces/can-bus-devices?no-of-tx-buffers=1&range=inc-in-stock|exc-obs&st=CAN

По мне дак это нормальный рабочий процесс разработки чего либо. НИКОГДА ничего сразу ни у кого нормально не работает. Иначе откуда взялись такие понятия как обновление ПО, новые аппаратные ревизии железа, наладка, отстройка , бета версии и т.д.
Косяки всплывают и во время разработки и во время эксплуатации и это нормальное явление.

MCP2551 - это трансивер CAN, который по своей функции соответствует любому трансиверу RS-485, например, MAX485 или SN75176 и т.п. Если примените его, то у вас коллизий на шине не будет, и  спалить его труднее, в этом все отличие от трансивера RS-485. Работать с ним можно от любого UART.

MCP2515 - это контроллер CAN. С ним работать трудно. Связь с микроконтроллером - через SPI. Сначала будете искать либы, а потом бодаться с описаниями CAN bus, даташитом MCP2515 и кривыми описаниями либ. И долго чесать репу, как все это применить под вашу задачу. Потом найдете CanFestival или подобный, будете вникать, а потом наконец поймете что на 8-битный Ардуино это не лезет, ресурсов не хватает. И останетесь у разбитого корыта.

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

triac, спасибо. займусь прототипами. 

Посже напишу результаты. пока закажу все =0)

С чего решили что MCP2551 обеспечивает подавление коллизий? В его даташите такого нет, он действительно функционально соответствует MAX485: преобразование логического уровня в  дифференциальный сигнал и обратно. А борьба с коллизиями - это "В случае одновременной передачи кадров двумя и более узлами проходит арбитраж доступа: передавая идентификатор, узел одновременно проверяет состояние шины. Если при передаче рецессивного бита принимается доминантный — считается, что другой узел передаёт сообщение с большим приоритетом, и передача откладывается до освобождения шины." Этого MCP2551 не умеет.  Получается что и для 485 и для CAN борьбу с коллизиями прийдется делать програмно.

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

 

Говорили про коллизии, а приводите текст про арбитраж доступа. :)

Чисто программно обычный микроконтроллер с обычным UART коллизий избежать не сможет. На физическом уровне коллизий не будет, а на логическом столкновение двух передатчиков все-таки приведет к порче информации.

Для того, чтобы избежать коллизий, нужна поддержка соответствующего железа, которое на битовом уровне обнаруживает логическую коллизию и мгновенно отключает передатчик. Это умеют делать контроллеры CAN (например, как упоминавшийся MCP2115), это умеет MAU интерфейса  KNX/EIB, и т.п.  Даже при помощи блоков CLC в составе некоторых PIC микроконтроллеров это тоже можно сделать.

Без аппаратной поддержки, чисто программно, на одном только UART избежать коллизий (это называется CSMA/CA) не удастся. Однако с CAN трансиверами будет очень легко коллизии обнаруживать (это называется CSMA/CD).

Впрочем, есть еще один способ, назовем его "гибридным". Он состоит в том, чтобы сделать UART программно, используя внешние прерывания, таймеры и т.п. Скорости большой трудно получить, да она и не нужна, зато UART с  CSMA/CA обеспечить можно без поддержки специального железа.

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

//А вот с трансиверами RS485 при произвольном доступе к сети коллизии и избежать невозможно, и обнаружить трудно, и при столкновении токи на выходах и в питании  будут как при коротком замыкании или даже хуже.

Токи не составляют проблемы. Согласно стандарту 485-го передатчик должен выдерживать КЗ. И коллизии собственно тоже обнаруживаются всегда средствами контроля целостности пакета.

//Говорили про коллизии, а приводите текст про арбитраж доступа. :)

А арбитраж - он как раз при коллизиях и случается. И протокол CAN  расчитан что, продолжу цитату

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

Коллизии будут! Чтоб их не было, Вы верно пишите

Ну и далее правильно вобщем. Но еще раз, повторюсь MCP2551 сам по себе без програмной доработки от колизий не избавит. 

 

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

В любом случае это создаст дополнительные помехи и головную боль при разработке.

Вы определитесь о каких коллизиях и в каком контексте вы говорите.

Физических коллизий не будет.

Про логические коллизии я уже описал выше, будут или не будут - зависит от реализации UART-а и дополнительной аппаратной поддержки. 

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

//в каком контексте вы говорите.

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

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

//это тоже можно рассматривать как коллизию.

Пока тут можна рассматривать как колизию только ваши сообщения.

 

При том, что, к примеру, Ардуино Мини Про с регулятором 78L05 на на номинальный ток 100 мА, при коллизии  питаемого им RS485 драйвера не сможет выдать требуемый ток. В результате чего питание просядет и Ардуино уйдет в ресет.

А что вообще знает гугл о коллизиях? Если по-русски и  по теме - то, что есть в википедии:

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

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

Вы ошибаетесь, считая "эту фишку" (иначе называемую CSMA/CA) экслюзивом CAN, при условии, если вы знаете, что означает слово "экслюзив". А в просторечьи оно означает, что никто другой этим свойством не обладает. Чтобы опровергнуть "экслюзивность" CSMA/CA, якобы присущей только CAN и никому другому, достаточно привести пример хотя бы одного интерфейса, который тоже обладает свойствами CSMA/CA.

Я приведу два примера: KNX/EIB и проводной C-Bus.  Это не все примеры, но двух, пожалуй, будет достаточно.

В свете сказанного, вам, как Logik-у, логично было бы впредь не приписывать в этом смысле эксклюзивность CAN-у.

... а если к примеру  ТЭЦ то 3000МВт. Ни где не заявлен ни Мини, ни без БП на 5В. Это вобще было бы странно. Кончайте балаболствовать вопрос только один.

 

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

возможно тогда действительно в MCP2551 нет особого резона.

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

А именно Rh Rl GND V+ и общий провод. Перед вещание устройство проверяет не занята ли линия, если нет, подает + на эти линию, ждем 5мс, начинаем вещать, ждем 5мс, отключаем. Для 19.2к это не существенно, но сделает проже программу и свидет все до минимум в частности коллизии . ) У некоторый в интернете видел примеры такой реализации и на urart и на 232 и на 485 и на кан.
Минусов такой реализации я не вижу, разче что + 1 жила провода и чуть дольше по времени. но ведь учитывая то  что в повторение пакета уже будет крайне мала, то ризон в этом есть . что думаете ? 

про 485 я уже забыл, как страшный сон. приимущество кан, на лицо =) 

Думаю нет резону. Достаточно аккуратно протокол писать, с проверкой CRC, подтверждением приема  и повторными попытками передачи через некоторые продуманные паузы. Дело в том что кроме коллизий есть еще достаточно гадостей способных нарушить обмен. Для борьбы с ними всеравно прийдется вышеперечисленное делать. Это что для RS485, что для псевдо-CAN на MCP2551 (псевдо- т.к. от CAN только физический уровень есть, а спека на CAN требует и более высокие их програмно в ардуине не просто делать).

//Перед вещание устройство проверяет не занята ли линия, если нет, подает + на эти линию, ждем 5мс, начинаем вещать,

А другое устройство в это же время делает тоже самое ))) Это и есть коллизия. Вероятность невелика, но есть. Уж лучше арбитраж как в CAN делать, на монтажном И. Почитайте о этом, оно даже интересно.

Так, значит все-таки заморочил вам этот тролль голову своей демагогией... Есть резон.

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

При широковещательном обмене нет возможности "подтверждать прием", просто некому это делать. Максимум что можно - выдавать негативное подтверждение, NACK. И при этом быть готовым к тому, что много узлов будут выдавать NACK-и одновременно. С трансиверами RS485 все это превращается в полный абсурд.

Поэтому на RS485 вы скатитиесь к "мастер-слэйву", то есть, опять к Модбасу.

Та ну!! )))

Начнем с определений.

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

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

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

Все одновременно? Но они не синхронизированы, столкновения передатчиков неизбежны, ACK не дойдет.

В разное время? А откуда они знают, кому в какое время надо отправлять ACK? Это задается при конфигурировании сети? Скажем, все 50 узлов настроить так, чтобы они передавали ACK в своем временном слоте, с нужными паузами между передачами, чтобы исключить столкновения. Мало того, что это дикий геморрой при настройке, вдобавок это и дикий тормоз тоже: все должны сидеть и слушать, пока все AKC-и не будут переданы, новое широковещательное сообщение в это время передавать нельзя. А откуда все знают, сколько времени нельзя? Еще один параметр настройки сети? Причем вероятность потери ACK-а растет с ростом количества узлов, поэтому начиная с десятка-другого узлов в сети вреда от ACK-ов становится больше чем пользы: в зашумленной сети вероятность потери ACK-а становится намного больше, чем вероятность порчи основного сообщения. Поэтому источник широковещательного сообщения прежде всего потеряет один из ACK-ов и будет  повторять свое сообщение снова и снова, хотя все узлы будут его правильно принимать и давать ACK.

Оба варианта - полный абсурд, поэтому никто так и не делает. Модбас в разы проше, а по скорости не особо уступит этой замороченной бредятине с ACK-ами.

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

И не просто ACK отправляется, там можна и кое что еще, например датчик может сразу и свой параметр отправить, т.е. одним широковещательным запросом типа "дайте температуру" получим температуру от всех термометров, а если кто промолчал - спросим его отдельно. Все просто. Почитайте чего по теории и практике сетей, там много мудрого, а мне лень Вашим образованием заниматся. Все чего я хотел - бредовость утверждения "MCP2551 обеспечивает подавление коллизий" донести. А то люди читают разные, начнут их вместо MAX485 впаивать и расчитывать что коллизий уже нет.

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

Весь этот вымученный бред с RS-485 и ACK-ами идет прямиком в помойку при использовании шинных формирователей CAN.  По той простой причине, что с ними физических коллизий на шине не будет, сколько бы вы ни пытались утверждать обратное.

А при отсутствии коллизий подтверждение широковещательного обмена элементарно делается NACK-ом. Например, передаваемым в один и тот же момент времени всеми "не расслышавшими" узлами символа  0xFF. Если источник услышит хоть что-то в этот момент - он повторит передачу.

Ну а самое важное, что при использовании трансиверов CAN становится возможным реализовать CSMA/CD, обнаружение логических коллизий, что невозможно сделать при использовании трансиверов RS-485. Ибо с RS-485, даже с бессмысленными ACK-ами, невозможно отличить одновременную работу нескольких широковещательных передатчиков от просто испорченного помехой сообщения.

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

Можно, такой интерфейс называется RS-422 и применяется так же весьма широко. Есть под него и спец микросхемы. Кроме того при перемыкании выходов и соотв управлении он легко превращается в RS-485.

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

Так 422 точка-точка т.е. для связи двух устройств. На крайняк одного передатчика и и группы приемников. Сеть как ТС хочет на нем не получится.

Подскажите, достаточно-ли такой обвязки для связи двух ардуин?

Ммм? Подскажите)

Не работает конструкция или какие-либо иные проблемы?

Почему нет? Для двух даже резисторы не нужны. Ну а так, всё же ж расписано. http://masters.donntu.org/2004/fema/kovalenko/library/art7.html

Да, достаточно, вот только 120 Ом для второй не нужно. Достаточно одного резистора на две платы связи. Может оказаться что и на первой не нужно. Это зависит от длины и типа кабеля. На коротких можно оставить оба, на километровых может оказаться что без резисторов 120 Ом будет лучше если скорость связи не большая. Соедините и проверьте как есть. У меня на 115200 на 50 метрах витой пары с двумя резисторами работает без потерь пакетов в условиях сильных помех. 

Пробую. Хотела что-бы сразу всё было хорошо.

 

Спасибо.

Если источники питани устройств разные или шина длинная, то такой схемы недостаточно !

Обвязку линии берите вот из этой схемы https://media2.24aul.ru/imgs/538f27301252081aec927fc0/max485csa-max485-rs-485-rs485-maxim-smd-sop-8-max485csa-3-4168969.jpg

Спасибо

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

Да-да, так и есть.

А для чего LM555N?

Универсальный таймер на миллион применений. Есть даже программы по расчёту режимов.Типа https://houseofjeff.com/555-timer-oscillator-frequency-calculator/  

Не так спросила. Для чего он нужен в представленной выше схеме)

Чтобы сформировать TE RE. Если не вдаваться в подробности картинки, то такое включение 555ого читается так:

При переходе с 1 в 0 на входе TR поднять из 0 в 1 выход Q, При переходе обратно из 1 в 0 на входе TR держать выход Q высоким еще 40 мкс.

========если интересно================

40 мкс это 3.9К * 0.01 мкФ *1.1 = 43 мкс. Точность там не сильно важна. Так что 40 мкс - это примерно. В реальности - от 35 до 50.

С7 Д8 и С16 на картинке - дань правилам проектирования. С7 - из типовой схемы включения... не нужно спрашивать его смысл ;) - типа дополнительный фильтр. С16 - стандартный фильтр питания, Д8 - чтобы TR не висел в ввоздухе при отключенном микроконтроллере и чтобы разрядить С8 при 0 на входе TR..

Всё ясно?

В этой схеме 555 нужна если Вы не управляете направлением передачи с помощью микроконтроллера. 555 включает передачу на время одного символа. Если Те Re подключены к микроконтроллеру то всё что относится к 555 можно выбросить. 

У меня приёмом и передачей управляет МК.

Оставляю так?

 

 

RE/DE тоже заводятся на МК.

Ну-да, просто не дорисовала.

Резисторы в протоколе RS485 всегда желательно оставлять. По идее витая пара является длинной линией, со всемы вытекающими отсюда последствиями, когда длина волны в кабеле меньше длины самого кабеля. При частоте 9000 герц длина волны в кабеле будет 25 километров, при коэффициенте укорочения 1,4 примерно.   С одной стороны частота импульсво относительно не высокая, но спект его куда более высок, учитывая близку к прямоугольной форму, так что мы получаем отражения, перемещающиеся от одного конца к другому, и нарвемся на ошибки. Точнее они не гарантированы, но вероятность их больше. Тем более для домашних проектов на малом расстоянии мы выгодно можем использовать большую скорость, по той причине, что если устройств больше чем 2, то управляющее устройство должно опрашивать подчиненные, а это возможно нужно быдет сделать побыстрее, чтобы не пришлось ждать, когда же включится свет к примеру. 
Когда у нас подключен резистор с сопротивлением равному волновому сопротивлению витой пары, отражений практически не будет. И он должен быть с каждой стороны, т.к. отражаться сигналы будут от ненагруженного конца. Просто по всей линии туда сюда постепенно ослабевая перемещаться не будут. 
 

А почему стабилитроны на 13 Вольт?

А с уровнями стандарта RS-485 никакой связи не прослеживается?

Напряжение‎: ‎-7 В до +12 В

А как хорошо начиналось...

проводная сеть из множества arduino по витой паре с протоколом RS485

Но весь пар выпустили на "коллизии" 

И где же теперь:

"...Обязательно напишу результаты..."?

еще в процессе )