Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум разработчиков электроники ELECTRONIX.ru _ FAQ по XPort/WiPort _ Подключение XPort к МК

Автор: Igor_K Sep 17 2008, 19:14

Появился интерес заложить XPort в обновляемое устройство, параллельно с USB и RS232 (что больше понравится программерам, то и будет потом запаиваться smile.gif. Задача - обмен короткими сообщениями между устройством на МК и компьютером. Устойчивость связи очень важна - нужна бессбойная работа сутками напролет.
Вопросов два:
- Достаточно ли сигналов RX/TX между МК и XPort для организации нормального обмена по Ethernet с PC, или же надо задействовать и сигналы аппаратного управления потоком?
- Насколько надежен XPort в отношении аппаратных сбоев?

Автор: rx3apf Sep 17 2008, 19:39

Цитата(Igor_K @ Sep 17 2008, 23:14) *
Появился интерес заложить XPort в обновляемое устройство, параллельно с USB и RS232 (что больше понравится программерам, то и будет потом запаиваться smile.gif. Задача - обмен короткими сообщениями между устройством на МК и компьютером. Устойчивость связи очень важна - нужна бессбойная работа сутками напролет.
Вопросов два:
- Достаточно ли сигналов RX/TX между МК и XPort для организации нормального обмена по Ethernet с PC, или же надо задействовать и сигналы аппаратного управления потоком?

Если есть уверенность в постоянной готовности хоста принимать данные (или их потеря некритична) и не надо следить за готовностью Xport принимать - то RxD/TxD вполне достаточно. А что, так мало ног ? Управление потоком - вещь полезная...

Автор: Igor_K Sep 18 2008, 04:58

Цитата(rx3apf @ Sep 17 2008, 22:39) *
Если есть уверенность в постоянной готовности хоста принимать данные (или их потеря некритична) и не надо следить за готовностью Xport принимать - то RxD/TxD вполне достаточно. А что, так мало ног ? Управление потоком - вещь полезная...

Еще как критична smile.gif Просто не хотелось вручную дергать дополнительными ножками. Но видно придется. Спасибо за ответ.

Автор: one_man_show Sep 19 2008, 13:10

Для полноценного обмена данными через XPort достаточно только Rx/Tx. Дополнительные линии управления сделаны для совместимости с теми устройствами, которые к нему подключаются со стороны последовательного порта smile.gif А для иных задач ему эти выводы совершенно не нужны. Как известно, у XPort есть три вывода, которые можно запрограммировтаь и для управления потоком (для совместимости), и для управления внешщними устройствами (ввод-вывод), и для индикации состояния (внтурення диагностика).

Доказательством того, что выводы управления потоком не нужны в процессе обмена служит помимо наличия внутренних буферов (для приема и для передачи) наличие "толстого" канала ethernet по сравнению с последовательным интерфейсом. То есть данные, принятые по последовательному каналу не будут тормозиться при передаче через ethernet. Это при условии, что связь возможно установить. Если связь невозможно установиьт или связь прервалась, для этого есть настройки, которые позволят без участия пользователя поступить с данными, застрявшими в буферах.

Автор: Igor_K Sep 19 2008, 17:24

Именно так я и предполагал, наскоро пробежав документацию по сабжу. Но после выше озвученного совета уже перерисовал проект, выделив ножки контроллера под "расширенный" RS. Пусть будут; не понадобятся - хорошо, меньше возни с программой.
Очень надеюсь, что все тормоза при обмене получится обойти, т.к. важна не только обязательная доставка посылок, но и оперативность.
Спасибо за ответ.

Цитата(one_man_show @ Sep 19 2008, 16:10) *
Для полноценного обмена данными через XPort достаточно только Rx/Tx. Дополнительные линии управления сделаны для совместимости с теми устройствами, которые к нему подключаются со стороны последовательного порта smile.gif А для иных задач ему эти выводы совершенно не нужны. Как известно, у XPort есть три вывода, которые можно запрограммировтаь и для управления потоком (для совместимости), и для управления внешщними устройствами (ввод-вывод), и для индикации состояния (внтурення диагностика).

Доказательством того, что выводы управления потоком не нужны в процессе обмена служит помимо наличия внутренних буферов (для приема и для передачи) наличие "толстого" канала ethernet по сравнению с последовательным интерфейсом. То есть данные, принятые по последовательному каналу не будут тормозиться при передаче через ethernet. Это при условии, что связь возможно установить. Если связь невозможно установиьт или связь прервалась, для этого есть настройки, которые позволят без участия пользователя поступить с данными, застрявшими в буферах.

Автор: one_man_show Sep 25 2008, 06:30

Можно эти три вывода одновременно завести на отдельный преобразователь и на какие-нибудь ключи или опторазвязки. Получится две опции: либо полный RS-232 при установленном преобразователе, либо ввод-вывод или управление внешними объектами (если не установлен преобразователь, но есть ключи или что-то подобное)

Автор: rx3apf Sep 25 2008, 07:34

Цитата(one_man_show @ Sep 19 2008, 17:10) *
Доказательством того, что выводы управления потоком не нужны в процессе обмена служит помимо наличия внутренних буферов (для приема и для передачи) наличие "толстого" канала ethernet по сравнению с последовательным интерфейсом. То есть данные, принятые по последовательному каналу не будут тормозиться при передаче через ethernet.

А обратно ? Если положиться на то, что от MC к Ethernet пройдет даже 921600 без приостановок лишь потому, что Ethernet быстрый (а ведь на пути к потребителю где-то может и dial-up встретиться - хватит буферов-то ? А если где-то через GPRS ? Это я не с потолка беру - это то, с чем регулярно приходится встречаться. Ведь не все ограничивается локалками...), то обратно, к MC, как без линии готовности ?

Автор: one_man_show Oct 3 2008, 09:35

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

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)