Это что за документ? CAN в т.ч. и беспроводной (радио) бывает...

Офф. Только не подумайте, что я фанат CAN-а. Протокол как протокол. Но модбас с ним даже рядом не стоит.

Правильно.
MODBUS гораздо шире по возможностям, надежнее и более часто применим.
При этом прост в реализации и более дешев.
A CAN - жалкая медленная и короткая покидуха от BOSH с претензией на универсальность.
Как Вам такой ?
Я тоже не фанат MODBUS.
Просто уже наелся CAN-оводских решений до отвала в качестве потребителя.

Почему другой? Ровно один в один с абстракциями CAN и Ethernet интерфейсов. В которых внешняя часть оканчивается электрическими характеристиками, а внутренняя (со стороны программы на МК) - фреймами данных, правилами их формирования и декодирования. С моей стороны, говоря о 485-м интерфейсе выше, и предлагая его использовать для домашней сети - речь шла именно о связке UART+RS485 драйвер. Иначе ведь я бы не смог предложить подвязать IRDA устройства в общую сеть... Зачем мы тратим столько времени на очевидные вещи?... Или у вас есть опыт работы с RS485 сетями где используются фреймы отличные от UART'овских?

Потому, что в "физике" нет ни фреймов, ни битов, а есть только Вольты, Амперы, Омы и секунды.
Потому, что путь к взаимопониманию начинается с базовых определений, которые, как оказывается, у вас свои собственные.
Вам уже приводили пример с манчестером через RS485. Как еще один пример, SPI с частотой тактирования несколько МГц на сотню метров, также используя драйверы RS485. Вот и получается, что RS485 в применениях есть, а UART нету.

Стоп. Вы прикалываетесь или это троллинг такой мощный? ;>

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


За примеры спасибо, правда не помню кто приводил пример с манчестером и в каком контексте, но я тоже могу таких примеров насочинять сколько угодно. Могу UART фреймы пустить по физике ethernet'а. Дурное дело - нехитрое, любые фреймы можно гнать по любой физике (не факт только что это будет эффективно, и востребовано). Но это явно не проблема.
Вопрос был более конкретным:

Так есть или нет такой опыт?
Допустим по рекламке вы покупаете конвертер RS485<>Ethernet, что вы ожидаете получить от этого конвертера? Манчестер с обеих сторон, HDLC, CAN фреймы, SPI на много мегагерц, или все-таки Ethernet фреймы на ethernet стороне, uart фреймы на RS485 стороне? Допустим Вы декларируете поддержку RS485 вашим устройством, вы уточняете какие фреймы бегают по этому интерфейсу в своей документации, это HDLC, CAN фреймы, Ethernet фреймы, или SPI на много мегагерц или все же UART фреймы? Если Вы хотите чтобы Ваши устройства кто-то купил, неужели будете ганять там ни с чем несовместимый SPI на "несколько мегагерц" как приводите в своем примере?

За себя отвечу - у меня опыт такой:
все сторонние (не сделанные мной) устройства, которые декларировались как совместимые с RS485 интерфейсом с которыми работал формировали UART фреймы.


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

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

Непонятно почему какая-то заплатка вдруг объявляется эталоном и синонимом самого понятия 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 лучше!

О, 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... )

ну дык, схема та же. Оба слейва - на высокую скорость, за одну ms на 2MBit/s сможете передать 200 байт данных (от слейва к мастеру или наоборот), а это 25ms звука в G.711. Т.е. на дуплекс между двумя узлами уйдет всего 4/25*100% = 16% времени шины.

Можно сократить в два раза требуемую пропускную до 8%, если ввести broadcast адрес - 0xff. Тогда мастер спрашивает допустим слейв_1 передать очередной звуковой фрейм, а слейв в ответ шлет широковещательный пакет, не мастеру, а всем в сети, но примут и проиграют его только те слейвы которым мастер разрешил.


В контексте этой ветки вы не пользователь, а строитель своей системы. И программу в любом случае придется писать.
А ежели вы не строитель, а пользователь - тогда не нужно думать о высоких материях 1-wire и RSах разных - в магазин - там WiFi / Bluetooth / Ethernet приколов сколько угодно, и все продумано.

