Непонятно почему какая-то заплатка вдруг объявляется эталоном и синонимом самого понятия RS485. Я, например, начинал работать с RS485 четверть века назад, интерфейс Bitbus (ныне IEEE 1118). Там никаких UART и духу не было, он использует SDLC. Однако это не дает мне оснований парить всем мозги, будто RS485 и Bitbus - это одно и то же.


Бредовое какое-то требование, чтобы слово "интерфейс" обязательно присутствовало в названии. Вот вам еще примеры названий документов, описывающих интерфейсы:

"Serail ATA"
"CompactPCI Specification"
"PCI Local Bus Specification"
"Universal Serial Bus Specification"

Найдите там слово "интерфейс"

Если широта возможностей определяется возможностью передавать более 8 байт в одном пакете, то может показаться что MODBUS шире. К счастью, к вершнему уровню CAN нет жестких требований - поэтому изобретайте свой протокол под конкретную задачу. Хотя, можно и не изобретать - взять готовый (свой или чужой).

Надежность у CAN выше. Только надо измерять частно. Передаем ровно 8 байт данных в контроллер CAN и в UART, на другом конце их ловим. CAN доставит достоверные данные, а UART - увы, прочухает только нарушение формата кадра и контроль четности.

Часто применим? А в какой области? В авто, что-то RS-485 не используют...



Моя реализация CAN: 32 программный буферов на прием и передачу. Т.е. заполняешь нужные поля структуры и выставляешь флажок "готов" для передачи. В прерывании по освобождению передатчика отсылается следующий пакет "готово". На прием тоже просто: заполняется свободный буфер и выставляется его флажок "готово".
Никаких контрольных сумм, повторов передачи, мультимастеров в софте нет.

Цены уже приводились. Плюс минус пять копеек.



Вы хотите чтобы Вас обслужили:
1. Быстро
2. Вкусно
3. Дешево
Выбирете 2 пункта.

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



Можно подробнее и с примерами, ибо я фанат CAN...

А я в промышленных приборах ни разу CAN не встречал...
Равно как и в требованиях заказчиков

В рамках поста №1 хочу заметить, что сеть нужна скорее для задач умного дома, а не для промышленного управления.

А это означает:
- событийный характер работы;
- обмен маленькими пакетами;
- минимальное время отклика;
- гибкая масштабируемость.


...
+ В промышленности RS-485 лучше!

Сообщение отредактировал adnega - Jul 5 2010, 05:14

О, Lonworks! Раз трудоемкости разработки в критериях нет


Опять ни одной цифры
Ну какое ВРЕМЯ ОТКЛИКА Вы хотите получить и на что?! В цифрах!
От нажатия на кнопку открытия гаражных ворот до начала движения?
От момента подтверждения новой температуры в комнате до момента, когда температура начнет изменяться?
1 мс, 10 мс, 100 мс, 1с, 1 мин, 1 час, 1 сутки?
Отсюда и физический интерфейс и количество мастеров и многие другие вещи.

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

Там где LON, там и спец чипы, и жесткий протокол, и бабло)

Опять пример из жизни. Есть система УД на базе модулей I-7000 - т.е. RS-485, опрос и т.п. Иногда паузы в опросе доходят до 0.8 секунды (обработка скриптов, еще что-то)... Приходит в такой дом гость). Вскоре гостю "приспичило", он подходит к роялю выключателей и пытается найти тот, который включает свет в заветной комнате... Поверьте, с задержкой в полсекунды сделать это не легко (придется пройти первый уровень игры "елочная гирлянда"). Хозяин стоит рядом и краснеет.

По-моему, 100 мс - для человека уже чувствительно.

Событий происходит не много - по сути всякий раз, когда что-нить щелкаешь, крутишь и т.п. В пределе (10 событий в сек на человека).

Думаю, 16 бит на событие вполне достаточно.

Ну и какая связь между обработкой скриптов и RS-485 ?

Естессно у вас нет оснований, потому как 25 лет уже никто BitBus не пользует, все пользуют UART


Обычное требование. А как иначе? Если описывается интерфейс, то так и пишется - интерфейс, вот пример названия доки которая описывает интерфейс:

Reduced MII interface

иначе описывается все что угодно, но не интерфейс.

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

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

Hardware Interfaces
Hardware interfaces exist in computing systems between many of the components such as the various buses, storage devices, other I/O devices, etc. A hardware interface is described by the mechanical, electrical and logical signals at the interface and the protocol for sequencing them.

Обратите внимание на словосочетание between many of the components such as the various buses. Все доки на которые вы сослались описывают шины, а интерфейс образуется между шиной и тем что к ней подрубается.

Про биты на событие не понял, проехали.
Итого, 100 мс.

Рассматриваем систему с одним мастером (нумер раз в списке ув. АК)
Берем наиболее геморройный случай архитектуры - события происходят в одном слэйве, а исполнительное устройство - другой слэйв.
Длина линии 50 м, выбираем скорость 57600, 6 байт опроса (с запасом), два байта ожидания(с запасом), 9 байт команды(с запасом), два байта ожидания(с запасом), внутренние задержки в устройствах 1 мс, 10 слэйвов с системе.

Итого максимальное время отклика:
((1000/57600) мс * (10 бит/фрейм) * (6+2+10+2) +1+1) * 10 = 54,7 мс.

ТЗ выполнено с почти двукратным запасом.
Что не так?

16 бит на команду - будем считать, что для передачи полезной информации от устройства к устройству нужно всего два байта. Теперь понятно?

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

Мультимастер получается не нужен - молотим опросом.

С кнопками, лампами, воротами... понятно. А я хочу звук! ) В посте 58 описывал рабочую систему. В принципе все можно сделать на RS-485 (если добавить Мастера-бездельника-молотильника). Все, кроме звука.

Хотите звук, переключитесь мастером на скоростной подканал - пусть 2MBit в этой же сети, залейте/скачайте пару фреймов звука.
Затем верните скорость назад и пообщайтесь с остальными устройствами.

А если источник звука слейв_1, а приемник слейв_2. Да и общение идет двухстороннее.

Тогда понятно ... Поговорить не с кем ?
Тема более чем "ниачём".

Почему же? Звук по домовой шине для меня актуальная реальность.
Эдак и про домофон можно сказать, что не надо.

Если в доме всего-то 5 выключателей, да 5 лампочек (10 слейвов), 50 метров кабеля, и ничего более, то автоматизировать тут НОЛЬ.

А если нужна сложная система?
Я как пользователь хочу пойти в магазин, купить коробочку, подключить ее к 4 проводкам, и что бы все что работало ранее - продолжало работать; после настройки событий - заработал новый модуль с новым функционалом. Писать программу для Мастера даже не вздумайте предлагать. А заложить в Мастера весь функционал, который когда либо может быть - утопия.

Забыли обсудить еще X10... или 1-wire... )

Сообщение отредактировал adnega - Jul 5 2010, 14:14