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

1. Использовать сложный в аппаратном, но легкий в программном плане CAN _надежнее_ того же RS-485 с программными "ухищрениями" для получения соизмеримой вероятности необработанной ошибки. Ибо, программист грешен и допускает ошибки.

2. Защита от дурака усложняет, но надежность от этого увеличивается.

3. Распределенная система (CAN) по числу элементов может быть и меньше централизованной на RS-485... Если отказом считать невозможность нормально функционировать какому-то отдельно взятому узлу, то в случае CAN надежность равна надежности одного узла; в случае с RS-485 сумме всех узлов. Например, промышленный модуль I-7015 при "слете" прошивки на ногах проца имеет такой потенциал, что продолжает висеть на шине с _включенным_ передатчиком RS-485. Сеть при этом глючит - найти кто виноват в этом случае, на объекте, в условиях, за потолком или в теплоузле, мягко говоря... !

4. Если речь идет о "контроллере светодиода", то микросхемы тут не нужны - тупо включатель и провода (надежнее не придумаешь).

5. Контроллер для умного дома или _сети_ уже подразумевает под собой нечто сложное. Ресурса tn13 может не хватить (сейчас или в будущем). Прыгать по камушкам - затратно.

6. tn13 - шикарные микросхемы! ) Постоянно держу неснижаемый остаток штук 50. Пихаю везде, где только можно

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


Недежность ПО падает, т.к. каждый "if" в программе это дополнительный риск возможного глюка.


Неправда, с RS-485 надежность определяется надежностью одного самого сложного устройства - Мастера.


Пример мимо кассы, и CAN можно запороть неадекватным (несовместимым со стандартом) железом, шина общая ведь и там.


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


Контроллер для умного дома - это несомненно сложная программа возможно на PC, или в центральном устройстве управления. А модуль на t13 это всего лишь исполнительный блок, выполняющий строго свою одну функцию - вкл./отлк свет и возможно менять яркость по команде от мастера. Даже если поменяется устройство управления в будущем, перекроить всю систему, то этот исполнительный блок на t13 все равно будет продолжать выполнять всё ту же функцию - вкл/откл свет и задать яркость. Ничего нового туда не добавится, ибо для управления освещением набор функций по определению ограничен только этими двумя действиями - вкл/откл и яркость.


это да порой незаменимый кусочек железа ;>

При использовании в CAN девайсах современных защищённых приёмопередатчиков, с ограничение времени доминанты (0), вероятность подвешивания всей сети одним девайсом несоизмеримо меньше, чем при использовании сети с RS485 приёмопередатчиками, которые, к тому же, могут подвешивать сеть и 0 и 1.
Хотя, ради справедливости нужно сказать, что если в модбасе заменить все приёмопередатчики на CAN-овские, эффект будет то же. Но это возможно только при использовании достаточно высокой скорости.

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

Не надо пытаться делать вещи проще, чем они того заслуживают. Табурет с 3 ногами устойчивее лишь в теории; 5 ног - явный перебор. "Битый жизнью" Мерфи утверждал, что если что-то негативное может случится, то оно случится обязательно с самым максимальным ущербом. Если под "защитой от дурака" понимать несложные программные или аппаратные проверки, уберегающие от явно деструктивного поведения системы при возможных (допустимых физически, реализуемых) входных условиях, то такая защита повышает надежность. Яркие примеры: проверка перед делением на ноль и плавкий предохранитель. Кстати, и прямовключенный диод во входной цепи питания много жизней спас.

Мастер, несмотря на всю свою активность, все же товарищ пассивный. Мониторят датчики и клацают релюхи слейвы. В контексте сети, для передачи сигнала о нажатии на кнопку на слейве_1 слейву_2 для управления реле, требуется, чтобы жили: слейв_1, слейв_2, мастер и не пакостничали все оставшиеся.

Яркий пример несовместимого по стандарту железа - топор - может запороть любую проводную шину. Пожалуй, поможет кольцевание и сегментация - и тут CANу легче. Разорвав сеть, в случае с CAN получите две маленькие работоспособные сеточки; у RS-485 одна сеть 100% мертвая, вторая - с простоями на шине из-за таймаутов на ответ "потеряных" узлов.

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

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

