Да никак не надо! Это далекооо от FTP клиента. FTP->IP->Ethernet Adapter->SLIP/PPP->RS232 Driver. Это ШТАТНАЯ фича Виндозного Dialup клиента. Только нажать на иконку "New Connection" и сказать, что надо. Для RS232 уже все уже прикручно до нас. На рубеже 90x лично пользовался широко .

Итак... если я правильно понял то варианта ничего не делать на PC + RS-485 нет так так RS-485 это полудуплекс.
Из RS-232 можно стандартными средствами "окон" вывести PPP, SLIP, X.25.
И может получится если вставить девайс между RS-232 и RS-485 для буферизации.
Всё правильно или чего-то я не так понял?

Про X.25 это пургу несли . И нет его поддержки в Win как класс. Только в Linux есть нечто писанное левой ногой и реально заброшенное на стадии Альфа еще в прошлом веке . Да и не нужен он Вам. Совсем. PPP и SLIP - да.

Или девайс, или драйвер заменяющий Виндозный RS232 и разруливающие хотя-бы большую часть коллизий. Что для Вас проще, то и делайте.

Всем спасибо.
Если есть ещё светлые мысли буду благодарен.

А что, лишней пары в кабеле совсем нету?

Есть, но ее уже тоже озвучивал - вместо драйвера простое приложение, которое выполняет функции некоего proxy - к нему лезут по IP, ну уж оно транслирует их в RS232 c учетом, что за ним halfdupleх. В свое время так и делал одну приблуду, бо под кучу разных Win писать драйвера было не рационально. А так оно хоть и старенькое, но живет до сих пор на всех Win. И будет, пока Winsock да
open( serial_port, ... ) поддерживаются . Кстати, его порт и под Linux живет. Дальше, только "ключи от квартиры, где деньги лежат"

Ну и тема!

Нда? А вот я попробовал! Цепочкой [браузер -> localhost:8080 -> софтина -> COM-порт -> железка] легко получаю пару html'ок из железа. Можно и остальное попробовать, но мне лень.. так что

В существующих сетях точно нет, да и в будущих вряд ли возможно.

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

Может я не ту софтину пробовал не ткнёте носом?

Вот именно "что"? В огороде бузина, в Киеве дядька.....

А что если использовать MT9172 в модемном режиме (по даташиту - "MOD MODE") - полный дуплекс по одной паре, до 6-и километров можно выжать, 80/160кбит в беспрерывном битовом потоке.

Я первую попавшуюся взял: ComPort/IP Server 2.2.

Второй бесполезный комментарий Скажите лучше где грабли лежат в таком решении.

1. BRI мертв давно и надежно - эти и подобные чипы достать можно только из складских отвалов по весьма эксклюзивной цене. На сетях сейчас всякие *DSL.
2. Еще надо будет железку для PC сделать добавив к чипу аппаратную поддержку того-же HDLC, ну и драйвер написать .

Грабли в том, что это ВООБЩЕ НЕ РЕШЕНИЕ поставленной задачи никаким боком.

Да, BRI отдаёт прошлым веком, хотя я знаю фирму, которая сегодня активно использует в своих изделиях связку MT9172+MT8952 (+ ещё куча). Кстати, чипы и сегодня производятся Zarlink'ом, хотя ценник действительно кусачий. Кстати, ещё и специальные трансформаторы для этого дела нужны. Тут HDLC, я думаю, не обязательно нужен был бы. MT9172 в модемном режиме передаёт в обе стороны прозрачный битовый поток, которому всё равно, что гонять, хоть линии RX/TX от RS-232, только бы совпадала битовая скорость. Но наверное без дополнительных МК для дополнительной синхронизации не обойтись, учитывая сетку стандартных скоростей RS-232.

SysRq Вы всё же не поняли суть моей задачи.

Всё, всё, я ушел...

Обалдеть, дейсвительно заглянул - Product Status: Production правда ни у кого из солидных оптовиков не видать их, а на заказчика вагонами
под которого подобные чипы выпускают, все еще выпускают, всякие Инфинеоны с Неками я не тяну.
Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я совершенно серьезно.

Это не проблема - мотальщики трансформаторов не умерли , да и NECовские армейские в керамических! DIP! я использую и трансформаторы соответственно есть. Ну а если без питания в линии, то вообще не проблема.

Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации
кроме битовой. Так вот, HDLC контроллеры традиционно и занимаются асинхронным запихиванием и извлечением из этого потока фреймов кратных 8битам.

Попробую спросить у них, при возможности.

Я знаю, но разве нельзя битовым потоком передать стартовый и стоповый биты UART'а? Про HDLC в лице MT8952 мне всё известно.

