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

Откуда взялись 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В.

Сообщение отредактировал bloody-wolf - Mar 18 2016, 15:47

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

И 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 удивляет то как они делают - зато поле для ремонтников ;-)


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

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