Чё-то как-то неубедительно.
Возьмите свой девайс. Вместо 485-ого UARTы двух процов подключите напрямую. Что изменилось? Что при этом относится к протоколу, что к UARTу, а что к 485-ому? А то, что 485-ый просто передаёт любого вида двоичный сигнал (с ограничением на скорость переключения) с хорошей помехоустойчивостью (электро, не программной) на длинные расстояния. И всё. Нет у 485-ого никакого размера фрейма. Связан он с UARTом именно как тёплое связано с мокрым
Причём в парочке своих девайсов я спокойно передавал по 485-ому сигналы SPI.

ЗЫ. RS-232 с UARTом скорее всего точно так же связан

Мне кажется, что автор ветки под Мультимасеровостью понимал:



С CANом is_message и send_message очень просты.
Все контроллеры одинаковы, за исключением содержимого while(1), которое пишется под конткретный контроллер и не зависит от других контроллеров.
Не нужен дополнительный (или выделенный) контроллер.

Хорошо, а если так:
через CAN драйвер можно гнать фрейм оличный от CAN-фрейма? можно.
CAN без CAN фреймов продолжает быть CAN интерфейсом? нет.

без CAN фреймов это будет эээ RS-CAN: electrical charactericts of generators and receivers in multipoint systems.


Последний раз
Словосочетание "RS-485 интерфейс", упоминаемое мной в этой ветке, подразумевает связку "UART<->RS485 драйвер". Вместе UART и RS-485 драйвер образуют интерфейс с помощью которого можно легко подключить программу выполняемую на любом простом МК с аппаратным UART'ом к сети. Этот RS-485 интерфейс будет проще в реализации и надежней в работе чем программная реализация CAN интерфейса на том же МК, и дешевле чем если брать МК сразу с поддержкой CAN интерфейса.

Отдельно от UART'а RS485 - это не интерфейс, потому что не описывает способ подключения устройства к сети, а описывает только электрические характеристики и способ передачи данных (полудуплексность) по двухпроводному каналу.

Если делать сеть на RS-485, какой контроллер можно взять для Мастера?

Любой, где есть UART. А где его нет - можно сделать программно. Так что - совсем любой.
А если взять преобразователь USB-RS485, то Мастером может быть ПК. Также любой.
Так что - совсем любой МК или ПК. Главное, чтобы у него ресурсов хватило на Мастерство.

Ну хорошо, признаюсь, что полного/оригинального стандарта TIA/EIA-485-A я не читал и не могу утверждать, что там есть слово Interface Но вот стандарт RS232 (TIA/EIA-232-F) вполне доступен. В заголовке его английским по-белому написано слово Interface (Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange). Найдите, пожалуйста, в его тексте что-нибудь про UART, baudrate, frame и прочее, которое по-вашему мнению является непременной принадлежностью интерфейса. Только не нужно ссылаться на "старость" документа
Если не убеждает этот документ, то вот стандарт RS422 (EIA/TIA-422-B ). Совсем близко к RS485. И снова в наименовании документа присутствует слово Interface (Electrical Characteristics of Balanced Voltage Digital Interface Circuits), но опять нет ничего про форматы данных, биты, фреймы и пр. хотя упоминаются Вольты, Омы, метры и Герцы.
Ну и на закуску ответьте, пожалуйста, сможет ли работать упоминаемый вами конвертор RS485<->Ethernet, если я подам ему на вход сигнал строго от UART (естественно с помощью драйвера RS485) с baudrate 12Мбит/с или еще проще - 30 бит/с? Или с форматом 3 бита на символ или 17 битов на символ? Возможность генерации таких baudrate и символов пока не обсуждаем.

Хорошо.
А attiny13 подойдет?
Как никак 64 байта ОЗУ. Хватит ли хранить информацию о всех слейвах?
Или atmega8? Уже 1024 байта - под стек, перемнные, буфера, состояния слейвов...
atmega128! Дык, это дорого

