100%
Передавал по обычному телефонному плоскому кабелю на скорости 57600 в одну сторону дина провода 50м и без всяких црц и пр. херни, работало стабильно.
Мастер - max232 , slave - резистор, диод и через инвертор на мк.


Люди не ищут простых и лёгких путей решения задачи.

Люди ищут не только решение текущих задач, но и знания и опыт для решения будущих задач. Не всем-же пару байт на 50 метров всю оставшуюся жизнь пересылать. Расти над собой надо.

Мне вообще навеяло пару новых терминов: COMофобия и CANомания.
Перевернули тут всё с ног наголову, точнее, вывернули наизнанку...

Из всех "фирменных" интерфейсов для УД только про один известно, что он сделан на CAN - это VelBus от бельгийской компании Velleman. Остальные используют или специализированные интерфейсы (KNX/EIB, C-bus, LonWorks, и т.п.), или же бесхитростно ставят RS485. Скажем, для счетчиков электроэнергии выход RS485 - это стандарт, какой счетчик "с мозгами" не посмотришь, обязательно есть RS485.

Ну и шинник CAN, он ведь тоже примерно доллар стоит.

Любое дело кто-то должен начать первым.

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

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

вот у меня такой адаптер блютуз-422:

Любительские УД на CAN тоже известны. Был такой Caraca - CAn Remote Automation and Control with the AVR. Хороший пример того, что значит строить самопал на голом CAN-е. Разработчики его еще в 2000 году забросили. Первооткрыватели, ага. В это время еще и KNX-а даже не было, его предтеча EIB только-только "набирал обороты". А VelBus - не знаю, наверное, уже был. Он явно не молод и не выглядит успешным, не видно что-то, чтобы использование CAN дало Velleman конкурентные преимущества. 165 работников, оборот 37 миллионов, это немного.

Любое дело можно угробить. Я, например, абсолютно уверен, что Вам это тоже удалось-бы сделать с легкостью. Так что не могу согласитья с тем, что выбор CAN интерфейса угробил этих любителей. Это любители, по причине любительства угробили все, как угробили-бы на любом интерфейсе.

Вы и про выходное сопротивление передатчиков RS485 были уверены, что оно "не составляет единицы Ом", пока вас не ткнули носом в даташит. А пример Caraca и Velleman-а довольно наглядно показывает, что CAN (и уж особенно "голый" CAN с самопальным протоколом) - это никак не панацея и не решение всех проблем УД.

Согласен. Хоть у меня УД на CAN давно и стабильно работает, докладываю: для отправки коротких сообщений (максимум 8 байт) - CAN хорош.
Для установления связи точка-точка, для передачи больших порций данных, для детерминированного во времени обмена,
для более низких требований к монтажу и согласованию линии передачи - RS-485 годится лучше, чем CAN.

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


Это уже совсем... Какой драйвер 485-го в разы дороже CAN? Для space-применений?

Оно и не состовляет единицы Ом. Диапазон (в зависимости от типа драйвера и напряжения питания драйвера, от 35 до 150 Ом). Но Вам этого не дано понять, ибо надо не только видеть, но понимать куда смотреть и иметь способность понять.


https://store.ti.com/SN65HVD1781D.aspx
Это лично у меня массовый драйвер для мест, где не требуется гальваническая развязка. Защита на нем, кстати, используется от CAN на 30V- она резко дешевле чем для становящегося все более нишевым продуктом 485.
Это не аэрокосмос. То, что есть по 20 центов чипы, я в курсе , но их не использовал, не использую и использовать не буду - уж очень дорого обходятся.

не согласен - особенно когда про скорость передачи больших порций данных и детерменированного обмена
видимо все кто делают автомобили сильно ошибаются выбрав can

Как минимум, справедливо и обратрое утверждение:

Вам, как утонченному любителю дорогих трансиверов, должен понравиться LTC2845. Вот его выходные характеристики, в низком уровне - примерно 5 ом на участке 40-50 мА, в высоком уровне - примерно 12 Ом на том же участке.

Нажмите для просмотра прикрепленного файла

