[VCO 0]

Кстати, Простые Электроники тоже обсуждали этот вопрос:

http://forum.easyelectronics.ru/viewtopic....=35&t=17552

Тоже нет единого мнения. Пмсм, здесь выбор только за ТС.

 

Насчёт спора RS-485 vs CAN - спор пустой и неуместный.

Любой из физ. уровней хорош по-своему и ни один не сдох.

Достоинство RS-485 - скорость, гибкость, простота и совместимость с ПК и др. устройствами.

Достоинство CAN - надёжность и определённость протокола.

Оба используются для построения УД одинаково успешно.

 

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

[blackfin 26]

Насчёт спора RS-485 vs CAN - спор пустой и неуместный.

Любой из физ. уровней хорош по-своему и ни один не сдох.

Достоинство RS-485 - скорость,простота и совместимость с ПК.

Достоинство CAN - надёжность и определённость протокола.

Оба используются для построения УД одинаково успешно.

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

[adnega 11]

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

Смотрите, передать 8 или 9 байт в RS-485 разницы принципиальной нет. А в CAN разница между передачей 8 и >8 байт существенна.

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

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

как и в случае потери арбитража. Т.е. время отправки (успешно или неуспешно) зависит уже и от линии, и от других узлов, и от ID пакета.

 

[net 0]

Насчёт спора RS-485 vs CAN - спор пустой и неуместный.

Любой из физ. уровней хорош по-своему и ни один не сдох.

Достоинство RS-485 - скорость,простота и совместимость с ПК.

Достоинство CAN - надёжность и определённость протокола.

Оба используются для построения УД одинаково успешно.

 

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

 

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

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

 

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

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

которые многие не считают проблемами

 

 

 

[adnega 11]

совместимость с ПК совершенно одинаковая - полно USB-CAN и просто CAN плат

Неужели? Беру обычный USB-RS485 переходник, втыкаю в ноут, появляется порт, отравляю в порт через терминал "Hello World".

На приемной стороне получаю "Hello World". Что происходит при подключении USB-CAN переходника? Порт появляется?

С каким протоколом? Или нужно специальным ПО пользоваться? Как отправить "Hello World" по CAN в таком случае?

[Corvus 1]

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

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

[zltigo 2]

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

Отлично! Оталось просуммировать эти два числа. Можно так же продолжить поски передатчика с выходным динамическим сопротивоением, например, 16,99 Ома. Но даже нахождения такого экземпляра не отменит тех фактов, что:

1) Волшебное динамическое сопротивление не есть особенность 485 драйвера, как такового. Для двух предыдущих кандидатов на "единицы Ом" на их графиках дифференциального

выходного напряжения динамическая компоента в рабочем диапазоне отсутствует в принципе.

2) Выходное сопротивление даже в 150 Ом, совершенно удовлетворяет требованиям 485 драйвера.

3) Типичное выходное сопротивление типичного 485 драйвера не "единицы Ом", а порядка 60 Ом.

 

 

[net 0]

Смотрите, передать 8 или 9 байт в RS-485 разницы принципиальной нет. А в CAN разница между передачей 8 и >8 байт существенна.

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

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

как и в случае потери арбитража. Т.е. время отправки (успешно или неуспешно) зависит уже и от линии, и от других узлов, и от ID пакета.

 

если отвечать по вашей логике то все совсем не так как вы думаете

если стоит просто записать в порт то вы правы

если цель переслать данные то все совем не так

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

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

 

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

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

 

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

 

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

 

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

 

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

 

вот если вы говорите о том что послать 1 байт и принять его в системе 1 мастер по 485 - то да это получится быстрее чем в CAN

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

1 что ваш байт ктото принял

2 что ваш байт принят ровно таким каким вы его посылали

не находите что это довольно призрачно ебыстродействие?

но оно действительно для 485 будет быстрее

 

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

что я имею ввиду

может быть очень быстрый процессор и куча дохлых процессоров и вот этот мощный может пересылать с высоким быстродействием пакеты, а дохлые возьмут только те пакеты которые им принадлежат

 

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

 

[zltigo 2]

Угу, столь же информативно, как и весь остальной ваш бред:

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

SN65HVD1781D

70-V Fault-Protected RS-485 Transceivers

TI Store Price:

 

 

Qty. Price

1 - 9 $ 5.06

10 - 24 $ 4.61

25 - 99 $ 4.16

100 - 249 $ 3.83

250 - 499 $ 3.49

500 - 749 $ 3.17

750 - 999 $ 2.88

[net 0]

Неужели? Беру обычный USB-RS485 переходник, втыкаю в ноут, появляется порт, отравляю в порт через терминал "Hello World".

На приемной стороне получаю "Hello World". Что происходит при подключении USB-CAN переходника? Порт появляется?

С каким протоколом? Или нужно специальным ПО пользоваться? Как отправить "Hello World" по CAN в таком случае?

вы считаете проблеммой то что драйвера которые прилагаются к таким устройствам не имеют функционала COM порта?

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

поэтому такой огрызок и не делают - но его можно легко реализовать

в этом случае CAN станет для вас ценным? смешно

 

для справки advantech делает такой драйвер который полностью совместим

и использует теже функции что и com порт

выставление скорости и передачи пакета

ну и в чем такая ценность

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

 

[zltigo 2]

Любой из физ. уровней хорош по-своему и ни один не сдох.

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

Достоинство RS-485 - скорость, гибкость,

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

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

не предусматривает. Ну и что?

простота и совместимость с ПК и др. устройствами.

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

Оба используются для построения УД одинаково успешно.

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

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

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

[Baser 5]

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

 

Битва гигантов: RS-485 против CAN

ну или проще

Holy War: RS-485 versus CAN

 

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

Бедный ТС уже, наверное, офигел от потока хлынувшей на него информации.

А впереди еще выходные

 

[adnega 11]

 

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

На RS485-шине единственный Мастер. Все обмены происходят по его инициативе.

Обсуждать мультимастер на RS485 не стоит, т.к. для такого применения CAN без альтернатив.

 

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

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

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

могу судить о недоступности слейва или его неисправности. Сколько и чего ждать в CAN?

 

1 что ваш байт ктото принял

2 что ваш байт принят ровно таким каким вы его посылали

Но получив тут же ответ от слейва я гарантирую, что он его получил.

Отправка пакета в CAN, это типа "толпа! тут байты есть налетай кому надо".

Потом каждый за это ответить должен, мол, "я получил. я тоже"?

 

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

[zltigo 2]

вы считаете проблеммой то что драйвера которые прилагаются к таким устройствам не имеют функционала COM порта?

сделать это не проблемма

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

 

Битва гигантов: RS-485 против CAN

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

 

 

[net 0]

На RS485-шине единственный Мастер. Все обмены происходят по его инициативе.

Обсуждать мультимастер на RS485 не стоит, т.к. для такого применения CAN без альтернатив.

 

 

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

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

могу судить о недоступности слейва или его неисправности. Сколько и чего ждать в CAN?

 

 

Но получив тут же ответ от слейва я гарантирую, что он его получил.

Отправка пакета в CAN, это типа "толпа! тут байты есть налетай кому надо".

Потом каждый за это ответить должен, мол, "я получил. я тоже"?

 

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

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

 

 

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

 

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

 

 

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

это тупые потери канала!!!!

 

 

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

видимо я не могу вам ничего объяснить. раз вы все читали о чем вы говорите??????