Ничего, поскольку набор букв DHLC лично мне ни о чем не говорит. Если это HDLC, то ни к какому halfduplex эти буквы тоже отношения не имеют. Что Вы пытаетесь узнать? Как сделать так, что-бы ничего не делать? Не получится. Придется писать драйвер для поддержки своего железа. FTP/IP/PPP(SLIP) Windows Вам предоставит, остальное сами. Можете обойтись и без драйвера - напишите какое-нибудь приложение выполняющее роль шлюза и имеющее с одной стороны RS232->RS485 а с другой стороны изображающий локальный FTP сервер для Win.

Скрин из википедии на которую меня послал rezident
Как видно и SLIP и PPP и HDLC являются протоколами канального уровня TCP/IP стека, но в отличие от SLIP и PPP HDLC является, по сведениям из той же википедии, протоколом который может работать поверх RS-485.
Если изложенное в википедии верно, то у меня вопрос:
Возможно ли применить какой-то стандартный(уже написанный) софт реализующий цепочку FTP-клиент->[некий софт]->HDLC->RS-232.

В одну сторону совершенно без проблем . Ну НЕ имеет он отношение к дуплексу никакого. И вообще он в потоке битов а не байтов работает. Что, дальше Википедии заглянуть не судьба?

http://en.wikipedia.org/wiki/COM_port_redirector

К какому месту прикладывать для получения удовлетворения?

Насколько я понимаю эта штука позволяет создать прозрачный RS-232 через интернет.

К голове. Там в конце статейки ссылки на софт.

Ну тогда приложите и подумайте как этот софт поможет физически вылезти из писишки RS485-тым.

Ну вестимо у автора темы есть на ПК интерфейс RS485 (либо с преобразованием с RS232), вестимо в системе он представлен в виде последовательного порта
Почему бы не попробовать реализовать TFTP-клиент <-> (локальный TCP\UDP порт) этот софт <-> (COM-порт) RS485 <-> железо <-> TFTP-сервер?.. Полудуплекс RS485 помешать не должен..

FTP-клиент никак не стыкуется "'этим софтом" ибо "этот софт" не передает TCP/IP пакеты в ком порт.

Это все (кроме 485)делается без всяких дополнительных приблуд, как уже описано выше.

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

skripach, в этом случае в COM-порт пойдут только данные из них, т.е. протокол верхнего уровня в чистом виде.

Исключить, выбрав протокол верхнего уровня с принципом запрос-ответ. Железке отдем логическую роль slave. Чем TFTP не подходит?

Вообще, чтобы ничего не создавать на PC, надо создать что-то вне PC - например сделать дуплексный 485, по двум парам. И всех делов. На это вроде тут уже намекали. Или, если в кабеле пар физически не хватает, как вариант, создать умный переходник 232-485, который бы и разруливал конфликты.


А если ошибка в канале битовая... Начнутся перезапросы, перепосылки пакетов... Да и все TCP ACK-ки ходят дуплексно вместе с пакетами вне зависимости от того, что там за протокол "наверху". В общем встроенного средства заставить винду (да вроде и линь тоже, хотя тут не уверен) учитывать в TCP-уровне то, что канал недуплексный, нету.

Без проблем, но его придется написать, причем для двух сторон, а не взять готовый их Windows, о чем тоже уже говорилось выше.

хорошо бы ftp сразу в RS232, сейчас буду проверять, но наверное не так.