УКНЦ загрузка через стык С2

Воспринимая критику кабеля со стороны Vamos, хочу предложить следующий вариант:

Код:

---

Разъем                            Разъем
Стык С2                            DB9S
  1,10 (102) ■─────────────────────■    5 (GND)

  5    (103) ■──────────┐    ┌────■    3 (TD)
                  ┌────■│■────┘
  6    (104) ■────┘    └──────────■    2 (RD)

  3    (+5В) ■─              ┌────■    4 (DTR)
                              │
  7    (109) ■────────────────┤  ─■    1 (CD)
                              │
                              └────■    6 (DSR)

  2    (108) ■──────────┐    ┌────■    7 (RTS)
                  ┌────■│■────┘
  9    (107) ■────┘    └──────────■    8 (CTS)

---

Отличается тем, что на вход 7 УКНЦ (сигнал 109) подается не +5В с УКНЦ, а сигнал DTR с PC. Сразу предупрежу, что этот кабель для УКНЦ с квантовской схемотехникой. На УКНЦ с СЭМЗ-овской схемотехникой на вход 7 надо подавать ТТЛ-уровень, так что там остается вариант только с +5В.
Для нормального функционирования данного кабеля в настройках HX-сервера обязательно должны стоять следующие параметры:

Код:

---

fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_HANDSHAKE

StopBits = TWOSTOPBITS

fOutxCtsFlow = TRUE
fOutxDsrFlow = TRUE

---

hobot, RT1154Y_HX22_UKNC.rar запустил...

http://i.piccy_.info/i7/0b5ceecb7ba1...18_218_240.jpghttp://i.piccy_.info/a3/2013-01-11-1...40x180-r/i.gif

Цитата:

---

Сообщение от palsw

RT1154Y_HX22_UKNC.rar запустил...

---

там есть тест DR_Titusa ! )

Patron, Словил баг что ли - у меня образ всегда грузится с HX2:
На новой версии первый блок грузиться с HX2: а остальные только с HX0:.Тоесть образ должен быть загружен в HX0: и HX2: одинаковый и одновременно

Цитата:

---

Сообщение от palsw

Patron,

---

какой именно образ?

hobot, HX_Server 2.1_-_UKNC_11.01.13_16-10.rar из новой версии .Раньше я на HX0 и HX1 свои образы загружал,а в HX2 загрузочный образ был

Цитата:

---

Сообщение от Alex_K

Воспринимая критику кабеля со стороны Vamos, хочу предложить следующий вариант кабеля

---

Но если с этим вариантом кабеля сигнал DTR постоянно установлен через fDtrControl = DTR_CONTROL_ENABLE - то какой тогда смысл в fOutxDsrFlow = TRUE ?

Ведь, если на входе DSR всегда будет TRUE от DTR - никакого управления потоком через DSR не будет..

Цитата:

---

Сообщение от Patron

Но если с этим вариантом кабеля сигнал DTR постоянно установлен через fDtrControl = DTR_CONTROL_ENABLE - то какой тогда смысл в fOutxDsrFlow = TRUE ?

Ведь, если на входе DSR всегда будет TRUE от DTR - никакого управления потоком через DSR не будет..

---

А нет никакого смысла. Управление через DTR/DSR не ведется. А на самом деле смысл есть только в установке fDtrControl = DTR_CONTROL_ENABLE, чтобы открывало вход для посылок извне на УКНЦ, а fOutxDsrFlow = TRUE так для проверки, что DTR установился.

И какие вообще преимущества должен ( по идее ) дать пятый провод в кабеле, когда и четырёх проводов больше чем достаточно..

Ведь, провод RTS реально используется только тогда, когда сервер не забирает байты у Windows более 3 секунд ( а он обычно это делает 60 раз в секунду ). Если просто подать TRUE на вывод 9(107) и не распаивать провод RTS в кабеле - ни какой разницы при реальной работе не будет.

---------- Post added at 23:19 ---------- Previous post was at 23:15 ----------

Цитата:

---

Сообщение от Alex_K

А нет никакого смысла.

---

Не нужно вообще с DTR заморачиваться - это совершенно бессмысленная затея. Со стороны PC ни DTR, ни DSR распаивать не надо.

Цитата:

---

Сообщение от Patron

И какие вообще преимущества должен ( по идее ) дать пятый провод в кабеле, когда и четырёх проводов больше чем достаточно..

---

А каких четырех? Давайте считать. 1 - земля, 2 - принимаемые данные, 3 - передаваемые данные, 4 - контроль по CTS. Ну и если нет контроля по RTS, то с RTS или DTR подать сигнал на вход УКНЦ 7 (сигнал 109), иначе посылки приниматься не будут, это пятый.