NullPointer 0 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Может я не ту софтину пробовал не ткнёте носом?Я первую попавшуюся взял: ComPort/IP Server 2.2. Вот именно "что"? В огороде бузина, в Киеве дядька..... :(Второй бесполезный комментарий :( Скажите лучше где грабли лежат в таком решении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба А что если использовать MT9172 1. BRI мертв давно и надежно - эти и подобные чипы достать можно только из складских отвалов по весьма эксклюзивной цене. На сетях сейчас всякие *DSL. 2. Еще надо будет железку для PC сделать добавив к чипу аппаратную поддержку того-же HDLC, ну и драйвер написать :). Скажите лучше где грабли лежат в таком решении. Грабли в том, что это ВООБЩЕ НЕ РЕШЕНИЕ поставленной задачи никаким боком. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mp41 0 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Да, BRI отдаёт прошлым веком, хотя я знаю фирму, которая сегодня активно использует в своих изделиях связку MT9172+MT8952 (+ ещё куча). Кстати, чипы и сегодня производятся Zarlink'ом, хотя ценник действительно кусачий. Кстати, ещё и специальные трансформаторы для этого дела нужны. Тут HDLC, я думаю, не обязательно нужен был бы. MT9172 в модемном режиме передаёт в обе стороны прозрачный битовый поток, которому всё равно, что гонять, хоть линии RX/TX от RS-232, только бы совпадала битовая скорость. Но наверное без дополнительных МК для дополнительной синхронизации не обойтись, учитывая сетку стандартных скоростей RS-232. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
skripach 6 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба SysRq Вы всё же не поняли суть моей задачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NullPointer 0 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Всё, всё, я ушел... :laugh: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Кстати, чипы и сегодня производятся Zarlink'ом, Обалдеть, дейсвительно заглянул - Product Status: Production правда ни у кого из солидных оптовиков не видать их, а на заказчика вагонами под которого подобные чипы выпускают, все еще выпускают, всякие Инфинеоны с Неками я не тяну. Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я совершенно серьезно. Кстати, ещё и специальные трансформаторы для этого дела нужны. Это не проблема - мотальщики трансформаторов не умерли :), да и NECовские армейские в керамических! DIP! я использую и трансформаторы соответственно есть. Ну а если без питания в линии, то вообще не проблема. Тут HDLC, я думаю, не обязательно нужен был бы. MT9172 в модемном режиме передаёт в обе стороны прозрачный битовый поток, которому всё равно, что гонять, хоть линии RX/TX от RS-232, только бы совпадала битовая скорость. Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации кроме битовой. Так вот, HDLC контроллеры традиционно и занимаются асинхронным запихиванием и извлечением из этого потока фреймов кратных 8битам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mp41 0 27 декабря, 2009 Опубликовано 27 декабря, 2009 (изменено) · Жалоба Будем считать, что для меня это, возможно, Новогодний подарок, если скажете источник к которому приникли коллеги из "знаю фирму, которая сегодня активно использует". Я серьезно. Попробую спросить у них, при возможности. Батенька, это НЕПРЕРЫВНЫЙ ПОТОК битов в котором нет, совсем нет никаких нарезок на байты и вообще какой-либо синхронизации кроме битовой. Так вот, HDLC контроллеры традиционно и занимаются асинхронным запихиванием и извлечения из этого потока фреймов кратных 8битам. Я знаю, но разве нельзя битовым потоком передать стартовый и стоповый биты UART'а? Про HDLC в лице MT8952 мне всё известно. :) Изменено 27 декабря, 2009 пользователем МП41 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба им очень удобен оказался U-интерфейс. Мне тоже :). Явки? Пароли? Я тоже знаю и тех, кто под крупным западником работает и у него нет проблем с поставками. И тех, кто развел платы под три варианта корпуса собирает по миру складские остатки Infineon по несколько сот штук (на полгода хватает). Хотя при этом являются официальным дилером Infineon :(. Я знаю, но разве нельзя битовым потоком передать стартовый и стоповый биты UART'а? Можно, но это будет практически тот-же резко усеченный HDLC c фиксированным размером фрейма в 8бит. Дополнительная железяка должна будет получать асинхронно! 10-12 бит фрейм от UART, сохранять его, по началу очередного бита его синхронно выпихивать. Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mp41 0 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Мне тоже :). Явки? Пароли? Я немножко подправил предыдущее сообщение. Можно, но это будет практически тот-же резко усеченный HDLC c фиксированным размером фрейма в 8бит. Дополнительная железяка должна будет получать асинхронно! 10-12 бит фрейм от UART, сохранять его, по началу очередного бита его синхронно выпихивать. Получите байтовый поток, на который потом будете вешать SLIP/PPP с байтстаффингом, дабы передавать фреймы. Лучше сделать это сразу зараз из битового потока. В общем, я покуда ничего лучшего не вижу, хоть и вариант немного с бубном. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Попробую спросить у них, при возможности. Буду ждать! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти. Да не успокоюсь. Решение какое-никакое, а готовое, и соответствующее поставленной задаче - без какого либо самописного софта на PC. Пользуются им многие, то что Вы их не знаете, этого не отменяет. Про то, что на PC win никто не говорил (или, если я пропустил, извиняюсь). Да и для win полно готовых решений для "TCP/IP через AX.25", только они не встроены в систему, а требуют установки. Что касается "тупо кидается" - он не "тупо кидается", а с рандомной задержкой, т.е. "тупо как Ethernet". Вообще в пакетном радио другого способа разрешения коллизий, кроме как в AX.25, просто нет, и все пакеты доходят, несмотря на Ваши сомнения. Тут уж "может не дойти, может дойти" - непрофессионально, давайте или не гадать вообще, или измеренные (или рассчитанные) результаты "сколько может не дойти при каком уровне коллизий", и почему. Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Я руководствуюсь лишь практическими результатами пользователей, которые используют 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 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP. не отличаются. Так как протокол верхнего уровня и есть TCP/IP. И я об этом уже писал - "TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба ....не отличаются. Так как протокол верхнего уровня и есть 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 6 27 декабря, 2009 Опубликовано 27 декабря, 2009 · Жалоба "TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows. А как это готовое называется и где можно взять. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться