Я первую попавшуюся взял: 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 мне всё известно.

Сообщение отредактировал МП41 - Dec 27 2009, 01:44

Мне тоже . Явки? Пароли? Я тоже знаю и тех, кто под крупным западником работает и у него нет проблем с поставками. И тех, кто развел платы под три варианта корпуса собирает по миру складские остатки 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 радиолюбителями это
посылка текстовых сообщений - чат, в стиле вопрос - ответ.

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