[zltigo 2]

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

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

По RS485 я мастером отправил пакет и если в течение 10 мс не получу первый байт ответа после передачи последнего байта запроса, то

могу судить о недоступности слейва или его неисправности.

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

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

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

[blackfin 26]

Каждый датчик делать с Ethernet сложно и дорого.

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

 

[net 0]

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

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

сложность вещ растяжимая

 

[adnega 11]

Откуда взялись 10 ms никак не относящиеся к 485?

Ок. Давайте уточним: время на разбор запроса и подготовку ответа + время передачи одного байта.

На скорости 9600 это чуть больше 1 мс. Если перед передачей ответа включить передатчик на время большее 1 символа, то можно легко

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

(Мастера уже выключил, а слейв еще не включил). Т.е. 1 или 2 мс.

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

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

 

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

Я считаю КПД так: отправляю 1 байт с 11-битным ID. Шина вместо 10 битовых интервалов занимается 75 битовых интервалов.

Мне нужно из места A в место B гонять аудио-поток в реальном времени. Что лучше RS485 или CAN?

 

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

[bloody-wolf 0]

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

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

сложность вещ растяжимая

 

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

 

 

и еще по поводу доступности CAN

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

 

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

 

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

 

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

 

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

Изменено 18 марта, 2016 пользователем bloody-wolf

[zltigo 2]

Я считаю КПД так: отправляю 1 байт с 11-битным ID. Шина вместо 10 битовых интервалов занимается 75 битовых интервалов.

Это не подсчет, это подтасовка. Вы себя обмануть пытаетесь?

Даже если один байт, то Вы же сами радостно писали:

перед передачей ответа включить передатчик на время большее 1 символа

И 10 бит уже сразу превратились в 20. Куда делись остальные затраты на фрейминг и адресацию?

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

Поскольку я ОЧЕНЬ далек от мысли, что Вы являетесь клиническим идиотом, то остается одно - Вы решили тупо потролить. Мне не интересно :( быть обьектом для Ваших упражннеий.

[adnega 11]

Это не подсчет, это подтасовка. Вы себя обмануть пытаетесь?

Даже если один байт, то Вы же сами радостно писали:

 

И 10 бит уже сразу превратились в 20. Куда делись остальные затраты на фрейминг и адресацию?

Ах да, Вам же совсем "не нужно" вообще ничего, Вам нужен поток байтов для передачи музыки! Тогда могу сообщить Вам, что Вам мешает и асинхроность потока создаваемая UART. Вам нужно гнать синхронный поток, ибо для ВЫДУМАННОЙ цели и CAN и UART неоптимальны.

Я же написал: есть задачи, где CAN хорош (мультимастер, обмен сообщениями).

А есть где плох: в частности

- передача более 8 байт в пакете;

- задачи чувствительные с ответу слейва (временной детерминизм).

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

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

[zltigo 2]

А есть где плох: в частности

- передача более 8 байт в пакете;

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

- задачи чувствительные с ответу слейва (временной детерминизм).

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

[adnega 11]

Поскольку я ОЧЕНЬ далек от мысли, что Вы являетесь клиническим идиотом, то остается одно - Вы решили тупо потролить. Мне не интересно :( быть обьектом для Ваших упражннеий.

Мое первое сообщение в этой теме почему-то вызвало

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

Я ни на чем не настаиваю. Это просто мое мнение и мой однобокий УД-опыт (тут слегка лукавлю ибо разработанная мной система с линией связи по CAN

успешно эксплуатируется на электричках уже года 4 в системе охранно-пожарной сигнализации).

[zltigo 2]

Это просто мое мнение и мой однобокий УД-опыт (тут слегка лукавлю ибо разработанная мной система с линией связи по CAN

успешно эксплуатируется на электричках уже года 4 в системе охранно-пожарной сигнализации).

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

А то за этим байтом ни дереьев ни леса не видно :(

 

 

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

И у не очень дешовых и не очень простых тоже. По этой причине конкретно у меня живет симплексный UART. Только это не является ни разу аппаратно-пртокольно-системным преимушеством UART.

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

[adnega 11]

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

Я не знаю, на основании чего вы делаете такие выводы но я как раз говорил, что для обмена типа "запрос-ответ" CAN не очень подходит.

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

"запрос-ответом", например при обновлении прошивки или запросе диагностических данных узлов.

Из личной переписки с ТС

Я планировал сам разработать на линуксе доску с контроллерами.

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

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

Хотя можно и на CAN - сложнее реализовать, а выигрыш не очевиден.

У меня УД - полностью распределенная система. Все необходимое есть в контроллере (пользовательские скрипты). Для работы распределенных алгоритмов

используется механизм сообщений.

 

На UART исхитриться так, что-бы это происходило с минимальными задержками несложно. Для CAN же это однозначно два контролера и чистое затраты времени на полный прием и перепередачу.

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

[zltigo 2]

Я не знаю, на основании чего вы делаете такие выводы...

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

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

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

 

[adnega 11]

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

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

Запрос-ответ не плох и не хорош. Он такой какой есть. В CANе приятен мультимастер и беззаботная отправка сообщений.

Но при работе с порциями данных >8 байт есть качественное усложнение протокола, в отличии от RS485.

Насчет музыки по CAN. У меня давным давно был сделан интерком между комнатами поверх CAN.

Передача звукового потока закладывалась в архитектуру моего УД изначально. Ничего военного: чуть-чуть нужно буферизировать,

загрузка шины самым низкоприоритетным трафиком порядка 50% и не влияет на передачу критичных данных.

То, что я написал лишь исключение подтверждающее правило.

Дык, и я про тоже: есть задачи, которые лучше для RS485 нежели для CAN.

Я назвал эту группу "детерминированного во времени обмена".

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

[net 0]

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

can есть стандарт на 10 мегабит

и при чем тут это?

 

 

 

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

 

 

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

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

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

 

 

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

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

 

тут возможно несколько типовых решений и надо смотреть

если это типа бизнес нужно иметь варианты решений чтобы можно было при различных условиях их применять

однозначного решения тут нет

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

отвественных решений тут как то не наблюдается

 

 

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

 

 

если же 485 vs CAN - в моем понимании тут и обсуждать нечего

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

надежность и бытсродействие, дешевизна can уже доказана на автомобилях и обсуждать это не стоит

 

вообще автомобили это самые сложные условия и стоимостные требования

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

 

 

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

[VCucumber 0]

Каждый датчик делать с Ethernet сложно и дорого

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