[=AK= 17]

Имею на то все основания - все кому не лень без задней мысли подключают драйвер RS485 к UART'овому RXD/TXD, RE/DE цепляют на UART'овый RTS.

 

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

 

Как можно TIA/EIA-485-A стандарт перевести как "спецификация интерфейса", если в названии документа нет слова interface?

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

 

"Serail ATA"

"CompactPCI Specification"

"PCI Local Bus Specification"

"Universal Serial Bus Specification"

 

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

[adnega 11]

Правильно.

MODBUS гораздо шире по возможностям, надежнее и более часто применим.

 

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

 

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

 

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

 

При этом прост в реализации и более дешев.

 

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

Никаких контрольных сумм, повторов передачи, мультимастеров в софте нет.

 

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

 

A CAN - жалкая медленная и короткая покидуха от BOSH с претензией на универсальность.

Как Вам такой :bb-offtopic: ?

 

Вы хотите чтобы Вас обслужили:

1. Быстро

2. Вкусно

3. Дешево

Выбирете 2 пункта.

 

Да, скорость передачи и длина линии связаны. У CAN требование, чтобы значение бита было одинаково во всей сети. Длина и скорость привязаны к констранте с, а ее как известно, не поменяешь.

Приведите пожалуйста пример, какой скорости на какой длине Вы добивались на RS-485.

 

Я тоже не фанат MODBUS.

Просто уже наелся CAN-оводских решений до отвала в качестве потребителя.

 

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

[MrYuran 23]

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

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

Равно как и в требованиях заказчиков

[adnega 11]

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

 

А это означает:

- событийный характер работы;

- обмен маленькими пакетами;

- минимальное время отклика;

- гибкая масштабируемость.

 

 

...

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

Изменено 5 июля, 2010 пользователем adnega

[DogPawlowa 0]

сеть нужна скорее для задач умного дома

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

 

- событийный характер работы;

- обмен маленькими пакетами;

- минимальное время отклика;

- гибкая масштабируемость.

Опять ни одной цифры :(

Ну какое ВРЕМЯ ОТКЛИКА Вы хотите получить и на что?! В цифрах!

От нажатия на кнопку открытия гаражных ворот до начала движения?

От момента подтверждения новой температуры в комнате до момента, когда температура начнет изменяться?

1 мс, 10 мс, 100 мс, 1с, 1 мин, 1 час, 1 сутки?

Отсюда и физический интерфейс и количество мастеров и многие другие вещи.

 

 

 

[=AK= 17]

Опять ни одной цифры

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

[adnega 11]

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

 

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

 

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

 

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

 

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

[MrYuran 23]

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

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

[defunct 0]

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

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

 

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

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

 

Reduced MII interface

 

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

 

Вот вам еще примеры названий документов, описывающих интерфейсы:

....

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

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

[DogPawlowa 0]

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

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

 

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

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

Итого, 100 мс.

 

Рассматриваем систему с одним мастером (нумер раз в списке ув. АК)

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

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

 

Итого максимальное время отклика:

((1000/57600) мс * (10 бит/фрейм) * (6+2+10+2) +1+1) * 10 = 54,7 мс.

 

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

Что не так?

 

[adnega 11]

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

 

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

 

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

 

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

[defunct 0]

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

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

Затем верните скорость назад и пообщайтесь с остальными устройствами.

[adnega 11]

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

[DogPawlowa 0]

А я хочу звук! )

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

Тема более чем "ниачём".

[adnega 11]

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

Тема более чем "ниачём".

 

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

Эдак и про домофон можно сказать, что не надо.

 

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

 

А если нужна сложная система?

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

 

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

Изменено 5 июля, 2010 пользователем adnega