Многие разработчики - произошли от программистов, некоторые от радиофизиков. Статистическая радиофизика утверждает, что все работает с какой-то вероятностью (точнее, интересуется вероятностью "не работы") и учит методам снижения вероятности отказа. Программист всегда работает на исправном железе - "отказ? - перезагрузись!"

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

...
+ купил когда-то ADM485 - так и лежат. Правда, уж второй год на московских АэроЭкспрессах бегает речевое оповещение с RS-485 - тьфу-тьфу... хотя и поезд)... хотя и не мультимастер)

Попытка оправдать применение дорогой автомобильной шины для дома? Вот 3 ноги из вашего примера - это отдельный провод каждому выключателю, 5 ног - это предложенный Вами STM32, а тиня там это как раз обычная четырех-ногая табуретка. Причем не особо важно будет то тиня13 или тиня2313 или PIC или еще чего такого же класса.


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


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


Что за чушь, а если я с ПК хочу отключить свет в туалете, или запрограммировать чтобы кондиционер включился ровно в 8.00, тоже прикажете не использовать?
А CAN фтопку (вместе с Шао Каном, Лю Каном и Кано), не нужно оно для дома.

1. CAN совсем не дорого.
2. Насчет того что нужно мастеру, а что слейву - соглашусь, посмотреть можно и под Вашим ракурсом. Но типичный хомо-сапенс спроектирован для работы по принципу "причина-следствие". Заменив понятия, легко можно из Вашей концепции получить мою, где для актеров "выключатель" и "реле" система должна обеспечить некий сервис. В таком случае, "выключателю" и "реле" уже что-то надо - и с таким положением дел согласится 99% домохозяек. Применив, готовые микросхемы/интерфейсы с событийным характером работы, а не опросным, можно стать ближе к народу и Матушке-Природе, веками оттачивающей свое совершенство.
3. По поводу Заказчиков. Когда работаешь "на себя" - все запускается с первого раза, когда "работаешь на дядю" - как правило, Заказчика выбирает дядя. У них свои интересы, а делать из "г" конфетку за зарплату приходится разработчику. Эх... Заказчик с "100 выключателей" достался мне "по наследству". А с дядей я до сих пор работаю, и мысленно благодарю его за такой бесценный опыт.
4. ПК для конфигурирования и мониторинга очень удобен. Для управления в реальном времени... извиняйте.
5. Не изобретайте велосипед... возьмите готовый... интерфейс из транспорта )

А что, дом чем-то хуже автомобиля? Я бы думал, что наоборот.

У вашей системы есть один большой недостаток: нельзя в произвольном месте подключить к шине кнопочку, которая будет управлять "во-он той лампочкой". Или эти кнопочки должен будет постоянно опрашивать единственный мастер, что, по-моему, не является красивым решением.

Думаю будет интересно:
Имея неприятный опыт внедрения "чужих" умных домов, однако же не побоялся сделать себе свой. В спальне под кроватью расположен контроллер с SD-картой, длинным проводочком, релюшкой, полным мостом на 245 логике, и динамиком.
Контроллер постоянно измеряет емкость провода, аккуратно прикрепленного к краю одной из спинок кровати. Стоит поднести руку к проводу - загорится свет под кроватью (релюха + светодиоды). Аналогично свет выключается. Искать тапки зимой удобно.
В 11.00 с SD-карты играет колыбельная (44100Гц, 10 бит @ 2-ШИМ + полный мост + динамик). В 7.00 играет будильник (довольно спокойная композиция), в 7.30 - более настойчивый трек).

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

