Может не совсем Ethernet но всё же...
Задача передавать файлы, удалять файлы, просматривать директории на SD-карте которая вставлена в "железку".
Связь с "железкой" осуществляется по существующим каналам (PC->RS-232->RS-485->"железка").
Вопрос реально ли сделать подобие FTP сервера но по RS-485.
Очень хотелось бы для PC ничего не создавать, а пользоваться стандартным FTP-клиентом.

Вы сначала разберитесь, что у вас есть и что требуется.
RS232, RS485, Ethernet это интерфейсы - физический уровень сети, а FTP это протокол, прикладной уровень. См. описание сетевой модели OSI

Тогда с 485 облом, хотя с RS232 можно.

Вроде бы написал...
Думаю нужно искать возможность замены физического,канального уровня с Ethernet на RS232-485 на стороне PC, есть ли варианты???

облом потому что не дуплекс?

P.S. Вот интересно у модераторов красная лампочка зажигается или звоночек звенит когда создаётся новая тема.

RS485 может быть и дуплексом (две пары проводов) и полу-дуплексом (одна пара).

В полнодуплексном варианте это уже RS422, а не 485.

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

Связь с "железкой" осуществляется по существующим каналам (PC->RS-232->RS-485->"железка").

Вопрс не в том как научить "железку", а в том как вывеси FTP наружу из PC через RS-232, а не через Ethernet.

При помощи PPP или SLIP.

Да.

Это даже робот дежурный понимает, что тема создана не там.

Вот это уже похоже


Перенесли правильно, удивило два первых ответа от модераторов с разницей в 2 минуты.

Так всё таки как (чем) на PC связать Ftp-клиент и COM-порт?

Вам-же уже сказали SLIP/PPP на выбор натягивается на RS232. Поддержка коих в Win штатно есть (помните слово "модем"? - так вот это оно и есть). Поддержка SLIP на стороне контроллера несколько десятков строчек и дело в шляпе - IP поднят и ходите, чем хотите. Но это дуплекс. Если 485,
то придется для Win драйвер вместо RS232 писать, который будет разруливать проблемы.

Пардон сразу не понял.
А что скажете насчет DHLC это вроде поверх 485?

Нужна реализация TCP/IP для COM-порта.

Ничего, поскольку набор букв 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, сейчас буду проверять, но наверное не так.

Это loopback. Я сам себе сервер, сам себе клиент. По полудуплексному каналу я предлагаю гонять только протокол верхнего уровня.

Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно.

Так параметры железки будем говорить или как?
RTOS-ы портировать умеете?
Открытый, полноценный и качественный FTP сервер поверх PPP (HDLC, к сведению, является несущей PPP) который может работать
поверх асинхронных последовательных каналов есть только в демопакете MQX от Freescale.
Вам только портировать надо эту ось, драйвер UART-а и SDIO.
Профессионалу работы на неделю... ну не больше месяца

И как винду (или линь, на PC может работать самая разная ось) это заставить делать без какого-то доп. софта для PC? Один хрен все готовые утилиты работают через сокеты, а сокеты - через набор имеющихся драйверов, включающих и протоколы нижнего уровня. Вариант лишь один - брать какой-то опенсурс клиент и переписывать под свой транспорт. Что противоречит условию - ничего на PC не делать

Вы опять о чем-то, чего не понимаете,говорить пытаетесь



Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.

Кстати, если применить AX.25 - то пожалуй и можно сделать все то, что хочет сделать автор, вроде по памяти X.25 умеет по полудуплексу ходить. А TCP/IP over AX.25 есть на PC (как минимум в лине) встроенными средствами.

Разумеется нет.

Слаб я в идеологии... Это враги из Freescale называют физический уровнь PPP как HDLC.
Да и другие как сговорились все этот уровень HDLC называют.

А так согласен HDLC это битовый протокол.
У нас одна уважаемая фирма даже собственный придумала формат тоннеля IP поверх FrameRelay с битовым HDLC и через свои спутниковые каналы качает с огромной скоростью.

А про что тогда пишут в "2.4.3.5 Collision Recovery", а именно "2.4.3.5.1 Collisions in a Half-Duplex Environment" спецификации AX.25 ?

Для битовых потоков это так и есть - классика жанра. Тот-же X.25 лежит в таком случае поверх HDLC+LAPB(вот эту сладкую парочку
уровня Data Link и могут называть как придется)->MLP->X.25

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.
Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

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

Боюсь мужику все равно придется поверх X.25 лепить PPP.
А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

Что-то это масло масляное - TCP/IP over AX.25 over PPP


Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще (это тут только с жиру беситься - доменные имена вводить в 485-ой сети). А какие-то фиксированные адреса в RS-485 сети наверное уже и так есть... Которые видимо в AX.25 вид "позывной+SSID" придется переделать.



Блин, сорри, досадная опечатка вышла, букву пропустил... В этом сообщении http://electronix.ru/forum/index.php?showt...st&p=698806 - все три раза должно быть AX.25

Зачем? У него физическая точка-точка и на всякие адреса и шлюзы вообще плевать игнорируя - контроллеру можно вообще радостно откликаться на любой. Или речь идет о 485 "сети"? В ней по портам разойтись можно,
И вместо PPP SLIP пойдет на ура. Все, что требуется , это драйверок вместо RS232 разруливающий явные коллизии.

Маразм крепчал...
DHCP используют вообще-то только при наличии уровня LLC-MAC. Хотя можно в принципе наверно предложить коллеге эмулировать LLC и МАС поверх RS485.

Что за новости? Это где еще такое в RFC-2131 написано? UDP+броадкасты есть - значит и DHCP реализуем, и совершенно все равно, что там ниже, MAC или не MAC.
Да и реализуется он (DHCP) "одной левой", если уж человек на FTP позарился. Хотя в контексте - фиксированные айпишники всем, и вперед.

Короче - если TCP/IP over AX.25 встроен в ядро ОС на PC, то и какой-то протокол преобразования IP-адресов в AX.25 адреса (по аналогии с изернетовским ARP) тоже там есть. Дело за малым - поднять AX.25 и TCP/IP over AX.25 в девайсе.

Ничего не имею против такой технологии. Тоже хороший ход.
Только загвоздка, что штатные FTP сервера и клиенты понимают только вменяемые IP адреса и работают через штатные сокеты которые используют штатные таблицы маршрутизации. FTP сервер же открывает потом еще одно соединение.
Кастрировать все это хозяйство под некие упрощенные процедуры это будет знатный гемор.

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

Да ни малейших проблем - работают и пусть.

Естественно, но проблемы-то какие?

Никакой кастрации - легкая вставка игнорирующая IP, выхватывающая из IP адрес и заносящая его, как свой для
ответных фреймов. Портировать-то IP стек по любому в котроллер надо. А вообще, чего это мы еще и о конфигурации IP? Статические адреса еще никто не отменял.

Да, я думаю мы недооцениваем мануальную терапию.

Осталось только выяснить как этот SLIP или что там.. X.25 присобачить скажем к FTP клиенту Total Соmmander-а?

Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти. Нужно коллизии разруливать на байтово-фреймовом уровне пока навстречу идет фрейм свое буферизировать и не передавать. А при конфликте встречных фреймовых маркеров должно быть понятие уступающего слейва. И уж потом, если разрулили не 100% коллизий качественно, например, по причине упрощения разруливателя, то это тогда битое на IP вывалится и подчистится.

А какой-нибудь telnet не решит задачу топикстартера? На имеющемся типе связи его вроде проще поддержать. Или нет?