С ПК сразу облом. Скорее всего ОС Windows, а это означает что про миллисекунды можно забыть, иногда, на минуты.
Делать в одном потоке - загрузка под 100%. В разных - можешь управление раньше чем через ~14мс не получить. К тому же ПК грузится долго, вирусы, шум, пыль, электроэнергия, а самое главное - он будет дороже контроллера с аппаратным CAN!

Широта возможностей определяется простой вещью - возможностью применить свое устройство так, чтобы не было обидно за потраченные на его разработку усилия.
В этом плане и приветствуется следование стандартам. MODBUS ли, PROFIBUS ли или еще чего... Для фанатов CAN-а - DeviceNet и CANOpen.

Дык, в авто и CAN, что-то не очень используют. Только в дорогих и очень дорогих...
А насчет применения MODBUS я уже здесь распинался. Здесь же, чуть выше.

А зря. Поэтому и приходится людям дорабатывать CAN с помощью протоколов более высокого уровня в виде DeviceNet.

PROFIBUS/DP - 12MB - 300 m.
С репитерами и коуплерами - длина практически не ограничена.
Некоторые абоненты сети подключены к ней через оптоволокно.

Пример - применение "голого" CAN со своим протоколом в одной из машин на нашем производстве.
Глючит неподеццки.

С тиньками не работаю, а Мастер на PIC12 (1К флэш и 64 регистра по 8) для простенькой сети - как-то был прецедент. Использовался Модбас, кстати, по просьбе трудящихся.

В последней системе пром. компьютер под виндой рулил аж 12-ю подсетями на RS-485. Управлял десятком-другим устройств, снимал телеметрию в реальном времени, обслуживал датчики, привода, пульты операторов...
Так что никаких обломов...
P.S. Потом управляющий ПК оставили в оффисе (чтобы не возить), а систему соединили с ним через эзернет и инет, кстати, ничего не переделывая и не перестраивая. Ваша CAN-система так сможет?

Замечу, что это не доработка, а необходимая надстройка.
Система должна решать:
- как передавать данные больше 8 байт;
- как распределять идентификаторы/приоритеты.

Спорить тут действительно не о чем. Любую более-менее реальную систему можно построить и на CAN, и на RS-485 (или еще чем-нить). Вопрос не в физике, вопрос в сложности разработки.
В RS-485 относительно "тупые" слейвы и суперсложный Мастер (содержит в себе практически весь функционал системы). Благодаря этому можно клепать дешевые слейвы, а на Мастера можно и раскошелиться.
В CAN все одинаковые как по цене, так и по сложности (суперсложность Мастера раскидана по слейвам).
"Каждый выбирает для себя".
Я придерживаюсь пути: лучше сделать десять сложных вещей, чем одну супер-сложную.