Мне тоже . Явки? Пароли? Я тоже знаю и тех, кто под крупным западником работает и у него нет проблем с поставками. И тех, кто развел платы под три варианта корпуса собирает по миру складские остатки Infineon по несколько сот штук (на полгода хватает). Хотя при этом являются официальным дилером Infineon .

Можно, но это будет практически тот-же резко усеченный HDLC c фиксированным размером фрейма в 8бит. Дополнительная железяка должна будет получать асинхронно! 10-12 бит фрейм от UART, сохранять его, по началу очередного бита его синхронно выпихивать.
Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока.

Я немножко подправил предыдущее сообщение.

В общем, я покуда ничего лучшего не вижу, хоть и вариант немного с бубном.

Буду ждать!

Да не успокоюсь. Решение какое-никакое, а готовое, и соответствующее поставленной задаче - без какого либо самописного софта на PC. Пользуются им многие, то что Вы их не знаете, этого не отменяет. Про то, что на PC win никто не говорил (или, если я пропустил, извиняюсь). Да и для win полно готовых решений для "TCP/IP через AX.25", только они не встроены в систему, а требуют установки. Что касается "тупо кидается" - он не "тупо кидается", а с рандомной задержкой, т.е. "тупо как Ethernet". Вообще в пакетном радио другого способа разрешения коллизий, кроме как в AX.25, просто нет, и все пакеты доходят, несмотря на Ваши сомнения. Тут уж "может не дойти, может дойти" - непрофессионально, давайте или не гадать вообще, или измеренные (или рассчитанные) результаты "сколько может не дойти при каком уровне коллизий", и почему. Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле.

Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP. C определенностью полагаю, что там протоколы/процедуры верхнего уровня сами по себе ПОЛУДУПЛЕКСНЫЕ и AX.25 в этом случае занимается разрешением потерь, равно, как и редких случайных коллизий канале, которые НИКАК не отличает от потерь вообще. Они действительно могут быть разрешены - выше я говорил, что и в "драйвере" для простоты можно и не гарантировать разрешения всех коллизий - верхний уровень сможет расхлебать последствия редких коллизий.
В FTP/TCP halfduplex не пахнет и коллизии будут ГАРАНТИРОВАННЫЕ и неразрешимые. Чего-нибудь будет пролезать разве только чудом и изредка.

P.S.
Посмотрел какую-то радиолюбительскую статью. В общем, по крайней мере в ней, буквы AX.25 вольно трактуются более, чем широко и к ним заодно валится в одну кучу Data Link уровень на котором действительно ожидаемо поминается контроль за занятостью канала передачи. Посмотрел исходники Линукса - то, что там написано не ведает, точнее не делает НИКАКИХ различий между simplex и duplex каналами. switch() везде присутствует, но они строго везде запаралелены. Пример:

В конце концов все передается железному уровню одинаково - dev_queue_xmit(skb) и нехай там некий dev разбирается, как передать.

не отличаются. Так как протокол верхнего уровня и есть TCP/IP. И я об этом уже писал - "TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows.

Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же.
Единственная причина изложена здесь:
http://www.a27.ru/information/bulleten/199...paketnoe-radio/

Так-что TCP/IP через AX.25 это только один из частных случаев. Насколько я могу понимать родное использование AX.25 радиолюбителями это
посылка текстовых сообщений - чат, в стиле вопрос - ответ.

А как это готовое называется и где можно взять.

А то самое, о чем тут? Разруливание коллизий полудуплекса [радиоканала]...


Да так и называется - "TCP/IP over AX.25", или "TCP/IP через AX.25". В линуксе оно встроено в ядро. А для виндовс надо что-то там искать, качать и ставить. Одно из них то-ли FlexNet, то-ли NetFlex. Я сам этим никогда не пользовался, ибо не радиолюбитель. Просто знаю о существовании и о некоторых свойствах, да и то без 100%-ной гарантии.

В линуксе оно вот этим самым

НЕ занимается. А снаружи "You can use a physical Packet Modem (Terminal Node Controller = TNC)"

Берите
http://www.wattystuff.net/amateur/packet/w...owsprograms.htm
будете шипеть соундбластером.

Тогда, повторю вопрос - зачем тогда в спецификации есть разделы, посвященный коллизиям, полудуплексу и их разруливанию?

TNC естественно есть, но он в себе содержит (по крайней мере содержал лет так 15-20 назад) именно только сам модем - просто тупо преобразующий поток данных в модулированный НЧ сигнал без каких либо LAP*, коррекций ошибок, и прочего. И AX.25 работает сразу поверх этого.

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

Если бы я сам решал бы эту задачу с тем, что готовый софт на PC - обязательное условие - просто собрал бы свой переходник RS232-RS485 с разруливанием коллизий внутри этого переходника, и SLIP или PPP сверху этого.

