[NullPointer 0]

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

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

 

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

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

[zltigo 1]

А что если использовать MT9172

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

2. Еще надо будет железку для PC сделать добавив к чипу аппаратную поддержку того-же HDLC, ну и драйвер написать :).

Скажите лучше где грабли лежат в таком решении.

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

[mp41 0]

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

[skripach 5]

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

[NullPointer 0]

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

[zltigo 1]

Кстати, чипы и сегодня производятся Zarlink'ом,

Обалдеть, дейсвительно заглянул - Product Status: Production правда ни у кого из солидных оптовиков не видать их, а на заказчика вагонами

под которого подобные чипы выпускают, все еще выпускают, всякие Инфинеоны с Неками я не тяну.

Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я совершенно серьезно.

Кстати, ещё и специальные трансформаторы для этого дела нужны.

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

Тут HDLC, я думаю, не обязательно нужен был бы. MT9172 в модемном режиме передаёт в обе стороны прозрачный битовый поток, которому всё равно, что гонять, хоть линии RX/TX от RS-232, только бы совпадала битовая скорость.

Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации

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

[mp41 0]

Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я серьезно.

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

Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации

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

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

Изменено 27 декабря, 2009 пользователем МП41

[zltigo 1]

им очень удобен оказался U-интерфейс.

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

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

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

Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока.

[mp41 0]

Мне тоже :). Явки? Пароли?

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

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

Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока.

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

[zltigo 1]

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

Буду ждать!

[SM 0]

Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти.

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

[zltigo 1]

Я руководствуюсь лишь практическими результатами пользователей, которые используют 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 разбирается, как передать.

[SM 0]

Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP.

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

[zltigo 1]

....не отличаются. Так как протокол верхнего уровня и есть 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 радиолюбителями это

посылка текстовых сообщений - чат, в стиле вопрос - ответ.

[skripach 5]

"TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows.

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