Кстати, Простые Электроники тоже обсуждали этот вопрос:
http://forum.easyelectronics.ru/viewtopic....=35&t=17552
Тоже нет единого мнения. Пмсм, здесь выбор только за ТС.

Насчёт спора RS-485 vs CAN - спор пустой и неуместный.
Любой из физ. уровней хорош по-своему и ни один не сдох.
Достоинство RS-485 - скорость, гибкость, простота и совместимость с ПК и др. устройствами.
Достоинство CAN - надёжность и определённость протокола.
Оба используются для построения УД одинаково успешно.

Тему должен вести топикстартер, а не ярые и неистовые спорщики.

Я далек от темы УД, но просто любопытно, а почему не применяют Ethernet?

Смотрите, передать 8 или 9 байт в RS-485 разницы принципиальной нет. А в CAN разница между передачей 8 и >8 байт существенна.
По поводу детерминизма. В RS-485 уж если вы отправили символ в передатчик, то через длительность байта можете отправлять следующий (грубо).
В CAN записали посылку в мэйлбокс и ждите когда он отправится. При возникновении ошибки пакет может автоматически переотправляться,
как и в случае потери арбитража. Т.е. время отправки (успешно или неуспешно) зависит уже и от линии, и от других узлов, и от ID пакета.

просто не надо сравнивать теплое с мягким

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

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

Неужели? Беру обычный USB-RS485 переходник, втыкаю в ноут, появляется порт, отравляю в порт через терминал "Hello World".
На приемной стороне получаю "Hello World". Что происходит при подключении USB-CAN переходника? Порт появляется?
С каким протоколом? Или нужно специальным ПО пользоваться? Как отправить "Hello World" по CAN в таком случае?

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

Отлично! Оталось просуммировать эти два числа. Можно так же продолжить поски передатчика с выходным динамическим сопротивоением, например, 16,99 Ома. Но даже нахождения такого экземпляра не отменит тех фактов, что:
1) Волшебное динамическое сопротивление не есть особенность 485 драйвера, как такового. Для двух предыдущих кандидатов на "единицы Ом" на их графиках дифференциального
выходного напряжения динамическая компоента в рабочем диапазоне отсутствует в принципе.
2) Выходное сопротивление даже в 150 Ом, совершенно удовлетворяет требованиям 485 драйвера.
3) Типичное выходное сопротивление типичного 485 драйвера не "единицы Ом", а порядка 60 Ом.

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

чтобы послать в 485 вы записываете в порт - в can ровно точно также толкьо в порт можно записать сразу до 8 байт
формально получается CAN проще - тут не надо ждать когда чтото отправится чтобы записать следующее, работая через прерывания в 485 вы съедаете ресурсы и тормозите очень сильно если вдруг возникнет более приоритетное прерывание и вы для того чтобы послать следующий байт потеряете кучу времени если вообще его получите

теперь гарантирование отправления даже внутри одного микроконтроллера конкурирует по ID и вы всегда можете отправить высокоприоритетное сообщение прервав обмен(вклинившись между передачей пакетов) по шине - что 485 невозможно в принципе

как то не вижу причин обсудать все это тут - если вы почитаете про can то все это становится совершенно очевидно и не требует никакого обсуждения

а уж про синхронизацию - выполнять ее аппаратно в CAN или программно в 485 - я даже не знаю как такое обсуждать?

если я вас не убедил - то извините

вот если вы говорите о том что послать 1 байт и принять его в системе 1 мастер по 485 - то да это получится быстрее чем в CAN
об этом даже и говорить не стоит 485 тут выше всяких похвал. вот только нельзя быть уверенным -
1 что ваш байт ктото принял
2 что ваш байт принят ровно таким каким вы его посылали
не находите что это довольно призрачно ебыстродействие?
но оно действительно для 485 будет быстрее

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

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

Учитывая Ваши проблемы с интеренетом, специально для Вас:

вы считаете проблеммой то что драйвера которые прилагаются к таким устройствам не имеют функционала COM порта?
сделать это не проблемма - но все дело в том что при этом вы потеряете кучу вкусных плюшек
поэтому такой огрызок и не делают - но его можно легко реализовать
в этом случае CAN станет для вас ценным? смешно

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

