Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Протокол для RS485
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам
muravei
Если взять за физический уровень 485 , а по нему пустить:
1 Обычный асинхронный последовательный
2 Манчестер
3 С тайм-слотами , типа 1-варе.
Что будет лучше(выше, дальше, быстрей) smile.gif
Arch_Grey
Цитата(muravei @ Mar 22 2007, 09:18) *
Если взять за физический уровень 485 , а по нему пустить:
1 Обычный асинхронный последовательный
2 Манчестер
3 С тайм-слотами , типа 1-варе.
Что будет лучше(выше, дальше, быстрей) smile.gif


Навскидку можно предположить следущее:

1 Обычный асинхронный последовательный - особенности следуют из названия, накладные расходы: 1
старт-бит, минимум 1 стоп т.е от 20%;
2 Манчестер - одновременный поток данных и синхронизации, преимущество - нет постоянной составляющей (что для 485 несущественно), недостаток - надо в два раза шире полоса т.е накладные расходы около 100%;
3 С тайм-слотами , типа 1-варе - не совсем понятно, что значит "С тайм-слотами", но это интерфейс с запросом мастером каждого бита, т.е. запросить бит и подождать ответ какое-то время, зависящее от свойств физической линии, что, вероятно, приведет к накладным не менее 100%.

Таким образом можно сделать вывод, что эти интерфейсы оптимальны для для тех физических линий, с которыми традиционно и применяются.
muravei
Цитата(Arch_Grey @ Mar 22 2007, 13:48) *
что, вероятно, приведет к накладным не менее 100%.

А что предача CRC и повторы при обычном асинхр. не приведут к повышению накладных?
Arch_Grey
Цитата(muravei @ Mar 23 2007, 09:47) *
А что предача CRC и повторы при обычном асинхр. не приведут к повышению накладных?


При сравнении этих протоколов рассматривались "накладные" на передачу одного байта при одинаковой скорости переключения в линии. А предача CRC во-первых производится 1 раз на пакет (скажем 2 байта на 200 т.е. ~ 1%), а во-вторых непонятно почему при одних и тех-же физической линии и требованиях к надежности передачи при асинхронном протоколе надо CRC, а при других протоколах не надо. То же относится и к повторам. Почему тройное квитирование принимаемого бита в стандартном асинхронном приемнике менее надежно, чем фиксирование фронта в Манчестере или одиночное квитирование в 1-варе?
muravei
Цитата(Arch_Grey @ Mar 23 2007, 15:29) *
Почему тройное квитирование принимаемого бита в стандартном асинхронном приемнике менее надежно, чем фиксирование фронта в Манчестере или одиночное квитирование в 1-варе?

Потому что в них синхронизируется каждый бит.
В моем случае 1 байт и будет 100%
Arch_Grey
Цитата(muravei @ Mar 23 2007, 17:29) *
Потому что в них синхронизируется каждый бит.
В моем случае 1 байт и будет 100%


Для успешного приема бита из линии необходимо, чтобы он во-первых стробировался в нужное время, а во-вторых чтобы его действительное значение установилось на входе премника. В Манчестере приемник синхронизирутеся непосредственно сигналом, а при передаче байта асинхронно разность частоты сихронизации передатчика-приемника может составлять несколько процентов, что легко обеспечить. Будем считать что стробирование в нужное время обеспечивается и там и там. А вот то, что при Манчестере на один бит сигнал может дернуться 2 раза означает, что для надежного приема надо либо уменьшать скорость передачи, либо длину линии. А это первоначальной задачи "дальше, быстрее" это вряд ли решит.
rumit2000
Цитата(muravei @ Mar 22 2007, 11:18) *
Если взять за физический уровень 485 , а по нему пустить:
1 Обычный асинхронный последовательный
2 Манчестер
3 С тайм-слотами , типа 1-варе.
Что будет лучше(выше, дальше, быстрей) smile.gif

моё мнение что этот выбор сродни "Дёшево,Быстро,Качественно - выбери 2 любых пункта"
т.е. надо выбрать что более приоритетно - надёжность передачи, скорость, дальность и исходя из этого произвести выбор...
Вот например у меня 1-wire (стандартный) на 600м с даласовской таблеткой работал... (а вот митраконовская(помоему это их таблеточки с буковками МК) ) на 300м. затыкались при такой реализации...)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.