[Гость Igor_K]

Появился интерес заложить XPort в обновляемое устройство, параллельно с USB и RS232 (что больше понравится программерам, то и будет потом запаиваться :). Задача - обмен короткими сообщениями между устройством на МК и компьютером. Устойчивость связи очень важна - нужна бессбойная работа сутками напролет.

Вопросов два:

- Достаточно ли сигналов RX/TX между МК и XPort для организации нормального обмена по Ethernet с PC, или же надо задействовать и сигналы аппаратного управления потоком?

- Насколько надежен XPort в отношении аппаратных сбоев?

[rx3apf 0]

Появился интерес заложить XPort в обновляемое устройство, параллельно с USB и RS232 (что больше понравится программерам, то и будет потом запаиваться :). Задача - обмен короткими сообщениями между устройством на МК и компьютером. Устойчивость связи очень важна - нужна бессбойная работа сутками напролет.

Вопросов два:

- Достаточно ли сигналов RX/TX между МК и XPort для организации нормального обмена по Ethernet с PC, или же надо задействовать и сигналы аппаратного управления потоком?

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

[Гость Igor_K]

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

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

[one_man_show 0]

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

 

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

[Гость Igor_K]

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

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

Спасибо за ответ.

 

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

 

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

[one_man_show 0]

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

[rx3apf 0]

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

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

[one_man_show 0]

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