На моей памяти один уже сдох. Был в даже штатно в IBM PC ! но взял и помер. Его совершенно СПРАВЕДЛИВО вытеснил 485. Кто следующий

Скорость и близко нет. Гибкость, если понимать под этим минимальные ограничения на реализацию чего попало, то да.
Эта "гибкость" в том числе пораждает разннобразные кривейшие протокольные решения. А это надо? Вот Ethernet фрейм, как и CAN, подобной "гибкости"
не предусматривает. Ну и что?

Простота нынче абстрактна. На россыпи ЛА3 уже не делается ничего. CAN уже в долларовых чипах поддерживается.

В настояшее время да.

А он уже CAN выбрал.

Полагаю, что тему уже давно можно разбить на две, где главной будет:

Битва гигантов: RS-485 против CAN
ну или проще
Holy War: RS-485 versus CAN

А во вторую уже выделить помощь ТС по "интеллектуализации" освещения в его коттедже.
Бедный ТС уже, наверное, офигел от потока хлынувшей на него информации.
А впереди еще выходные

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


Напомню, что мы обсуждаем системы чувствительные к детерминизму времени.
По RS485 я мастером отправил пакет и если в течение 10 мс не получу первый байт ответа после передачи последнего байта запроса, то
могу судить о недоступности слейва или его неисправности. Сколько и чего ждать в CAN?


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

Про CAN я начитан. Но вот вы знаете, что в CAN очень низкий КПД в части полезной информации - плата за удобный сервис и кое-какие гарантии?

Именно так. Кто то уже забыл, что USB это ни разу не байтовый интерфейс, но на нем уже давно вешаются "СОМ" порты. Ethernet тоже не байтовый интерфейс, но виртуализируется и на нем, BT туда же, ZigBee образные тоже. Пропихнуть байт обернув его в ЛЮБОЙ готовый пакетный уровень ни разу ни проблема.


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

1 вы же понимаете даже если у вас 1 мастер то он должен договориться со слейвом чтобы тот начал передаввать! а это очень большое время


2 еще раз доступ к передаче будет за одинаковое время если 485 мастер. передача в can займет больше времени если вы в 485 не о чем не заботитесь - если вы хотите надежность то разницы никакой нет если стартуете из одинаковых условий. а если вам приспичило чтото передать слейву когда он вам чтото передает? то все 485 в ауте !!!

3 получив тут же? это время огромное по сравнению с CAN который получает потдверждение в процессе передачи. единственное это подтверждение о том что сообщение ктото принял а не тот кто конретно был должен


10 мс вы с умма сошли - это быстродействие? !!!
это тупые потери канала!!!!


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

Это очень важно. У меня как раз такие. Так что сейчас обсудим

Откуда взялись 10 ms никак не относящиеся к 485? Мое утройство НЕ успеввает за 10 ms разобраться с запростом мастера. Оно само должно, например, запустить поиск других устойств в эфире. Куда поропал весь "детерминизм"? Пока Вы разбираетесь пусть даже 10 ms не до начала ответа, а на весь ответ, что происходит с "детерминизмом времени" остальной сотни слейвов?

У него великолепный КПД, причем по по причине ОТСУТСТВИЯ этого самого мастера занимающего канал передачи запросами и катострофически теряющего время на таймауты ожидания ответов. То, что Вы написали о КПД, это примерно тоже самое, что рассуждения о том, что трактор штука хреновая, поскольку лошади его тяжело тянуть .

Ага, спасибо. Примерно так и думал..

на первое место поставил бы дорого
сложность вещ растяжимая

Ок. Давайте уточним: время на разбор запроса и подготовку ответа + время передачи одного байта.
На скорости 9600 это чуть больше 1 мс. Если перед передачей ответа включить передатчик на время большее 1 символа, то можно легко
избавиться от мусора при приеме на стороне Мастара, т.к. там может оказаться помеха когда на линии нет растяжки, и оба передатчика выключены
(Мастера уже выключил, а слейв еще не включил). Т.е. 1 или 2 мс.

Тут совсем ничего не понял.