Все это локально работает и удобно для меня и супруги. Но если добавить немножечко CANа, то:
- можно управлять настольной лампой с емкостного сенсора кровати (если удерживать 3 секунды). Фича появилась, когда лентяйки забывались на столе, а разработчик с супругой уже были в постели.
- можно управлять громкостью звука под кроватью с пульта. особенно удобно выключать будильники. Можно запускать другие треки.
- появилась возможность работы с напоминалками. С пульта нажимаешь кнопочку и голосом тебе сообщают об истечении времени по истечении времени. Нажатием кнопки по кругу выбирается "5 мин - 15 мин - 30 мин - выкл". Чайник на кухне стал реже подгорать).
- кроме того, есть возможность гонять живую речь между контроллерами у стола и кабинетом. Интерком поверх CAN: "женушка, принеси чай")

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

По CANу конфигурирую, круглосуточно мониторю - трафик ничтожный, задержек нет.

Как говорится "а Вам слабо, уважаемый RS-485"? Или умный дом это что-то другое? Может, это привычные выключатели и лампочки в альтернативной реализации? - тогда RS-485 рулит, и я сдаюсь)

По требованиям к электронике - для разработчика как раз много лучше, это не industrial и даже не commercial, не то что automotive... Например можно поставить CAN, а можно - лапшу из проводов, можно поставить гальваноразвязку для каждого устройства, а можно и не ставить и т.д.. Тобиш выбор огромный, делай, что хочешь и как хочешь, принимай работу сам, и не бойся в тюрму не посадят из-за того что дом на кого-то упадет.. куда ж еще лучше требования то найти?


Ну а такие же требования как и для автомобиля могут появиться только если "дом" это одно из трех:
- избушка на курьих ножках;
- трейлер / вагон поезда;
- сарай у подножья действующего вулкана.



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


Да он будет опрашивать все устройства ввода, которые нашел, это факт, тем самым заодно и контроллируя статус устойства - живой/не живой.

Повлечёт, но не очень сильное. Его адрес + кто он такой.



Можно попробывать пойти по другому. На момент инит в систему он мастер, сообщает о себе , становится slave.

Уж если RS-485, то могу посоветовать две фишечки:
1. Использовать схему приоритетного опроса. Реализуется не сложно,принцип такой:
- у каждого узла на шине есть приоритет.
- мастер за один цикл опрашивает все узлы с наивысшим приоритетом и одно устройство с приоритетом на единицу ниже (окно). От цикла к циклу в окно последовательно попадают все устройства с приоритетом на единицу ниже и одно на две единицы ниже. Далее рекурсивно. Пример, A, B - наивысшиq приоритет, C, D - чуть ниже, E - низший приоритет. Опрос будет выглядеть так: A B C A B D A B E и т.д. Если какой-то узел не ответил N раз - считаем его потерявшим связь с шиной и устанавливаем низший приоритет. При восстановлении связи с этим узлом - восстанавливаем исходные приоритет.
Плюсы: гарантированный период опроса (ограничен сверху), минимизация простоев на шине.
Минусы: пока не придумал)

2. После запроса мастера к конкретному слейву, тот отвечает на запрос мастеру и может продолжать занимать шину. Скажем, послать команду другому слейву, а затем освободить шину. Псевдомультимастер )

3. Недавно всплывала задачка автоматического поиска устройств на шине RS-485 (охранно-пожарная сигнализация с нестабильно конфигурацией - например, поезд с перецепкой вагонов). Готовые контроллеры имеют 24 битный адрес (8 под тип устройства; 16 под идентификатор, прошиваемый на заводе) - тупой перебор займет мнооого времени (скорость 9600, минимальный пакет слейву 7 байт + таймаут неответа), или я не правильно считаю?

Раз уже пошли советы по теме
Могу тоже поделиться hint'ом:
Если использовать хороший помехоустойчивый протокол и не требовательный к таймаутам между пакетами, например модбас over hdlc. Тогда в одной сети можно размещать устройства с разными скоростями обмена. Устройства с ИК портом на 2400-9600, остальные на 115200, а там где много данных например на 1Mbps. В этом случае у мастера появляется возможность адресовать устройства не только адресным байтом, но и признаком скорости. Например в системе может быть 3 устройства с одинаковым адресом "1", но работающих на разных скоростях.

Вот только не надо переворачивать все с ног на голову: сами же писали, что CAN - это слишком дорого.

Может всё таки 2

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


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

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