Автору ветки (с atmega`ми) конечно быстее будет разобраться с RS-485, но я советую "идти другим путем".

Всем Мира и удачи в делах)

PS: интересно, на чем он будет делать?



Без конкретных цифр не интересно. Судя по тому, что все прекрасно ожило через Инет - постоянная времени гораздо больше упоминаемых 100мс.

Моя CAN-система может). (с переходником Ethernet-CAN, конечно) Могу по сети поуправлять любым контроллером, поменять параметры, перепрошить в конце концов. Делал управление по TCP/IP - можно заходить на страничку с УД. Хоть в локалке, хоть в Инете, хость с мобилки. Кстати, и RS-485 не проблема прикрутить. (Я надеюсь понятно, что не к CAN-шине).

100мс - был максимально допустимый таймаут. По нему ошибок не было.

Да, этот стандарт описывает физический интерфейс. (указаны и типы разъемов, и электрические параметры, и логические сигналы, их назначение, и последовательность действий для соединения устройств). Но есть более современные редакции этого интерфейса вчастности RS-232C (тот что пользуют в PC) который включает спецификации CCITT x.20 bis и x.21 bis (вот он формат фрейма). К МК мы зауши притягиваем RS-232C, да собсно именно его зачастую и конвертируем в 485...

вот нарыл чтобы не быть голословным:
In this document the term RS232 will be used when refered to this serial interface. The description of RS232 is an EIA/TIA norm and is identical to CCITT V.24/V.28, X.20bis/X.21bis and ISO IS2110. The only difference is that CCITT has split the interface into its electrical description (V.28) and a mechanical part (V.24) or Asynchronous (X.20 bis) and Synchronous (X.21 bis) where the EIA/TIA describes everything under RS232.




Ну если бы я в магазине увидел такой девайс, то я бы сразу себе представил, что этот конвертер со стороны ethernet'а дает TCP, а со стороны 485-го UART фреймы, скорость, четность, кол-во бит в байте настраиваемые. И думаю не ошибся бы. (Вы бы для магазина сделали именно такой )


Для мастера лучше потолще. Он будет всего один на всю сеть, и будет удобно если у него всегда будут ресурсы в запасе. Если mega128 то еще б ей 32KB памяти впридачу. А еще лучше какой-нить ARM. Можно подобрать подходящую плату для мастера на starterkit.ru

Т.е. вы согласны, что RS232, описываемый стандартом EIA/TIA-232-F, это все-таки (физический) интерфейс?
А когда он не заработал бы с теми сигналами, что я описал, что бы вы подумали? Что может это все же конвертор не интерфейсов, а протоколов? То бишь это устройство конвертора протоколов, имеющее два физических интерфейса, которое конвертирует асинхронный протокол формата "свободная линия" в стек протоколов IP. Разве не так?

Да, док приведенный вами в предыдущем посте описывает физический интерфейс.


Если бы он дал что-то другое, отличное от UART фреймов на 485-й стороне, я бы не думал, а отнес бы его обратно в магазин. собсно вот
вообще все так, только протокол этот асинхронный является неотъемлемой частью интерфейса системы в которой я бы хотел применить этот конвертер. Помните ваш пример с общением между людьми, междумордие и все такое Так вот: Рот + выговаривать звуки - есть интерфейс, (ртом ведь не только можно говорить, можно еще есть... пить...), язык общения - протокол.

Вот например по приведенной вами выше доке можно смастерить два разъема соединить их и думать что это такой способ соединения троса. Без спецификации данных будет "мартышка и очки", а не интерфейс.

Я думаю, что связку UART-RS485, все таки, не стоит называть интерфейсом.
Более правильно, по моему, называть это сочетание физическим каналом связи. В его основе лежат две вещи: физический интерфейс - в данном случае RS-485, и способ передачи информации - асинхронная последовательная передача данных.
Обе эти составляющие можно рассматривать совершенно отдельно от друг от друга. Но только их сочетание образует физический канал, по которому уже можно что-то передавать. А различные протоколы - это то, что ложится поверх всего этого.
Кстати логическую часть (способ передачи) UART-том тоже называть не стоит. Так как UART - строго говоря, это аппаратный модуль - конвертор из параллельного кода в последовательный и обратно.

Эх... все бестолку
...война программистов окончена, учитель, я проиграл ©


Физический канал - это провода по которым осуществляется связь...
А сочетание (совокупность методов и средств) в результате которого вы стыкуете что-то с чем-то и называется "интерфейс"....

Ну слава богу! Хотя бы в этом консенсус достигнут
А если бы у него было указано, что он через RS485 прямо с линии Ethernet манчестерский код транслирует, без преобразования протоколов?
Вот ведь какой подшипник упорный от трактора ДТ-75МВ, все равно свое катите
Ну не совсем так. Рот (ротовое отверстие) сам по себе не разговаривает. Ротовое отверстие является частью речевого аппарата человека, в который входят как минимум голосовые связки и легкие. Хотя даже исправный речевой аппарат не может выдавать речь, а только звуки. Речь получается в результате взаимодействия мозговой деятельности и речевого аппарата. НО! Сообщение, которое хотелось бы передать с помощь речевого аппарата, можно отправить адресату и без оного - с помощью манипуляции рук, пишущего предмета и набора символов или даже только с помощью рук (азбука немых). Так что язык можно считать протоколом, но вот только он не имеет однозначной связи с интерфейсом речевого аппарата. Соответственно интерфейс речевой связи не является обязательной принадлежностью языка-протокола.
Даже без спецификации на формат передачи данных вы получаете стык согласованных интерфейсов! А по какому именно протоколу там будут передаваться данные это уже дело десятое.

Ну будет стык, двух шнуров, можно привязать его к тележке и тянуть, авось не порвутся.. если формат передачи не оговорен, получите просто связанные два шнура. Почитайте хотя бы ссылку которую я привел выше.. где говорится что интерфейс RS232 разделен на 3 части, механика, электрические параметры, и форматы фреймов.... Да по большому счету, если лень не надо ничего читать, просто захотите понять о чем я пишу.. == Стыкуем программу на МК с сетью для это нужен интерфейс состоящий из комплекса:
- механика (как соединить провода),
- электрических параметров (что будет бегать по проводам, как далеко и насколько быстро),
- и формата данных (чтобы нас поняли все узлы сети, в т.ч. прозрачные конвертеры, и мы понимали остальных).

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

Последний пример. Допустим я хочу передать вам письменное сообщение. У меня есть несколько способов (средств) сделать это: служба ЛС на форуме, e-mail, почта России, курьерская почта, проводник поезда, знакомый который у вас будет проездом и т.п. Никто из них не знает содержимого моего письма, там может быть текст, рисунок, фотография, электрическая схема и т.д. То бишь формат передаваемых данных доставке совершенно неизвестен. Если я пошлю вам письмо почтой России или курьером, а вы будете ждать его мылом, то сообщение может и не дойти. Аналогично будет, если я пошлю с оказией (знакомый проездом в вашем городе), а вы будете ждать его с проводником поезда. Знакомый уедет, так и не встретившись с вами у вас дома потому, что вы в это время на вокзале находитесь. Во всех случаях наши с вами интерфейсы (те самые "методы и средства") передачи данных оказались несогласованы. Но даже если они и будут согласованы, и вы таки получите мое послание, совсем не факт, что вы прочитаете письмо, написанное, например, на арабском языке. Формально информация вам доставлена, но для вас она нулевая.
Согласитесь же наконец, что интерфейс совсем не обязательно должен включать в себя протокол, и завяжем на этом.

Не имеет, я так и написал. Звуки имеют непосредственное отношение к речевому интерфейсу (как UART фреймы в нашем вопросе). А язык - модбус, или еще какой-то бус не имеет значения


И что нужно для того чтобы все эти службы работали? Правильно --- платИть, вот это и есть формат данных всех этих интерфейсов. Физический канал например может передавать 9600 кбит, а реально получается полезных 7680 а то и меньше.. Расплата интерфейсу за сервис и совместимость.


В том то и дело что обязательно должен, так написано в определении термина интерфейс... http://en.wikipedia.org/wiki/Interface_%28...uter_science%29
Но необязательно это будет какой-то сложный формат типа модбас. Протокол атомарной транзакции дайте или по самому минимуму хотя бы скажите что неактивный уровень это уровень лог "1", да и на том спасибо. Но должен быть!!

В названии документа RS485 слова "интерфейс" нет: TIA-485-A Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems Зато в названии его братьев-близнецов RS422 и RS423 слово "интерфейс" присутствует: TIA-422-B Electrical Characteristics of Balanced Voltage Digital Interface Circuits; TIA/EIA-423-B Electrical Characteristics of Unbalanced Voltage Digital Interface Circuits. Никакого фундаментального отличия между тремя документами нет, они очень похожи. Разница только в том, что RS422 и RS423 - это соединения "точка-точка" (как RS232).

Очевидно, что в англоязычной литературе "интерфейсом" как правило принято называть только то, что описывает взаимодействие двух объектов. Поэтому на английском все последовательные интерфейсы с топологией точка-точка могут называться "интерфейс", а интерфейсы с иной топологией будут называться как угодно еще, но только не "интерфейс".

Hарочито суженное употребление термина "интерфейс" в английском техническом вызванo тем, что, в отличие от русского, это слово заимствовано не из иностранного языка, а взято из самого английского, где оно успело обрести ("The noun interface has been around since the 1880s") вполне определенный смысл:

interface –noun
1. a surface regarded as the common boundary of two bodies, spaces, or phases.
...

interface (plural interfaces)
1. The point of interconnection between two entities.
...

Соответственно, англоязычные по возможности избегают использовать это слово в значениях, которые не соответствуют наиболее употребительному разговорному. Interface на русский точнее переводится как "стык". Соответственно, RS232 - это стык (и ведь бытовал он в русском как "стык С2"), RS422 - стык, RS423 - стык, а RS485 - это не стык, а шина.

Тролль, с которым вы продолжаете спорить, играет на мелких oтличиях терминологии в русском и английском языках, выдавая не имеющие никакого значения языковые артефакты и неряшливые описания википедии за истину в последней инстанции.

Нет, не должен. Должны быть, хотя бы, два различимых состояния (уровня сигнала) - и все. И ни каких нулей, единиц и атомарных транзакций. При одном способе передачи эти два состояния могут быть напрямую обозначены 0 и 1. А при другом передача может осуществляться, например, не уровнями, а временными интервалами между фронтами сигнала. Сами же уровни при этом не будут нести ни какой информации. Физическому интерфейсу не положено знать какой способ кодирования и передачи информационных бит (байт, фреймов и т.д.) будет выбран. Не его это забота. Вот так вот, дорогой ученик!

Ок хорошо, не должен.
В таком случае физический интерфейс обычной статической памяти конечно же не должен включать описания, ни сигналов ни их уровней ни строгой последовательности их появления ADDR, R, DATA. Все рашает вася пупкин. Так? Ведь вы говорите:

В данном случае описан не только физический интерфейс, но и способ передачи информации - то есть физический канал полностью. Описание способа передачи информации составил и реализовал другой Вася Пупкин. Он за Вас все уже решил. Когда надумаете сделать собственную м/c, тогда сможете сами выбирать способы передачи информации из/в нее, в пределах тех возможностей, которые Вам будут предоставлены физическим интерфейсом.

А теперь можно я приведу цитату определения аппартного интерфейса с wiki (к сожалению на русский никто не перевел так, что извините на родном процитировать не могу, мой перевод ниже но он может быть неточным):
A hardware interface is described by the mechanical, electrical and logical signals at the interface and the protocol for sequencing them (sometimes called signaling).

Переводится как:
Аппаратный интерфейс описывается механическими (разъемы, контакты), электрическими (напряжения, токи) и логическими сигналами (уровни "0", "1") в этом интерфейсе, а также протоколом их переключения (иногда называемым signaling).

Вот и все, в доке на RS232 есть все три пункта, в доке на RS485-й есть только второй пункт. Никаких игр слов.
В примере с шиной памяти, тоже должны быть описаны все три пункта, иначе память подключить будет нельзя.

Мы с Вами, по моему, обсуждали уровень физического интерфейса, а не аппаратного, в который авторы определения включили все понятия скопом - и физический интерфейс, и способ передачи информации, и требования к разъемам. Или Вы будете утверждать, что к физическому интерфейсу RS232 не применимо, все что сказано мною выше про RS485? Вы с чем не согласны, с использованием терминологии или по сути?
Насчет терминологии - я не настаиваю, называйте как считаете нужным...

Это не определение, это описание для чайников. Не путайте божий дар с яишницей

Моё ИМХО интерфейсы могут быть разные. Здесь я частично соглашусь с defunct. В частности и по RS232 можно передавать SPI сигналы. Но чтобы не спутать о каком типе интерфейса идёт речь они должны отличаться как минимум названием. Например RS-232 описывает только "mechanical, electrical and logical signals", а RS-232C то же самое плюс UART. С 485-ым так же должно быть. И понятие интерфейс может (но не обязано) включать в себя любой программно-аппаратный уровень форматов/стеков если речь идёт о законченном модуле/девайсе, который связан с внешним миром через канал связи. Но опять же чтобы не вводить в заблуждение людей нужно либо указывать точное название интерфейса (если таковой существует, как например RS-232C), либо указывать полную цепочку более элементарных интерфейсов, аппаратуры и протоколов, жёстко заложенных в девайс. Например RS-485+UART+ModBus.

Или, к примеру, DMX512. Есть и UART, и RS-485, но... верхушка другая - называется одним словом "DMX512".