Я считаю КПД так: отправляю 1 байт с 11-битным ID. Шина вместо 10 битовых интервалов занимается 75 битовых интервалов.
Мне нужно из места A в место B гонять аудио-поток в реальном времени. Что лучше RS485 или CAN?

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

Хотя, если подумать - то может и не так уж и дорого, ведь есть МК с интегрированной физикой, т.е. ставь разъем с трансформатором и вот тебе готовый девайс. другой вопрос, что эзернет как минимум на порядок более прожорлив, но и скорости там конечно поболее. Но для ммм уличного фонаря например ставить эзернет только для того, чтобы пару раз в сутки послать сообщение типа вкл/выкл с временем доставки плюс-минус лапоть - это как то через чур. потому и ставят всяческие низкоскоростные интерфейсы.


и еще по поводу доступности CAN
я знаю довольно дольшое количество беспроводных чипов, причем самое главное, ДЕШЕВЫХ чипов, которые представляют из себя связку из 8051 проца, РЧ передатчика и интерфейсов типа UART/I2C/SPI, так вот ни в одном из них нет CAN макуровня. это я к тому говорю, что повесить на шину 485 некий брелок беспроводной (например для открытия ворот) намного проще и дешевле, чем на шину CAN.

опять же, скорость передачи в 485 в принципе помимо физической среды зависит еще и от скорости максимальной самого УАРТА внутри МК, а тут уж так сказать есть уарты и до 4 мегабит,, CAN же всегда ограничем мегабитом.

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

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

а для меееедленного дома, может быть вообще имеет смысл управление делать по цепям питания 220В.

Это не подсчет, это подтасовка. Вы себя обмануть пытаетесь?
Даже если один байт, то Вы же сами радостно писали:

И 10 бит уже сразу превратились в 20. Куда делись остальные затраты на фрейминг и адресацию?
Ах да, Вам же совсем "не нужно" вообще ничего, Вам нужен ОДНОСТОРОННИЙ поток байтов для передачи музыки! Причем ОБЯЗАТЕЛЬНО для пущего "доказательства" в трактор нужно запрячь ложадьих нужно паковать по одному байту во фрейм. Тогда могу сообщить Вам, что Вам мешает и асинхроность потока создаваемая UART. Вам нужно гнать синхронный поток, ибо для ВЫДУМАННОЙ цели и CAN и UART неоптимальны.
Поскольку я ОЧЕНЬ далек от мысли, что Вы являетесь клиническим идиотом, то остается одно - Вы решили тупо потролить. Мне не интересно быть обьектом для Ваших упражннеий.

Я же написал: есть задачи, где CAN хорош (мультимастер, обмен сообщениями).
А есть где плох: в частности
- передача более 8 байт в пакете;
- задачи чувствительные с ответу слейва (временной детерминизм).
Я не утверждаю, что эти задачи не могут быть решены в рамках CAN, но, насколько я понял, ТС хочет делать централизованную систему,
а при таком подходе ему скорее всего захочется работать в режиме "запрос-ответ". И RS485 может быть приятнее CAN в этом случае.

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

C точностью до наоборот. Я объяснял, Вы ответили в стиле "ничего не понял". Но это Ваши проблемы, а не мом.

Мое первое сообщение в этой теме почему-то вызвало
вопросы у товарища net. Если он не согласен со мной, то может дальше использовать CAN в тех задачах, в которых я считаю использование CAN не оптимальным. Разбираться в дебрях CAN думаю в этой теме не стоит. Итак уже запугали ТС с гальваноразвязкой и т.п.
Я ни на чем не настаиваю. Это просто мое мнение и мой однобокий УД-опыт (тут слегка лукавлю ибо разработанная мной система с линией связи по CAN
успешно эксплуатируется на электричках уже года 4 в системе охранно-пожарной сигнализации).

Если Вы, без стеба, действительно сделали систему на CAN в стиле Master-Slave все молчат, пока Master не вякнет, то Вам ОБЯЗАТЕЛЬНО следует пересмотреть свой системный подход к использованию CAN. А то действительно у Вас лошадь трактор тянет и ей тяжело. Вам бы с тем-же net СПОКОЙНО о побеседовать о более верхних уровнях системы а не о том, как лучше один байт переслать.
А то за этим байтом ни дереьев ни леса не видно