Повторяю ответ - радиолюбители не различают уровни модели . И под AX.25 подразумевают "все разу" начиная с HDLC/SLIP и до
собственно AX.25. Как уже писал, в том-же Линуксе в AX.25 исходниках нет следов ни только разруливания коллизий, но и даже HDLC/SLIP уровня. Всем этим должен заниматься какой-то виртуальный или железный девайс.
В комплексных решениях типа виндозной шипелки в соундбластер совершенно очевидно реализовано ВСЕ, но оно не пригодно Автору. Практически оно ему и не надо, ибо это то-же самое, что написать простейшее приложение, о котором я писал несколькими постами выше. Причем при написании такого приложения АБСОЛЮТНО лишняя сущность ввиде AX.25 не используется и ее не требуется реализовывать на стороне контроллера (походу поиска халявы для PC об этом забыли ).


Именно так, только пропустили еще функцию определение занятости канала передачи, как это, например, делает PHY для Ethernet коаксиала. И собственно HDLC запихивающий байты получаемые из асинхронного потока в битовый синхронный. Впрочем, думаю, что радиолюбители скорее всего используют вариант с байтовым потоком, т.е. поминаемый ранее SLIP (в линуксе поддерживаются и SLIP и HDLC нижние уровни). Далее по тексту...

Ну HDLC-уровень (правильнее - уровень битового потока) там действительно лежит на модеме и на уарте - это просто пропуск старт- и стоп- бит от RS-232 в канал и прием их обратно. У автора HDLC-уровень не нужен, так как старт- и стоп- биты проходят по его каналу без изменения, формируются уартом с одной стороны, и вырезаются с другой - т.е. этот уровень, правильнее сказать, не не нужен, а уже реализован в его железе уартами.

SLIP-уровня там НЕТ вообще, и никогда не было. Выход модема, после убирания из него старт- и стоп-бит при помощи "железки" под названием UART идет сразу на уровень AX.25

Касаемо определения занятости канала - RS-232 сигнал CD - Carrier Detect - он мог использоваться в AX.25 (CSMA/CA), но он не гарантирует защиты от коллизий, а лишь уменьтшает их вероятность, и это опция. Два передатчика все равно могут свободно начать передавать в примерно одно время, сотворив коллизию.

А почему в линуксовом варианте AX.25 нет следов вот этого (нумерация пунктов другая, так как я из другой версии спецификации взял):

6.3.6.1. Collisions in a Half-Duplex Environment
Collisions of frames in a half-duplex environment are taken care of by the retry nature of the T1 timer and
retransmission count variable. No other special action is required.

я просто не в курсе. Значит они не реализовали этот T1 таймер, и нарушили спецификацию.

В 90-х это может и работало, а в Viste и Windows 7 SLIP-а больше нет. Ибо не поддерживает аутентификацию.
Более того SLIP-а нет даже в затасканом стеке lwIP !!!
Так что ставлю 1 против 10, что мужик будет делать на PPP.

Да ладно. А slipif.c тогда зачем?

О господи, ну пакетный, это уровень. Пакетный! И никакими "уартами" занающими только о байтах он реализован быть не может. Ну никак.

А вот SLIP, как раз и собирает из байтов пакеты. Посему два варианта, либо HDLC собирает из битов фреймы сразу, либо из битов
UART обирает байты из которых потом SLIP собирает пакеты.

Посторяю, ну не понимает AX.25 поток байтов. Ему фреймы подавать надо. Вот, как выглядит в линуксе к котрому Вы меня отослали,
передача на уровень AX.25

AX.25 получает ГОТОВЫЕ ФРЕЙМЫ а не байты.

Ну и незачем пользоваться этими вперед ногами рожденными уродцами. Была более-менее нормальная XP, в ней SLIP есть, и все остальное куда прямее и нормальнее.


Да пусть там SLIP есть, пусть нет, это не суть важно, SLIP-у совершенно по барабану, дуплекс там в канале или полудуплекс. Вполне возможно, что у них там подразумевается, что SLIP входит в состав AX.25, если это не так на самом деле... Я же говорю - я не на столько знаток всей спецификации, спорить не буду. Главное - что коллизии разруливает именно AX.25 задержанными ретрансмитами, а не SLIP, и не кто-то там еще ниже. Ну пусть будет TCP/IP->AX.25->SLIP->UART->канал->все_в_обратном_порядке - суть в AX.25 лишь в том, чтобы разрулить полудуплекс, работать по которому он обучен изначально.

В XP есть - проверил .

Ну и что, что нет - там буквально несколько десятков строчек написать.
Вот аж цельный UDP/IP в SLIP-е отдается в какой-то поделке 80x годов



Тфу, устал уже объяснять кто чем занимается. Имеющий разум да поймет, а остальное не столь важно.

