| |
 FTP по RS-485, Реально ли? |
|
|
|
 |
Ответов
(1 - 92)
|
|
 Dec 25 2009, 23:44
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата Вы сначала разберитесь, что у вас есть и что требуется. Вроде бы написал... Думаю нужно искать возможность замены физического,канального уровня с Ethernet на RS232-485 на стороне PC, есть ли варианты??? Цитата Тогда с 485 облом, хотя с RS232 можно. облом потому что не дуплекс? P.S. Вот интересно у модераторов красная лампочка зажигается или звоночек звенит когда создаётся новая тема. 
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 00:25
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Связь с "железкой" осуществляется по существующим каналам (PC->RS-232->RS-485->"железка"). Цитата Другой вопрос, как научить железку автора работать подобным образом. Вопрс не в том как научить "железку", а в том как вывеси FTP наружу из PC через RS-232, а не через Ethernet.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 00:36
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(skripach @ Dec 26 2009, 02:44)  облом потому что не дуплекс? Да. Цитата P.S. Вот интересно у модераторов красная лампочка зажигается или звоночек звенит когда создаётся новая тема. Это даже робот дежурный понимает, что тема создана не там.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 00:52
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата При помощи PPP или SLIP. Вот это уже похоже Цитата Это даже робот smile.gif дежурный smile.gif понимает, что тема создана не там. Перенесли правильно, удивило два первых ответа от модераторов с разницей в 2 минуты.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 16:48
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата Вам-же уже сказали Пардон сразу не понял. А что скажете насчет DHLC это вроде поверх 485?
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 18:32
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Скрин из википедии на которую меня послал rezidentКак видно и SLIP и PPP и HDLC являются протоколами канального уровня TCP/IP стека, но в отличие от SLIP и PPP HDLC является, по сведениям из той же википедии, протоколом который может работать поверх RS-485. Если изложенное в википедии верно, то у меня вопрос: Возможно ли применить какой-то стандартный(уже написанный) софт реализующий цепочку FTP-клиент->[некий софт]->HDLC->RS-232.
Эскизы прикрепленных изображений
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 19:32
|
Чайник, 1 литр
Группа: Свой
Сообщений: 655
Регистрация: 17-05-06
Из: Moscow
Пользователь №: 17 168
|
Цитата(zltigo @ Dec 26 2009, 22:13) К какому месту прикладывать для получения удовлетворения? К голове. Там в конце статейки ссылки на софт. Цитата The remserial program acts as a communications bridge between a TCP/IP network port and a Linux device such as a serial port. Any character-oriented Linux /dev device will work. Цитата TCP-Com is a software based serial port to TCP/IP Redirector, that can act as either a TCP/IP client or server. It allows you to turn your Windows PC into a "Serial Device Server"
|
|
|
|
|
|
|
|
Dec 26 2009, 20:22
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата TFTP-клиент <-> (локальный TCP\UDP порт) этот софт <-> (COM-порт) FTP-клиент никак не стыкуется "'этим софтом" ибо "этот софт" не передает TCP/IP пакеты в ком порт.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 20:22
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SysRq @ Dec 26 2009, 23:13) Ну вестимо у автора темы есть на ПК интерфейс RS485 (либо с преобразованием с RS232), вестимо в системе он представлен в виде последовательного порта  Почему бы не попробовать реализовать TFTP-клиент <-> (локальный TCP\UDP порт) этот софт <-> (COM-порт) RS485 <-> железо <-> TFTP-сервер?.. Это все (кроме 485)делается без всяких дополнительных приблуд, как уже описано выше. Цитата Полудуплекс RS485 помешать не должен.. Отнюдь, это полный кирдык, ибо средств разрешения конфликтов в драйвере RS232 не предусмотрено, за ненадобностью.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 20:45
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Вообще, чтобы ничего не создавать на PC, надо создать что-то вне PC - например сделать дуплексный 485, по двум парам. И всех делов. На это вроде тут уже намекали. Или, если в кабеле пар физически не хватает, как вариант, создать умный переходник 232-485, который бы и разруливал конфликты. Цитата(SysRq @ Dec 26 2009, 23:41) Исключить, выбрав протокол верхнего уровня с принципом запрос-ответ. А если ошибка в канале битовая... Начнутся перезапросы, перепосылки пакетов... Да и все TCP ACK-ки ходят дуплексно вместе с пакетами вне зависимости от того, что там за протокол "наверху". В общем встроенного средства заставить винду (да вроде и линь тоже, хотя тут не уверен) учитывать в TCP-уровне то, что канал недуплексный, нету.
|
|
|
|
|
|
|
|
Dec 26 2009, 20:45
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SysRq @ Dec 26 2009, 23:41) Исключить, выбрав протокол верхнего уровня... Без проблем, но его придется написать, причем для двух сторон, а не взять готовый их Windows, о чем тоже уже говорилось выше.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 20:45
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата в этом случае в COM-порт пойдут только данные из них, т.е. протокол верхнего уровня в чистом виде. хорошо бы ftp сразу в RS232, сейчас буду проверять, но наверное не так.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 26 2009, 20:51
|
Чайник, 1 литр
Группа: Свой
Сообщений: 655
Регистрация: 17-05-06
Из: Moscow
Пользователь №: 17 168
|
Цитата(SM @ Dec 26 2009, 23:45) А если ошибка в канале битовая... Начнутся перезапросы, перепосылки пакетов... Это loopback. Я сам себе сервер, сам себе клиент. По полудуплексному каналу я предлагаю гонять только протокол верхнего уровня. Цитата(zltigo @ Dec 26 2009, 23:45) Без проблем, но его придется написать... Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно.
|
|
|
|
|
|
|
|
Dec 26 2009, 20:53
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Так параметры железки будем говорить или как?  RTOS-ы портировать умеете? Открытый, полноценный и качественный FTP сервер поверх PPP (HDLC, к сведению, является несущей PPP) который может работать поверх асинхронных последовательных каналов есть только в демопакете MQX от Freescale. Вам только портировать надо эту ось, драйвер UART-а и SDIO. Профессионалу работы на неделю... ну не больше месяца  Цитата(skripach @ Dec 26 2009, 00:50) ... Задача передавать файлы, удалять файлы, просматривать директории на SD-карте которая вставлена в "железку"...
|
|
|
|
|
|
|
|
Dec 26 2009, 21:07
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SysRq @ Dec 26 2009, 23:51) Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно. Вы опять о чем-то, чего не понимаете,говорить пытаетесь  Цитата(AlexandrY @ Dec 26 2009, 23:53) (HDLC, к сведению, является несущей PPP) Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 21:20
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Слаб я в идеологии...  Это враги из Freescale называют физический уровнь PPP как HDLC. Да и другие как сговорились все этот уровень HDLC называют. А так согласен HDLC это битовый протокол. У нас одна уважаемая фирма даже собственный придумала формат тоннеля IP поверх FrameRelay с битовым HDLC и через свои спутниковые каналы качает с огромной скоростью. Цитата(zltigo @ Dec 26 2009, 23:07) Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.
|
|
|
|
|
|
|
|
Dec 26 2009, 21:35
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(AlexandrY @ Dec 27 2009, 00:20) Да и другие как сговорились все этот уровень HDLC называют. Для битовых потоков это так и есть - классика жанра. Тот-же X.25 лежит в таком случае поверх HDLC+LAPB(вот эту сладкую парочку уровня Data Link и могут называть как придется)->MLP->X.25 Цитата(SM @ Dec 27 2009, 00:22) спецификации AX.25 ? Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex. Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 21:42
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 00:35) Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери. А для любительского радио, для которого AX.25 придуман был, там других вариантов нет, как на этом уровне разбираться, ибо остальные аналоговые . Опять же по памяти - там делается тупо, как в Ethernet - если произошла коллизия, (слал более, чем один передатчик), ретрансмит по случайному таймеру. А вообще подробностей я не помню, очень давно это было, и разбираться-вспоминать в подробностях лень, да и времени нет, пусть автор сам смотрит, пойдет это ему, или не пойдет. Главное что оно на PC стандартными средствами есть.
|
|
|
|
|
|
|
|
Dec 26 2009, 21:56
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(AlexandrY @ Dec 27 2009, 00:45) Боюсь мужику все равно придется поверх X.25 лепить PPP. Что-то это масло масляное - TCP/IP over AX.25 over PPP Цитата(AlexandrY @ Dec 27 2009, 00:45) А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов? Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще (это тут только с жиру беситься - доменные имена вводить в 485-ой сети). А какие-то фиксированные адреса в RS-485 сети наверное уже и так есть... Которые видимо в AX.25 вид "позывной+SSID" придется переделать. Цитата(zltigo @ Dec 27 2009, 00:35) Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex. Блин, сорри, досадная опечатка вышла, букву пропустил... В этом сообщении http://electronix.ru/forum/index.php?showt...st&p=698806 - все три раза должно быть AX.25
|
|
|
|
|
|
|
|
Dec 26 2009, 21:58
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(AlexandrY @ Dec 27 2009, 00:45) Боюсь мужику все равно придется поверх X.25 лепить PPP.
А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов? Зачем? У него физическая точка-точка и на всякие адреса и шлюзы вообще плевать игнорируя - контроллеру можно вообще радостно откликаться на любой. Или речь идет о 485 "сети"? В ней по портам разойтись можно, И вместо PPP SLIP пойдет на ура. Все, что требуется , это драйверок вместо RS232 разруливающий явные коллизии.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 22:22
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(AlexandrY @ Dec 27 2009, 01:09) Только загвоздка, что штатные FTP сервера и клиенты понимают только вменяемые IP адреса Вменяемый не проблема, как позвали, так и ответит, тем более, что он может быть один на всех. Цитата и работают через штатные сокеты которые используют штатные таблицы маршрутизации. Да ни малейших проблем - работают и пусть. Цитата FTP сервер же открывает потом еще одно соединение. Естественно, но проблемы-то какие? Цитата Кастрировать все это хозяйство под некие упрощенные процедуры это будет знатный гемор. Никакой кастрации - легкая вставка игнорирующая IP, выхватывающая из IP адрес и заносящая его, как свой для ответных фреймов. Портировать-то IP стек по любому в котроллер надо. А вообще, чего это мы еще и о конфигурации IP? Статические адреса еще никто не отменял.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 22:43
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 01:05) AX.25. Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти. Нужно коллизии разруливать на байтово-фреймовом уровне пока навстречу идет фрейм свое буферизировать и не передавать. А при конфликте встречных фреймовых маркеров должно быть понятие уступающего слейва. И уж потом, если разрулили не 100% коллизий качественно, например, по причине упрощения разруливателя, то это тогда битое на IP вывалится и подчистится.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 23:33
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(skripach @ Dec 27 2009, 02:16) Из RS-232 можно стандартными средствами "окон" вывести PPP, SLIP, X.25. Про X.25 это пургу несли . И нет его поддержки в Win как класс. Только в Linux есть нечто писанное левой ногой и реально заброшенное на стадии Альфа еще в прошлом веке . Да и не нужен он Вам. Совсем. PPP и SLIP - да. Цитата(skripach @ Dec 27 2009, 02:16) И может получится если вставить девайс между RS-232 и RS-485 для буферизации. Или девайс, или драйвер заменяющий Виндозный RS232 и разруливающие хотя-бы большую часть коллизий. Что для Вас проще, то и делайте.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 26 2009, 23:57
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(skripach @ Dec 27 2009, 02:44) Если есть ещё всетлые мысли буду благодарен. Есть, но ее уже тоже озвучивал - вместо драйвера простое приложение, которое выполняет функции некоего proxy - к нему лезут по IP, ну уж оно транслирует их в RS232 c учетом, что за ним halfdupleх. В свое время так и делал одну приблуду, бо под кучу разных Win писать драйвера было не рационально. А так оно хоть и старенькое, но живет до сих пор на всех Win. И будет, пока Winsock да open( serial_port, ... ) поддерживаются . Кстати, его порт и под Linux живет. Дальше, только "ключи от квартиры, где деньги лежат"
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 00:08
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата А что, лишней пары в кабеле совсем нету? В существующих сетях точно нет, да и в будущих вряд ли возможно. Цитата Есть, но ее уже тоже озвучивал - вместо драйвера простое приложение Обязательно рассмотрю этот вариант, но это нужно что-то делать для PC, посмотрим... Цитата Нда? А вот я попробовал! Цепочкой [браузер -> localhost:8080 -> софтина -> COM-порт -> железка] Может я не ту софтину пробовал не ткнёте носом?
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 27 2009, 00:21
|
Чайник, 1 литр
Группа: Свой
Сообщений: 655
Регистрация: 17-05-06
Из: Moscow
Пользователь №: 17 168
|
Цитата(skripach @ Dec 27 2009, 03:08) Может я не ту софтину пробовал не ткнёте носом? Я первую попавшуюся взял: ComPort/IP Server 2.2. Цитата(zltigo @ Dec 27 2009, 03:15) Вот именно "что"? В огороде бузина, в Киеве дядька..... Второй бесполезный комментарий Скажите лучше где грабли лежат в таком решении.
|
|
|
|
|
|
|
|
Dec 27 2009, 00:34
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(МП41 @ Dec 27 2009, 03:15) А что если использовать MT9172 1. BRI мертв давно и надежно - эти и подобные чипы достать можно только из складских отвалов по весьма эксклюзивной цене. На сетях сейчас всякие *DSL. 2. Еще надо будет железку для PC сделать добавив к чипу аппаратную поддержку того-же HDLC, ну и драйвер написать . Цитата(SysRq @ Dec 27 2009, 03:21) Скажите лучше где грабли лежат в таком решении. Грабли в том, что это ВООБЩЕ НЕ РЕШЕНИЕ поставленной задачи никаким боком.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 00:54
|
4 синих кубика
Группа: Участник
Сообщений: 526
Регистрация: 19-09-08
Из: полупроводника, металла и стекла
Пользователь №: 40 326
|
Да, BRI отдаёт прошлым веком, хотя я знаю фирму, которая сегодня активно использует в своих изделиях связку MT9172+MT8952 (+ ещё куча). Кстати, чипы и сегодня производятся Zarlink'ом, хотя ценник действительно кусачий. Кстати, ещё и специальные трансформаторы для этого дела нужны. Тут HDLC, я думаю, не обязательно нужен был бы. MT9172 в модемном режиме передаёт в обе стороны прозрачный битовый поток, которому всё равно, что гонять, хоть линии RX/TX от RS-232, только бы совпадала битовая скорость. Но наверное без дополнительных МК для дополнительной синхронизации не обойтись, учитывая сетку стандартных скоростей RS-232.
--------------------
p-n-p-p-n-p-n-n-p-n-p структура однако очень эффективна
|
|
|
|
|
|
|
|
Dec 27 2009, 01:10
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(МП41 @ Dec 27 2009, 03:54) Кстати, чипы и сегодня производятся Zarlink'ом, Обалдеть, дейсвительно заглянул - Product Status: Production правда ни у кого из солидных оптовиков не видать их, а на заказчика вагонами под которого подобные чипы выпускают, все еще выпускают, всякие Инфинеоны с Неками я не тяну. Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я совершенно серьезно. Цитата Кстати, ещё и специальные трансформаторы для этого дела нужны. Это не проблема - мотальщики трансформаторов не умерли , да и NECовские армейские в керамических! DIP! я использую и трансформаторы соответственно есть. Ну а если без питания в линии, то вообще не проблема. Цитата Тут HDLC, я думаю, не обязательно нужен был бы. MT9172 в модемном режиме передаёт в обе стороны прозрачный битовый поток, которому всё равно, что гонять, хоть линии RX/TX от RS-232, только бы совпадала битовая скорость. Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации кроме битовой. Так вот, HDLC контроллеры традиционно и занимаются асинхронным запихиванием и извлечением из этого потока фреймов кратных 8битам.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 01:20
|
4 синих кубика
Группа: Участник
Сообщений: 526
Регистрация: 19-09-08
Из: полупроводника, металла и стекла
Пользователь №: 40 326
|
Цитата(zltigo @ Dec 27 2009, 03:10) Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я серьезно. Попробую спросить у них, при возможности. Цитата(zltigo @ Dec 27 2009, 03:10) Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации
кроме битовой. Так вот, HDLC контроллеры традиционно и занимаются асинхронным запихиванием и извлечения из этого потока фреймов кратных 8битам. Я знаю, но разве нельзя битовым потоком передать стартовый и стоповый биты UART'а? Про HDLC в лице MT8952 мне всё известно.
Сообщение отредактировал МП41 - Dec 27 2009, 01:44
--------------------
p-n-p-p-n-p-n-n-p-n-p структура однако очень эффективна
|
|
|
|
|
|
|
|
Dec 27 2009, 01:43
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(МП41 @ Dec 27 2009, 04:20) им очень удобен оказался U-интерфейс. Мне тоже . Явки? Пароли? Я тоже знаю и тех, кто под крупным западником работает и у него нет проблем с поставками. И тех, кто развел платы под три варианта корпуса собирает по миру складские остатки Infineon по несколько сот штук (на полгода хватает). Хотя при этом являются официальным дилером Infineon . Цитата Я знаю, но разве нельзя битовым потоком передать стартовый и стоповый биты UART'а? Можно, но это будет практически тот-же резко усеченный HDLC c фиксированным размером фрейма в 8бит. Дополнительная железяка должна будет получать асинхронно! 10-12 бит фрейм от UART, сохранять его, по началу очередного бита его синхронно выпихивать. Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 01:47
|
4 синих кубика
Группа: Участник
Сообщений: 526
Регистрация: 19-09-08
Из: полупроводника, металла и стекла
Пользователь №: 40 326
|
Цитата(zltigo @ Dec 27 2009, 03:43) Мне тоже . Явки? Пароли? Я немножко подправил предыдущее сообщение. Цитата(zltigo @ Dec 27 2009, 03:43) Можно, но это будет практически тот-же резко усеченный HDLC c фиксированным размером фрейма в 8бит. Дополнительная железяка должна будет получать асинхронно! 10-12 бит фрейм от UART, сохранять его, по началу очередного бита его синхронно выпихивать.
Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока. В общем, я покуда ничего лучшего не вижу, хоть и вариант немного с бубном.
--------------------
p-n-p-p-n-p-n-n-p-n-p структура однако очень эффективна
|
|
|
|
|
|
|
|
Dec 27 2009, 09:40
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 01:43) Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти. Да не успокоюсь. Решение какое-никакое, а готовое, и соответствующее поставленной задаче - без какого либо самописного софта на PC. Пользуются им многие, то что Вы их не знаете, этого не отменяет. Про то, что на PC win никто не говорил (или, если я пропустил, извиняюсь). Да и для win полно готовых решений для "TCP/IP через AX.25", только они не встроены в систему, а требуют установки. Что касается "тупо кидается" - он не "тупо кидается", а с рандомной задержкой, т.е. "тупо как Ethernet". Вообще в пакетном радио другого способа разрешения коллизий, кроме как в AX.25, просто нет, и все пакеты доходят, несмотря на Ваши сомнения. Тут уж "может не дойти, может дойти" - непрофессионально, давайте или не гадать вообще, или измеренные (или рассчитанные) результаты "сколько может не дойти при каком уровне коллизий", и почему. Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле.
|
|
|
|
|
|
|
|
Dec 27 2009, 12:05
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 12:40) Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле. Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP. C определенностью полагаю, что там протоколы/процедуры верхнего уровня сами по себе ПОЛУДУПЛЕКСНЫЕ и AX.25 в этом случае занимается разрешением потерь, равно, как и редких случайных коллизий канале, которые НИКАК не отличает от потерь вообще. Они действительно могут быть разрешены - выше я говорил, что и в "драйвере" для простоты можно и не гарантировать разрешения всех коллизий - верхний уровень сможет расхлебать последствия редких коллизий. В FTP/TCP halfduplex не пахнет и коллизии будут ГАРАНТИРОВАННЫЕ и неразрешимые. Чего-нибудь будет пролезать разве только чудом и изредка. P.S. Посмотрел какую-то радиолюбительскую статью. В общем, по крайней мере в ней, буквы AX.25 вольно трактуются более, чем широко и к ним заодно валится в одну кучу Data Link уровень на котором действительно ожидаемо поминается контроль за занятостью канала передачи. Посмотрел исходники Линукса - то, что там написано не ведает, точнее не делает НИКАКИХ различий между simplex и duplex каналами. switch() везде присутствует, но они строго везде запаралелены. Пример: Код void ax25_kick(ax25_cb *ax25)
{
.....
switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {
case AX25_PROTO_STD_SIMPLEX:
case AX25_PROTO_STD_DUPLEX:
ax25_send_iframe(ax25, skbn, (last) ? AX25_POLLON : AX25_POLLOFF);
break; В конце концов все передается железному уровню одинаково - dev_queue_xmit(skb) и нехай там некий dev разбирается, как передать.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 13:40
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 15:22) ....не отличаются. Так как протокол верхнего уровня и есть TCP/IP Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же. Единственная причина изложена здесь: http://www.a27.ru/information/bulleten/199...paketnoe-radio/Цитата AX.25 рассматривается как фактически стандартный протокол для использования в любительской радиосвязи и даже признается многими странами как легальный вид работы. Однако есть и другие стандарты. Любителями некоторых регионов используется TCP/IP. Часто используются специальные протоколы пакетного радио встраиваются внутрь пакетного формата AX.25. Это делается для обеспечения соответствия правилам, требующим, чтобы пакетные радиопередачи были в форме AX.25. Однако детали такого встраивания могут отличаться в различных странах. Так-что TCP/IP через AX.25 это только один из частных случаев. Насколько я могу понимать родное использование AX.25 радиолюбителями это посылка текстовых сообщений - чат, в стиле вопрос - ответ.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 13:52
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата "TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows. А как это готовое называется и где можно взять.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Dec 27 2009, 14:03
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 16:40) Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же. А то самое, о чем тут? Разруливание коллизий полудуплекса [радиоканала]... Цитата(skripach @ Dec 27 2009, 16:52) А как это готовое называется и где можно взять. Да так и называется - "TCP/IP over AX.25", или "TCP/IP через AX.25". В линуксе оно встроено в ядро. А для виндовс надо что-то там искать, качать и ставить. Одно из них то-ли FlexNet, то-ли NetFlex. Я сам этим никогда не пользовался, ибо не радиолюбитель. Просто знаю о существовании и о некоторых свойствах, да и то без 100%-ной гарантии.
|
|
|
|
|
|
|
|
Dec 27 2009, 14:08
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 17:03) В линуксе оно встроено в ядро. В линуксе оно вот этим самым Цитата разруливания коллизий полудуплекса радиоканала НЕ занимается. А снаружи "You can use a physical Packet Modem (Terminal Node Controller = TNC)" Цитата(skripach @ Dec 27 2009, 16:52) А как это готовое называется и где можно взять. Берите http://www.wattystuff.net/amateur/packet/w...owsprograms.htmбудете шипеть соундбластером.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 14:11
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 17:07) НЕ занимается. А снаружи "You can use a physical Packet Modem (Terminal Node Controller = TNC)" Тогда, повторю вопрос - зачем тогда в спецификации есть разделы, посвященный коллизиям, полудуплексу и их разруливанию? TNC естественно есть, но он в себе содержит (по крайней мере содержал лет так 15-20 назад) именно только сам модем - просто тупо преобразующий поток данных в модулированный НЧ сигнал без каких либо LAP*, коррекций ошибок, и прочего. И AX.25 работает сразу поверх этого. И вообще, я лишь предложил один вариант с готовым софтом, отработанным кучей радиолюбителей. А пойдет он конкретно в его окружении, или не пойдет - вопрос тридесятый, пусть сам автор вопроса и разбирается. Если бы я сам решал бы эту задачу с тем, что готовый софт на PC - обязательное условие - просто собрал бы свой переходник RS232-RS485 с разруливанием коллизий внутри этого переходника, и SLIP или PPP сверху этого.
|
|
|
|
|
|
|
|
Dec 27 2009, 14:39
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 17:11) Тогда, повторю вопрос - зачем тогда в спецификации есть разделы, посвященный коллизиям, полудуплексу и их разруливанию? Повторяю ответ - радиолюбители не различают уровни модели . И под AX.25 подразумевают "все разу" начиная с HDLC/SLIP и до собственно AX.25. Как уже писал, в том-же Линуксе в AX.25 исходниках нет следов ни только разруливания коллизий, но и даже HDLC/SLIP уровня. Всем этим должен заниматься какой-то виртуальный или железный девайс. В комплексных решениях типа виндозной шипелки в соундбластер совершенно очевидно реализовано ВСЕ, но оно не пригодно Автору. Практически оно ему и не надо, ибо это то-же самое, что написать простейшее приложение, о котором я писал несколькими постами выше. Причем при написании такого приложения АБСОЛЮТНО лишняя сущность ввиде AX.25 не используется и ее не требуется реализовывать на стороне контроллера (походу поиска халявы для PC об этом забыли ). Цитата(SM @ Dec 27 2009, 17:11) TNC естественно есть, но он в себе содержит (по крайней мере содержал лет так 15-20 назад) именно только сам модем - просто тупо преобразующий поток данных в модулированный НЧ сигнал без каких либо LAP*, коррекций ошибок, и прочего. Именно так, только пропустили еще функцию определение занятости канала передачи, как это, например, делает PHY для Ethernet коаксиала. И собственно HDLC запихивающий байты получаемые из асинхронного потока в битовый синхронный. Впрочем, думаю, что радиолюбители скорее всего используют вариант с байтовым потоком, т.е. поминаемый ранее SLIP (в линуксе поддерживаются и SLIP и HDLC нижние уровни). Далее по тексту... Цитата И AX.25 работает сразу поверх этого.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 15:01
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 17:39) Повторяю ответ - радиолюбители не различают уровни модели . И под AX.25 подразумевают "все разу" начиная с HDLC/SLIP и до собственно AX.25. Как уже писал, в том-же Линуксе в AX.25 исходниках нет следов ни только разруливания коллизий, но и даже HDLC/SLIP уровня. Ну 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 таймер, и нарушили спецификацию.
|
|
|
|
|
|
|
|
Dec 27 2009, 15:22
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 18:01) ...а уже реализован в его железе уартами. О господи, ну пакетный, это уровень. Пакетный! И никакими "уартами" занающими только о байтах он реализован быть не может. Ну никак. Цитата SLIP-уровня там НЕТ вообще, и никогда не было. А вот SLIP, как раз и собирает из байтов пакеты. Посему два варианта, либо HDLC собирает из битов фреймы сразу, либо из битов UART обирает байты из которых потом SLIP собирает пакеты. Цитата Выход модема, после убирания из него старт- и стоп-бит при помощи "железки" под названием UART идет сразу на уровень AX.25 Посторяю, ну не понимает AX.25 поток байтов. Ему фреймы подавать надо. Вот, как выглядит в линуксе к котрому Вы меня отослали, передача на уровень AX.25 Код /*
* Receive an AX.25 frame via a SLIP interface.
*/
int ax25_kiss_rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *ptype, struct net_device *orig_dev)
{
skb->sk = NULL; /* Initially we don't know who it's for */
skb->destructor = NULL; /* Who initializes this, dammit?! */
if (!net_eq(dev_net(dev), &init_net)) {
kfree_skb(skb);
return 0;
}
if ((*skb->data & 0x0F) != 0) {
kfree_skb(skb); /* Not a KISS data frame */
return 0;
}
skb_pull(skb, AX25_KISS_HEADER_LEN); /* Remove the KISS byte */
return ax25_rcv(skb, dev, (ax25_address *)dev->dev_addr, ptype);
} AX.25 получает ГОТОВЫЕ ФРЕЙМЫ а не байты.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 15:35
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(AlexandrY @ Dec 27 2009, 18:14) а в Viste и Windows 7 SLIP-а больше нет. Ну и незачем пользоваться этими вперед ногами рожденными уродцами. Была более-менее нормальная XP, в ней SLIP есть, и все остальное куда прямее и нормальнее. Цитата(zltigo @ Dec 27 2009, 18:22) Посторяю, ну не понимает AX.25 поток байтов. Ему фреймы подавать надо. Да пусть там SLIP есть, пусть нет, это не суть важно, SLIP-у совершенно по барабану, дуплекс там в канале или полудуплекс. Вполне возможно, что у них там подразумевается, что SLIP входит в состав AX.25, если это не так на самом деле... Я же говорю - я не на столько знаток всей спецификации, спорить не буду. Главное - что коллизии разруливает именно AX.25 задержанными ретрансмитами, а не SLIP, и не кто-то там еще ниже. Ну пусть будет TCP/IP->AX.25->SLIP->UART->канал->все_в_обратном_порядке - суть в AX.25 лишь в том, чтобы разрулить полудуплекс, работать по которому он обучен изначально.
|
|
|
|
|
|
|
|
Dec 27 2009, 15:41
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(AlexandrY @ Dec 27 2009, 18:14) В 90-х это может и работало, а в Viste и Windows 7 SLIP-а больше нет. В XP есть - проверил . Цитата Более того SLIP-а нет даже в затасканом стеке lwIP !!! Так что ставлю 1 против 10, что мужик будет делать на PPP. Ну и что, что нет - там буквально несколько десятков строчек написать. Вот аж цельный UDP/IP в SLIP-е отдается в какой-то поделке 80x годов CODE #define FR_END 0xC0
#define FR_ESC 0xDB
#define T_FR_END 0xDC
#define T_FR_ESC 0xDD
//---------------------------------------------------------------------------
void sendframe( )
{
int len = 0;
DWORD out_bl;
BYTE *ao_ptr = (BYTE *)&ao;
BYTE *so_ptr = slip_obuff;
int usize = sizeof(udp_Header)+sizeof(cmd_Header)+len;
int fsize = sizeof(in_Header)+usize;
int ssize = 0; // SLIP frame size
// ao.iph.ver = 4;
// ao.iph.hdrlen = 5;
// ao.iph.tos = 0x00;
ao.iph.length = htons( fsize );
ao.iph.identification = ++ident_flag;
// ao.iph.frag_ofs = 0x0000;
// ao.iph.ttl = 125;
// ao.iph.proto = 17;
// ao.iph.checksum = 0xFFFF;
// ao.iph.destination = htonl(0xC0A802C8);
// ao.iph.source = htonl(0xC0A802C9);
ao.iph.checksum = ~inchksum( ao_ptr, ao.iph.hdrlen * 4 );
// ao.udp.dstPort = htons( 9023 );
// ao.udp.srcPort = htons( 9023 );
ao.udp.length = htons( usize );
// ao.udp.checksum = 0x0000;
ao.hdr.ptype = CP_ALARM;
*(so_ptr++) = FR_END;
while( fsize-- )
{ if( *ao_ptr == FR_END )
{ *(so_ptr++) = FR_ESC;
*so_ptr = T_FR_END;
ssize++;
}
else if( *ao_ptr == FR_ESC )
{ *(so_ptr++) = FR_ESC;
*so_ptr = T_FR_ESC;
ssize++;
}
else
*so_ptr = *ao_ptr;
ssize++;
so_ptr++;
ao_ptr++;
}
*so_ptr = FR_END;
ssize += 2; // Double FR_END
WriteFile( hCom, slip_obuff, ssize, &out_bl, NULL );
} Цитата(SM @ Dec 27 2009, 18:35) Главное - что коллизии разруливает именно AX.25 Тфу, устал уже объяснять кто чем занимается. Имеющий разум да поймет, а остальное не столь важно.
Причина редактирования: Оформление кода
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 15:50
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 18:41) Тфу, устал уже объяснять кто чем занимается. Имеющий разум да поймет, а остальное не столь важно. Хорошо, соглашусь с вами. Я тоже устал. Признаю - спецификацию AX.25 писали идиоты. Коллизии она вопреки спецификации не разруливает. По полудуплексу вопреки спецификации не работает. Все радиоканалы, на которых она используется, только полнодупдексные. А если у кого-то и работает по полудуплексу, то коллизии разруливает некая потусторонняя сила в модеме, который сам по себе умеет лишь модулировать несущую входным цифровым сигналом, без какой либо его "интеллектуальной" обработки (типа древних модемов V.23 и V.24 без всяких там MNP и прочих LAP-ов).
|
|
|
|
|
|
|
|
Dec 27 2009, 16:14
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(SM @ Dec 27 2009, 18:50) Хорошо, соглашусь с вами. Я тоже устал. Признаю - спецификацию AX.25 писали идиоты. Нет, просто Вы пытаетесь рассказать, что в изобилии имеются некие программы, которые реализует на железе UART ВСЕ уровни ДО AX.25 включительно. Возможно, но могу точно сказать, что найденные в интернете ссылки на некие любительские программы и уж совершенно точно (исходники доступны всем) поминаемая Вами поддержка в ядре Линукса AX.25 занимается только ВЕРХНИМ уровнем, т.е. собственно самим AX.25 и совсем не занимается самым нижним уровнем, который в том числе и исключает бОльшую часть коллизий, как минимум НЕ допуская начала передачи в занятый канал. Это совершенно обыденный и естественный подход со времен того-же Ethernet на коаксиале. По причине основного недопущения коллизий на нижних уровнях (в железе/драйвере), как уже давал ссылку, радиолюбители и прямо без проблем используют ICP/IP, который, на самом деле является протоколом выполняющий такие-же задачи как X.25, AX.25, TCP/IP и так-же не знающий ничего о коллизиях в канале. С таким-же успехом (повторяюсь ), если Автор напишет драйверок (или железку приладит) который будет поддерживать halfduplex на UART-е, и натравит на него простейший SLIP, то у него прекрасно заработает TCP/IP.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Dec 27 2009, 16:29
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 19:14) По причине основного недопущения коллизий на нижних уровнях (в железе/драйвере), В общем, наличие хардварного детектора занятости канала и его использование (CSMA/CA), это лишь опция. AX.25 успешно работает (работал в те дальние года) у народа на полудуплексе и без этого. Что касается других уровней - да не против я того же SLIPа (других уровней между голым AX.25 и опять же голым модемом нет), но повторю, на количество и природу происхождения коллизий, как и на вид ошибок в результате коллизии, наличие или отсутствие этого уровня (SLIP) никак не скажется. А вот что касается спецификаций - так TCP/IP, на сколько я знаю, вообще не содержит ни слова про коллизию, и ни слова про полудуплекс. А AX.25 - содержит, и указывает на конкретные действия. В чем и одно из коренных отличий одного от другого. О чем я тут столько времени и говорю. И я тоже не знаю, на сколько какая реализация сейчас соответствует спецификации, и что там в нее входит. Но то, что "оно" работает на полудуплексе с "голым" модемом, не содержащим в себе ничего, кроме модема, и никаких потусторонних дополнительных разруливалок коллизий, и CSMA/CA там нет - точно, сам видел на заре пакетной связи. PS. Короче мне совсем надоел наш спор непонятно о чем. Пусть человек сам прочитает спецификацию в части полудуплекса и коллизии, и решит все, что ему там надо. Я привел номер главы/раздела/пункта, где это искать.
|
|
|
|
|
|
|
|
Dec 27 2009, 16:56
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(zltigo @ Dec 27 2009, 19:43) При массовых коллизиях неразруленных на нижних уровнях захлебнется/подвестится любой из помянутых протоколов. На самом деле не факт. Если ретрансмит делать через случайный промежуток времени с достаточным максимальным временем, то все эти массовые коллизии саморазрулятся. Да они наверное саморазрулятся даже только из-за разбега таймеров, если повезет . Цитата(zltigo @ Dec 27 2009, 19:43) Описыватели AX.25 помянули одну из причин потерь явно. А я это читаю, как "при коллизии достаточно этого действия, и применять дополнительных мер для их разруливания не требуется". Потому как описывать всякие возможные причины просто так, бесцельно, смысла нет.
|
|
|
|
|
|
|
|
Feb 9 2010, 11:14
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Запустил lwIP без ОС на STM32 через SLIP, за основу взял проект с сайта ST. Вроде работает, даже через RS485, но не совсем, после строк Код tcp_write(pcb, HELLO, strlen(HELLO), TCP_WRITE_FLAG_COPY);
tcp_write(pcb, NAME, strlen(NAME), TCP_WRITE_FLAG_COPY); на PC приходит пакет длиной(указано в поле IP заголовка) в strlen(HELLO)+strlen(NAME)+заголовки, но в поле данных TCP только HELLO и все, конец пакета(реальная длина пакета не соответствует указанной в IP заголовке на strlen(NAME)), поэтому контрольная сумма считается неправильно и до telnet'а пакет не доходит. Если так: Код tcp_write(pcb, HELLO, strlen(HELLO), TCP_WRITE_FLAG_COPY);
//tcp_write(pcb, NAME, strlen(NAME), TCP_WRITE_FLAG_COPY); то работает, но прходит только HELLO Что я делаю не так и как оно должно работать? P.S. С TCP/IP раньше дела не имел.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
|
Feb 10 2010, 07:30
|
■ ■ ■ ■
Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443
|
Цитата называется "работает" Нет, это называется "вроде работает". Цитата Причины обсуждались М.., поищу ещё.
--------------------
Делай что должен и будь что будет.
|
|
|
|
|
|
|
 |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