И у не очень дешовых и не очень простых тоже. По этой причине конкретно у меня живет симплексный UART. Только это не является ни разу аппаратно-пртокольно-системным преимушеством UART.
Озвучу и еще одну причину использования "гибкости", АКА примитивности UART. У меня есть вариант, когда протяженность каналов передачи десятки километров. И архитектура отнюдь не гомогенная. Так что стоит вопрос о ретрансляции и маршрутизации. На UART исхитриться так, что-бы это происходило с минимальными задержками несложно. Для CAN же это однозначно два контролера и чистое затраты времени на полный прием и перепередачу. А на UART вообше одного UART хватает и времени длительности 2-3 байт на принятие решения о маршрутизации.

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

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


Я по то же твержу.

Исключительно на основе ВСЕХ Ваших высказываний и жалоб на то, как плох запрос-ответ и передача музыки на CAN.

То, что я написал лишь исключение подтверждающее правило. Вы на форуме встречали обсуждения связанные с использованием десятков ретрансояторов на каком-либо, хот CAN, хоть UART интефейсов? Я нет. Исключение в том, что потребовалось редкое аппаратно-протокольное решение. А в этой ветке в стенания идут по поводу того, как хорош UART c кондовым пртоколом а-ля MODBUS или подобной сложности и что с "КПД" у CAN плохо.

Вы как-будто к словам начали придираться. Я нигде не жаловался - просто высказал свое мнение.
Запрос-ответ не плох и не хорош. Он такой какой есть. В CANе приятен мультимастер и беззаботная отправка сообщений.
Но при работе с порциями данных >8 байт есть качественное усложнение протокола, в отличии от RS485.
Насчет музыки по CAN. У меня давным давно был сделан интерком между комнатами поверх CAN.
Передача звукового потока закладывалась в архитектуру моего УД изначально. Ничего военного: чуть-чуть нужно буферизировать,
загрузка шины самым низкоприоритетным трафиком порядка 50% и не влияет на передачу критичных данных.

Дык, и я про тоже: есть задачи, которые лучше для RS485 нежели для CAN.
Я назвал эту группу "детерминированного во времени обмена".
Повторюсь, к выбору слов можно придраться, главное смысл именно такой, какой вы описали в своем примере с маршрутизацией.

can есть стандарт на 10 мегабит
и при чем тут это?




проще только потому что вы имеете набор для таких действий и это аргумент?
у меня нет брелка чтобы куда то повесить мне его надо делать = поэтому это очень сложно - это довод?


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

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


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


если же 485 vs CAN - в моем понимании тут и обсуждать нечего
стоимость значения не имеет - а простота реализации на can все покрывает. если же собирать can на ла3 то конечно будет сложно. когда у вас все на одном кристалле то никакой сложности тут нет
надежность и бытсродействие, дешевизна can уже доказана на автомобилях и обсуждать это не стоит

вообще автомобили это самые сложные условия и стоимостные требования
другое дело что и там конструктора дают маху (общение с audi, vw удивляет то как они делают - зато поле для ремонтников ;-)


если же рассуждать о ножках микроконтроллера и тд и тп то это отдельная песня

всех порву эзернетом по всем критериям

Но не по простоте настройки.

can может почти в тысячу раз больше
проблема 485 - отсутствие аппаратной поддержки uart`ом
так что если can так жмёт, то я бы выбрал 422, но не 485



и по простоте
ещё есть ?

А в УД больше не надо.

Модуль UART можно настроить на автоматическое управление сигналом TX_ENABLE.
Или какая-то друга поддержка нужна?

у меня в квартире 10 контроллеров в стене. Между ними проброшен один кабель "паравозиком".
На Ethernete вы предлагаете ставить 10 портовый хаб и тянуть от каждого контроллера к хабу кабель звездой?
Мне не кажется это простым решением.

а как же звук, который выше хотели ?


в stm32 ?


в ethercat эти вопросы таки решены - и шина, и без хаба

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

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

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