[NullPointer 0]

А если ошибка в канале битовая... Начнутся перезапросы, перепосылки пакетов...

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

 

Без проблем, но его придется написать...

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

[AlexandrY 3]

Так параметры железки будем говорить или как? :wassat:

RTOS-ы портировать умеете?

Открытый, полноценный и качественный FTP сервер поверх PPP (HDLC, к сведению, является несущей PPP) который может работать

поверх асинхронных последовательных каналов есть только в демопакете MQX от Freescale.

Вам только портировать надо эту ось, драйвер UART-а и SDIO.

Профессионалу работы на неделю... ну не больше месяца

 

 

 

... Задача передавать файлы, удалять файлы, просматривать директории на SD-карте которая вставлена в "железку"...

[SM 0]

По полудуплексному каналу я предлагаю гонять только протокол верхнего уровня.

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

[zltigo 1]

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

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

 

 

(HDLC, к сведению, является несущей PPP)

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

[SM 0]

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

[zltigo 1]

X.25 умеет по полудуплексу ходить.

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

[AlexandrY 3]

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

Да и другие как сговорились все этот уровень HDLC называют.

 

А так согласен HDLC это битовый протокол.

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

 

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

[SM 0]

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

 

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

[zltigo 1]

Да и другие как сговорились все этот уровень HDLC называют.

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

уровня Data Link и могут называть как придется)->MLP->X.25

спецификации AX.25 ?

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.

Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно :(. Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

[SM 0]

Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно :(. Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

 

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

[AlexandrY 3]

Боюсь мужику все равно придется поверх X.25 лепить PPP.

А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

 

 

Ну а X.25, как и многое другое, писал собственноручно.

Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно :(. Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

[SM 0]

Боюсь мужику все равно придется поверх X.25 лепить PPP.

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

 

А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

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

 

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.

 

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

[zltigo 1]

Боюсь мужику все равно придется поверх X.25 лепить PPP.

А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

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

И вместо PPP SLIP пойдет на ура. Все, что требуется :(, это драйверок вместо RS232 разруливающий явные коллизии.

[AlexandrY 3]

Маразм крепчал...

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

 

...Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще...

[SM 0]

при наличии уровня LLC-MAC.

Что за новости? Это где еще такое в 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 в девайсе.