[adnega 11]

Длина зависит от скорости. 10кБ/с.

[galjoen 0]

Длина зависит от скорости. 10кБ/с.

В моей таблице (вроде как от CIA) так:

1 Мбод - 30 м

500 кбод - 100 м

125 кбод - 500 м

20 кбод - 2500 м

10 кбод - 5000 м

Но реально не проверял.

Из интереса попробовал 1 мбод на 100 м - работает без ошибок при 2-х устройствах. Если 3-е посередине с 50 см усами - пошли ошибки. Но это более, чем 3-х (!) кратное превышение.

[rezident 0]

2 defunct, насчет разницы терминов интерфейс и протокол. Пояснения на бытовых аналогиях.

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

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

Резюмируя. Интерфейс это физическое средство/способ связи, а протокол это система условностей/договоренностей.

[defunct 0]

Резюмируя. Интерфейс это физическое средство/способ связи, а протокол это система условностей/договоренностей.

С примером все ОК, а вот с выводом - не согласен.

Интерфейсы в ВТ это способы взаимодействия разных уровней ОЗИ ;> между собой. Например интерфейс OpenGL позволяет app программисту общаться с разным железом видео карт разных производителей одинаково, но OpenGL сам при этом не является физическим средством, а всего лишь фантазия договоренностей функций и типов данных.

[syv 0]

Единственное, что бы добавить - автоматическую раздачу адресов

А вот это не надо.

Точно так же, как не надо и очереди сообщений и много другой чисто программистской чепухи.

Лично я, как потребитель , измученный различными сетями, такое бы брать не стал...

В обслуживании будет гемор.

 

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

К стати, ПМСМ, CAN не совсем попадает под определение 1 уровня OSI.

У него уже есть уровень 2 - разрешение конфликтов и некое поведенческое описание.

У того же MODBUS второй уровень полностью отвязан от первого.

Сейчас думаю реализовать его на оптике в качестве физ. уровня.

Интересно было бы посмотреть на CAN-оводов в этой ситуации...

 

[rezident 0]

С примером все ОК, а вот с выводом - не согласен.

Хорошо, давайте уберем слово "физический", но тогда это уже будет другой уровень абстракции. В топике же речь шла именно о физических интерфейсах!

 

[DogPawlowa 0]

Точно так же, как не надо и очереди сообщений и много другой чисто программистской чепухи.

А многомастерность уже закрыли?

 

Немного странно обсуждать протоколы, не видя перед глазами минимум требований:

- количество устройств в сети

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

- расстояние

- топология сети

- обстановка в части помех

 

 

[galjoen 0]

Сейчас думаю реализовать его на оптике в качестве физ. уровня.

Интересно было бы посмотреть на CAN-оводов в этой ситуации...

Живет CAN на оптике. Какие там проблемы то? Элемент 2-И добавить?

[syv 0]

Живет CAN на оптике. Какие там проблемы то? Элемент 2-И добавить?

И тем самым разрушить уровень 1 по OSI?

Там четко сказано - 2 открытых коллектора или стока.

 

[adnega 11]

Вроде, CANу от среды нужно немного:

- наличие двух состояний среды "доминантное" и "рецессивное";

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

 

Оптика: есть/нет света.

Радио: есть/нет модулированный сигнал

Витая пара: есть/нет разность напряжений.

Открытый коллектор, в конце концов.

[galjoen 0]

И тем самым разрушить уровень 1 по OSI?

Там четко сказано - 2 открытых коллектора или стока.

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

 

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

[syv 0]

Но модбас с ним даже рядом не стоит.

Правильно.

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

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

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

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

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

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

 

[defunct 0]

Хорошо, давайте уберем слово "физический", но тогда это уже будет другой уровень абстракции. В топике же речь шла именно о физических интерфейсах!

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

[rezident 0]

Почему другой?

Потому, что в "физике" нет ни фреймов, ни битов, а есть только Вольты, Амперы, Омы и секунды.

Зачем мы тратим столько времени на очевидные вещи?...

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

Или у вас есть опыт работы с RS485 сетями где используются фреймы отличные от UART'овских?

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

[defunct 0]

Потому, что в "физике" нет ни фреймов, ни битов, а есть только Вольты, Амперы, Омы и секунды.

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

Хорошо, давайте уберем слово "физический", но тогда это уже будет другой уровень абстракции.

Ровно один в один с абстракциями CAN и Ethernet интерфейсов. В которых внешняя часть оканчивается электрическими характеристиками, а внутренняя (со стороны программы на МК) - фреймами данных, правилами их формирования и декодирования.

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

 

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

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

Вопрос был более конкретным:

У вас есть опыт работы с RS485 сетями где используются фреймы отличные от UART'овских?

Так есть или нет такой опыт?

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

 

За себя отвечу - у меня опыт такой:

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

 

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

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

 

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