Построить надежное устройство - само по себе задача не тривиальная. А написать для него надежный софт - задача просто сложная, занимает много времени (с доводкой - растягивается нa годы) и получается отнюдь не у всех. Поэтому использование CAN является более чем оправданным. И разбиение задачи на маленькие кусочки - тоже оправданно. Ведь с ростом сложности ненадежность софта увеличивается не линейно, а как-то типа в геометрической прогрессии.

Так что много одинаковых не очень сложных узлов CSMA/CA получится надежнее, чем один сложный мастер.

Что Вы под этим понимаете

У меня софтовый CAN до 500 килобод живёт на ATmega48 за $1. Для выключателя/лампочки ничего больше и не надо. Неужели $2 ($1 контроллер + $1 драйвер) дорого?

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




Это решение ненадежно, настолько же насколько и недорого. Софтовая реализация довольно сложного интерфейса это не просто потенциальный баг, а мина замедленного действия. Сочетание той же m48 с аппартным UART'ом и rs485 драйвером, будет куда проще и надежней, заметьте - по той же цене.


Эта задача все равно много проще multimaster системы. Суммарно если сравнить две системы:
- систему 1 мастер + тривиальные слейвы,
- систему мультимастер где много устройств средней сложности.

Первая будет проще.


Набивать лапшой никто и не предлагает, богатство выбора дает уникальную возможность выбрать наиболее подходящий вариант.
С моей точки зрения такой вариант - это RS485 + IR непосредственно включенный в сеть 485, что позволит не только избавиться от лапши в некоторых местах, но и от пары Кановских проводов тоже, заодно и от сложности железа и софта слейвов и всей системы.

Чем же это железная реализация надёжнее софтовой? На мой взгляд, как раз наоборот. И периодически вылавливаемые в CAN-овском железе баги это подтверждают. И не известно есть они там или нет. А в софтовой можно все ошибки выгрести - запись логов при работе достаточно сделать. Кстати, для софтового CAN-а можно и ATtiny2313 использовать - ещё дешевле.
А для гарантии, при использовании с софтового CAN-а, можно использовать драйвер с ограничением времени доминанты и всё. Поэтому я и написал про его стоимость $1 .

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

Поймите правильно.
Не надо лучше.
Надо, чтобы всегда одинаково.
Поэтому - никаких "современных" стандартов.
И чем их меньше, тем лучше.
А свой протокол - даже не смешно.
Это будет никому ненужный мартышкин труд.

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


Так оно не получается одинаково, что признают использующие Modbus - свои типы данных, свои команды и т.д.


Никому не нужный мартышкин труд будет реализовывать Modbus там, где он объективно не нужен. Лучше потратить пару часов на изобретение своего, с учетом своих потребностей, а не брать Modbus и "расширять" его потом.

Сравните с:
А в 485-м интерфейсе багов нет и логов никаких не надо! И ловить нечего...

А как Вам "засерание" шины совершенно излишней информацией, якобы увеличивающей целостность данных в том же Ethernet или Profibus?
Тоже очевидная глупость...
А про старые отработанные годами протоколы я бы осторожнее...
Любую несуразность в них надо воспринимать практически, как устав РККА или ПУЭ.
Наличие такой "глупости" говорит только о том, что кто-то здесь сломал себе шею...

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

Смысла делать свое даже в данном случае не вижу.
Лучше сделать то, что потом пригодится.
Не нравится Modbus - делайте что-то иное - DeviceNet или CanOpen, к примеру.
Потом хоть наработки останутся...
А в промавтоматике, где находится основная часть денег, которые можно заработать, свой протокол - признак элементарного дилетантизма.
Иными словами. В эту сферу со своими протоколами лучше вообще не соваться... Засмеют.


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

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

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


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

Не знал, т.к. моя рабочая лошадка mega8(88,48).

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