Хорошо, соглашусь с вами. Я тоже устал. Признаю - спецификацию AX.25 писали идиоты. Коллизии она вопреки спецификации не разруливает. По полудуплексу вопреки спецификации не работает. Все радиоканалы, на которых она используется, только полнодупдексные. А если у кого-то и работает по полудуплексу, то коллизии разруливает некая потусторонняя сила в модеме, который сам по себе умеет лишь модулировать несущую входным цифровым сигналом, без какой либо его "интеллектуальной" обработки (типа древних модемов V.23 и V.24 без всяких там MNP и прочих LAP-ов).

Нет, просто Вы пытаетесь рассказать, что в изобилии имеются некие программы, которые реализует на железе UART ВСЕ уровни ДО AX.25 включительно. Возможно, но могу точно сказать, что найденные в интернете ссылки на некие любительские программы и уж совершенно точно (исходники доступны всем) поминаемая Вами поддержка в ядре Линукса AX.25 занимается только ВЕРХНИМ уровнем, т.е. собственно самим AX.25 и совсем не занимается самым нижним уровнем, который в том числе и исключает бОльшую часть коллизий, как минимум НЕ допуская начала передачи в занятый канал. Это совершенно обыденный и естественный подход со времен того-же Ethernet на коаксиале. По причине основного недопущения коллизий на нижних уровнях (в железе/драйвере), как уже давал ссылку, радиолюбители и прямо без проблем используют ICP/IP, который, на самом деле является протоколом выполняющий такие-же задачи как X.25, AX.25, TCP/IP и так-же не знающий ничего о коллизиях в канале.
С таким-же успехом (повторяюсь ), если Автор напишет драйверок (или железку приладит) который будет поддерживать halfduplex на UART-е, и натравит на него простейший SLIP, то у него прекрасно заработает TCP/IP.

В общем, наличие хардварного детектора занятости канала и его использование (CSMA/CA), это лишь опция. AX.25 успешно работает (работал в те дальние года) у народа на полудуплексе и без этого. Что касается других уровней - да не против я того же SLIPа (других уровней между голым AX.25 и опять же голым модемом нет), но повторю, на количество и природу происхождения коллизий, как и на вид ошибок в результате коллизии, наличие или отсутствие этого уровня (SLIP) никак не скажется. А вот что касается спецификаций - так TCP/IP, на сколько я знаю, вообще не содержит ни слова про коллизию, и ни слова про полудуплекс. А AX.25 - содержит, и указывает на конкретные действия. В чем и одно из коренных отличий одного от другого. О чем я тут столько времени и говорю.

И я тоже не знаю, на сколько какая реализация сейчас соответствует спецификации, и что там в нее входит. Но то, что "оно" работает на полудуплексе с "голым" модемом, не содержащим в себе ничего, кроме модема, и никаких потусторонних дополнительных разруливалок коллизий, и CSMA/CA там нет - точно, сам видел на заре пакетной связи.


PS. Короче мне совсем надоел наш спор непонятно о чем. Пусть человек сам прочитает спецификацию в части полудуплекса и коллизии, и решит все, что ему там надо. Я привел номер главы/раздела/пункта, где это искать.

Вот эти "конкретные действия" НИЧЕМ не отличаются (случайное значение таймаута не принципиально) от действий ЛЮБОГО протокола верхнено уровня при потере/не подтверждении фрейма. Вызваны эти потери коллизиями в канале или еще чем всем протоколам LAP*/AX.25/X.25/TCP по барабану. Описыватели AX.25 помянули одну из причин потерь явно. Вот и все "коренное отличие" . При массовых коллизиях неразруленных на нижних уровнях захлебнется/подвестится любой из помянутых протоколов.

На самом деле не факт. Если ретрансмит делать через случайный промежуток времени с достаточным максимальным временем, то все эти массовые коллизии саморазрулятся. Да они наверное саморазрулятся даже только из-за разбега таймеров, если повезет .


А я это читаю, как "при коллизии достаточно этого действия, и применять дополнительных мер для их разруливания не требуется". Потому как описывать всякие возможные причины просто так, бесцельно, смысла нет.

Запустил lwIP без ОС на STM32 через SLIP, за основу взял проект с сайта ST. Вроде работает, даже через RS485, но не совсем, после строк

на PC приходит пакет длиной(указано в поле IP заголовка) в strlen(HELLO)+strlen(NAME)+заголовки, но в поле данных TCP только HELLO и все, конец пакета(реальная длина пакета не соответствует указанной в IP заголовке на strlen(NAME)), поэтому контрольная сумма считается неправильно и до telnet'а пакет не доходит.
Если так:

то работает, но прходит только HELLO
Что я делаю не так и как оно должно работать?

P.S. С TCP/IP раньше дела не имел.

Если это называется "работает", то что тогда называется не работает? Причины обсуждались медленно и подробно, достаточно.

Нет, это называется "вроде работает".

М.., поищу ещё.