Не совсем понял, что тут называется интерфейсом, а что протоколом. Похоже под интерфейсом понимается физический уровень, т.е. драйверы. Если так, то у CAN (стандартного, 2-х проводного) драйвер проще и лучше, чем у 485. По крайней мере, там не может возникнуть случая, когда один драйвер тянет шину в 1, а другой в 0, и те девайсы, что ближе к первому, воспримут состояние на шине как 1, а ко второму - 0. Да и послушать шину чтобы сравнить, что там реально происходит с тем, что он отправил, девайс не может. Т.е. может, конечно, но толку нет - всё равно совпадёт. Да и проводов к драйверу меньше - при гальваноразвязке актуально.

Даже если теряется 100% пакетов?

Интерфейс включает также и формирование/декодирование фреймов которые по нему гуляют, определение ошибочных фреймов. CAN'овкие фреймы (те что Вы программно формируете) сложнее тех что ходят по 485-му. Фрейм в 485-м - включает Start ... данные ... Parity.. Stop, формируется/и декодируется железом UART'а.

Не совсем так. Имеет смысл говорить не про интерфейсы и протоколы, а про уровни согласно сетевой модели OSI. Тогда RS485 это физический уровень, а CAN это уже канальный уровень. Бо RS485 на аппаратном уровне не поддерживает детектирование коллизий и контроль целостности данных.

Не премешивайте теплое с мокрым. На аппаратном уровне 485й интерфейс способен формировать, детектировать и декодировать фреймы, их начало/конец и их целостность (четность/наличие правильного стоп бита) средствами UART'а МК. Разница между 485-м/CAN'ом/Ethernet'ом и т.п. только в размере фрейма и способе обнаружения ошибок. Канальный уровень заканчивается на фреймах. Следовательно 485-й интерфейс, как и CAN, включает и физику сигналов и канальный уровень.

Чтобы пресеч возможные дебаты по этому поводу, вот для Вас цитата взятая по Вашей же ссылке:

Канальный уровень (англ. Data Link layer)
Основная статья: Канальный уровень
Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает во фреймы, проверяет на целостность, если нужно, исправляет ошибки (посылает повторный запрос поврежденного кадра) и отправляет на сетевой уровень.

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

Ну раз у вас такая аргументация, то давайте уж тогда основы рассматривать. Если вас это не очень затруднит, то найдите, пожалуйста, в стандарте TIA/EIA-485-A, который специфицирует интерфейс RS485, упоминание об UART, микроконтроллерах и фреймах или вообще что-либо отличное от электрических и частотных характеристик этого интерфейса.

Приведу полное название документа на который вы ссылаетесь - "Electrical Characteristics of Generators and Receivers for Use in Balanced Multipoint Systems", чтобы было видно, что он описывает ну.. явно НЕ интерфейс. Иначе слово interface фигурировало бы в названии документа. Заодно можно на дату выхода стандарта посмотреть, - тогда и МК с UART'ом еще не существовали в природе, а если и был то один.

Спаведливости ради соглашусь, что по физике 485-го можно гнать что угодно, например HDLC фреймы.

Но реалии таковы, что дефакто RS-232/485 в отрыве от UART'а сейчас НИКТО мало кто рассматривает.

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

Бесспорным фактом остается то, что RS485 специфицирован стандартом TIA/EIA-485-A (а до этого - стандартом RS-485), и что в этой спецификации нет и намека на свойства и характеристики, которые вы приписываете какому-то мифическому "интерфейсу RS485".

Имею на то все основания - все кому не лень без задней мысли подключают драйвер RS485 к UART'овому RXD/TXD, RE/DE цепляют на UART'овый RTS. Производители МК для UART'а даже режим специальный придумали и так и назвали (UART MODE RS485). Ковертеры RS232<>RS485 впринципе не могут работать с данными отличными от UART фреймов, а здесь почему-то мы отвлеченно рассуждаем о том, что RS485 это строго физика. Нет не строго физика. И в контексте конкретно этой темы все кто предлагал пользовать RS485 - подразумевали эту связку UART<>RS485, как само собой разумеющееся явление. Связка UART<>RS485 PHY образует 485-й интерфейс, без этой связки RS485 - это непригодная к использованию фантазия расстояний, частот, напряжений, терминаторов и прочего хлама, такая же как Ethernet PHY в чистом виде.


Именно совокупность, т.е. не только как связать снаружи много 485-х драйверов (что и описывается в документе), но и как связать внутри, вчастности как МК подключить к RS485-й сети. Если вернуться к вышеупомянутой модели ОЗИ - интерфейс - это связь между уровнями (например интерфейс связи сетевого уровня с канальным), т.е. подразумевает стыковку с двух сторон, а протокол - связь множества элементов на одном уровне (например протокол сетевого уровня). Поэтому см. выше.

В принципе, это, как раз, не так. Конвертор RS232-RS485 в строгом смысле - это только преобразователь уровней сигналов, т.е. физических интерфейсов в чистом виде, и не более того. Никакого UART-та внутри там, как правило, нет. А снаружи - он только подразумевается. Другое дело, что подразумевается - практически всегда. Однако, ни что не мешает, вместо UART, прицепить к драйверу RS485 (или к RS422, или к RS232) модуль который будет использовать, например, манчестерскую кодировку. Если такое решение будет использоваться согласованно, для всех устройств на линии - все будет работать, никуда не денется.

Что то мы залезли в теорию, причём выясняется как теоретически правильно называется связка UART+драйвер RS485 (UART+485). Думаю, для практиков, а начинающие здесь это практики, это не представляет интереса. Поэтому предлагаю обсудить связку UART+драйвер CAN как базу для создания маленькой сети. Это будет гораздо интереснее. А уж как это будет называться - не так важно. Пусть будет UART+11898, если ни у кого нет возражений. На мой взгляд, именно такая связка наиболее оптимальна для создания маленькой сети т.к.её стоимость незначительно выше (драйвера одинаковой "брендовости" дороже на $0.3) чем UART+485, а по свойствам (мультимастерность, приоритеты, эхо-контроль и т.д.) она приближается к CAN. Я так вообще не могу найти ни одного недостатка у UART+11898 по сравнению с UART+485. Если в том же модбасе заменить все драйвера RS485 на CAN-овские всё продолжит работать как ни в чём не бывало...

А как насчёт длины линии в 1..2 км?

Длина зависит от скорости. 10кБ/с.

В моей таблице (вроде как от CIA) так:
1 Мбод - 30 м
500 кбод - 100 м
125 кбод - 500 м
20 кбод - 2500 м
10 кбод - 5000 м
Но реально не проверял.
Из интереса попробовал 1 мбод на 100 м - работает без ошибок при 2-х устройствах. Если 3-е посередине с 50 см усами - пошли ошибки. Но это более, чем 3-х (!) кратное превышение.

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

С примером все ОК, а вот с выводом - не согласен.
Интерфейсы в ВТ это способы взаимодействия разных уровней ОЗИ ;> между собой. Например интерфейс OpenGL позволяет app программисту общаться с разным железом видео карт разных производителей одинаково, но OpenGL сам при этом не является физическим средством, а всего лишь фантазия договоренностей функций и типов данных.

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


К стати, ПМСМ, CAN не совсем попадает под определение 1 уровня OSI.
У него уже есть уровень 2 - разрешение конфликтов и некое поведенческое описание.
У того же MODBUS второй уровень полностью отвязан от первого.
Сейчас думаю реализовать его на оптике в качестве физ. уровня.
Интересно было бы посмотреть на CAN-оводов в этой ситуации...

Хорошо, давайте уберем слово "физический", но тогда это уже будет другой уровень абстракции. В топике же речь шла именно о физических интерфейсах!

А многомастерность уже закрыли?

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

Живет CAN на оптике. Какие там проблемы то? Элемент 2-И добавить?

И тем самым разрушить уровень 1 по OSI?
Там четко сказано - 2 открытых коллектора или стока.

Вроде, CANу от среды нужно немного:
- наличие двух состояний среды "доминантное" и "рецессивное";
- при выводе сколь угодно многих "рецессивных" состояний, одно "доминантное" при считывании должно давать "доминантное" в сумме.

Оптика: есть/нет света.
Радио: есть/нет модулированный сигнал
Витая пара: есть/нет разность напряжений.
Открытый коллектор, в конце концов.