roboforum.ru

Для чего нужен полноценный TCP/IP?

в будущем. я говорю о том, что он будет нужен.

для передачи мультимедийной информации, для работы через интернет. прозрачно, без шлюзов на базе компов. просто через домашний роутер или gsm модем. к тому же надо учитывать, что для простых задач хватит одного только IP (без tcp поверх) и это будет легче и проще, но оно все так же будет совместимо и также будет работать в IP сетях.

немного не в тему, но вот ссылка. давно смотрел на эту тему. толи как дешевого вариант ethernet "контроллера" для меги, толи как пример работы IP на меге. исходники дома гдето лежат. могу поискать.

Мультимедиа тут не к месту. Совсем другие ресурсы нужны. Ну не прокачаем мы мелкими своими МК такой объем информации.
GSM модем - стек встроенный. Без GSM как раз шлюз на ПК будет в самый раз. Есть этот самый ПК у всех. И к интернету подключен.

Мультимедиа тут не к месту. Совсем другие ресурсы нужны.

значит когда будет нужна мультимедия (к коей относится передача голоса, которой взялся заниматься EdGull) - огород будем городить другой или даже параллельный?

Ну не прокачаем мы мелкими своими МК такой объем информации.

а вот тогда уже может быть и не мелкий МК, а вот стек и совместимость - на месте. когда наступает "зоопарк" в протоколах и нет совместимости - самая большая гадость. начинаются подпорки, падения и нестабильность.

Есть этот самый ПК у всех. И к интернету подключен.

я повторюсь. и жрет он минимум 300+ ватт в то время, как робот ест 3. + ко всему еще и шумит. а вот домашний adsl роутер несколько другой уровень. но и он позволит "выпустить" робота в интернет (опять же не изобретая NAT под свои адреса) и жрет меньше и работает тише... и включенным его можно оставить и на ночь и на отпуск. а еще в компе есть неприятные вещи типа винта и куллеров. которые суть механика и подвержены износу.

да и если развить мысль с роутером - он может быть с wifi который смотрит за 20км от места роботы робота. это уже полупромышленное решение, конечно, но оно остается в минимальном бютжете и работает на доступных средствах. применить в таких условиях комп я бы не рискнул.

Добавлено спустя 5 минут 14 секунд:
ЗЫ еще раз делаю акцент на том, что я не считаю это основными или массовыми решениями, я только хочу показать возможности применения универсального и уже практически готового решения.

blindman писал(а):Мультимедиа тут не к месту. Совсем другие ресурсы нужны. Ну не прокачаем мы мелкими своими МК такой объем информации.
GSM модем - стек встроенный. Без GSM как раз шлюз на ПК будет в самый раз. Есть этот самый ПК у всех. И к интернету подключен.

Если рассматривать Эдову платку, CC2500 поддерживает максимальную скорость до 500 кбит/с, кое для чего этого хватит, а мелкий МК в его плате можно использовать как транспортный МК, который будет перенаправлять данные по UART на основной МК...

Я не против TCP/IP в принципе. Есть готовые реализации стэка, используйте их, если нужно. Но по-моему не имеет смысла делать какой-то урезанный вариант.

Урезанный вариант будет проще и позволит его использовать в простых проектах. А существующие полные реализации это тяжеловато. Хотя с другой стороны если на плате с радио все равно будет МК, то тогда, имхо, вообще можно ничего сильно и не урезать.

Да, 60 байт - это я малость ошибся (как в том анекдоте - "с прямым углом перепутал" ). 40 байт - 20 на IP и 20 на TCP. И плюс еще свою обертку, аналогичную Ethernet-кадру, тоже придется наворачивать, в чистом виде IP к работе в разделяемой среде не очень приспособлен.

В общем, есть минусы у TCP/IP, как его не обкусывай. Поэтому тут мы все же рассмотрим несовместимый с ним вариант с мелкими пакетами. Потому что вот что, ИМХО, действительно является дурной работой - так это писать очередную урезанную версию TCP/IP. Есть uIP - наверное самая мелкая реализация, с возможностью откусывания ненужных фич, ее даже можно кое-как втиснуть в атмегу8: http://www.sics.se/~adam/old-uip/size.html - и еще на пакетный драйвер немножко останется.

Но этому поводу есть одна идейка. Можно попробовать унифицировать интерфейс нашего пакетного драйвера СС2500 с uIP. И тогда тот, кому надо, соберет его с uIP и получит веб-сервер на боте . А тот, кому не надо - соберет с нашим протоколом и не будет гонять 40 байт заголовка и три байта данных. Я пару лет назад, в качестве хобби, писал экономную по памяти реализацию VoIP протокола IAX для МК LPC21xx поверх uIP. Если б работу не поменял, дописал бы - он реально уже умел логиниться на АТС asterisk и делать звонок . Поэтому собирать uIP умею и писать что-то подобное не хочу, поскольку там все сделано за нас - собрал и оно работает. Я чуток попозже гляну, что там за интерфейс к драйверу, но вроде бы как раз что-то подходящее.

И плюс еще свою обертку, аналогичную Ethernet-кадру, тоже придется наворачивать, в чистом виде IP к работе в разделяемой среде не очень приспособлен.

канальный уровень писать прийдется что так что эдак.

В общем, есть минусы у TCP/IP, как его не обкусывай.

тут без вопросов, конечно. универсальные решения всегда менее гибкие.

Но этому поводу есть одна идейка. Можно попробовать унифицировать интерфейс нашего пакетного драйвера СС2500 с uIP.

идейка оч хорошая. и правильная. унификация это хорошо.

Поэтому собирать uIP умею и писать что-то подобное не хочу, поскольку там все сделано за нас - собрал и оно работает.

ну вот. "мы не ищем легких путей"?

важным и одним из основных моментов мне видится как раз унификация интерфейсов, чтобы можно было без проблем цеплять одно к другому. что uIP к радио, что к BT, так и этот некий простой протокол без кардинальных переделок (а лучше вообще без них). в общем я за четкое разделение уровней и унификацию интерфейсов. а там хоть голубями передавать.

Добавлено спустя 2 минуты 46 секунд:
и еще. ветку бы разделить .

frig писал(а):важным и одним из основных моментов мне видится как раз унификация интерфейсов, чтобы можно было без проблем цеплять одно к другому. что uIP к радио, что к BT, так и этот некий простой протокол без кардинальных переделок (а лучше вообще без них). в общем я за четкое разделение уровней и унификацию интерфейсов. а там хоть голубями передавать

Вот и общий знаменатель.

Унификацию ИМХО важнее всего делать на верхнем уровне - прицепил новую реализацию и вперед. А как там оно внизу рабоет - не барское дело.

Унификацию ИМХО важнее всего делать на верхнем уровне

а мне кажется, что надо лепить физический канальный и сетевой транспортный. соответственно получается 2 интерфейса канальный-сетевой и транспортный-приложения. тогда можно безболезненно заменить любую связку либо физический с канальным уровнем (радио на ИК) либо сетевой-транспортный (простой протокол на IP) и при этом унификация на верхнем уровне позволит все это единообразно использовать.

Господа
а зачем аткие сложности?

вот лично я уже нихрена не понимаю
и явно не смогу пользоваться тем что вы тут понапридумываете

у нас скорости дохрена 500 килобит
почему нельзя всем сразу работать?

по принципу кто первый того и тапки

первый начинает передачу и все остальные по прерыванию на приём остановили болтовню и слушают
потом ктото следующий стартует передачу все остальные слушают

вы же не мультики гонять собрались
а всего лишь радиоканал для роботов

вот лично я уже нихрена не понимаю
и явно не смогу пользоваться тем что вы тут понапридумываете

а вот это зря ты так. как раз сможешь и будешь. а если оно будет соответственно обрисовано интерфейсами и описано, то оно вообще тебе будет как семечки щелкать. а что там внутри тебе будет глубоко фиолетово.

по принципу кто первый того и тапки

это уже относится к получению доступа к среде. этим должен заниматься канальный уровень.

первый начинает передачу и все остальные по прерыванию на приём остановили болтовню и слушают
потом ктото следующий стартует передачу все остальные слушают

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

вы же не мультики гонять собрались

ну это вопрос спорный..

frig писал(а):в радио будет проблема с тем, что одновременно говорить и слушать нельзя. переключение между приемом и передачей занимает некоторое время и вполне вероятна ситуация когда заговорят двое одновременно. в этот момент все выслушают кашу из эфира и ребята начнут повторную передачу. таким образом жрется как пропускная способность так и время доставки данных.

и пофик, пускай заговорят (хотя это ещё надо обсудить какова вероятность что они одновременно заговорят) мы эти 500 кбит пока даже не придумали чем забить =)

команды влево вправо и температуру воздуха мы бум передавать легко.

нафик роботу канал 500 килобит? 62 килобайта в секунду
если каждому роботу надо 1 килобайт передать максимум
вот например вот стока информации это 1 килобайт:
(012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678
012345678012345678012345678012345678012345678012345678012345678012345678)

то это займёт всего 1/60 секунды

за секунду десяток роботов между собой обменяются всей возможной информацией учитывая всякие маловероятные коллизии.

и пофик, пускай заговорят (хотя это ещё надо обсудить какова вероятность что они одновременно заговорят)

вероятность есть, иначе бы в сетях такого понятия как коллизия небыло бы вообще. и более того. чем больше будет участников обмена тем больше будет желающих передавать и тем меньше будет пропускная способность, к томуже вероятность возникновения коллизий будет тоже выше. т.е. вдвоем будет может быть и комфортно. а вот если больше - уже нет.

мы эти 500 кбит пока даже не придумали чем забить =)

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

нафик роботу канал 500 килобит?

передача видео и аудио. это было в этой теме. эт во первых, а во-вторых всеж роботы несколько более широкое понятие чем "тележка о двух колесах". тот же умный дом приводимый в этой теме тоже можно рассматривать.

Myp, ты думаешь CSMA/CA придумали дураки? или сделали они это от хорошей жизни или от лени? или может им плохо жилось с CSMA/CD?

frig писал(а):а мне кажется, что надо лепить физический канальный и сетевой транспортный. соответственно получается 2 интерфейса канальный-сетевой и транспортный-приложения. тогда можно безболезненно заменить любую связку либо физический с канальным уровнем (радио на ИК) либо сетевой-транспортный (простой протокол на IP) и при этом унификация на верхнем уровне позволит все это единообразно использовать.

Во - именно этого и стоит добиваться. Вообще моя изначальная идея была только в унификации интерфейса "канальный-сетевой". К примеру - следовать интерфейсу драйвера uip, у которого всего 3 функции - init, read и send. Вопрос об интерфейсе между транспортом и приложением - чуть сложнее, надо внимательнее смотреть, тем более что за эти 2 или 3 года uip как-то изменился

Возможно, что добиваться совместимости на уровне приложения и не стоит (а может и правда стоит) - нужно оценить, чего нам это будет стоить по ресурсам. Реализация протокола, которая становится на место uIP, ведет себя точно так же, но с другими ограничениями на значения адресов и портов, и с сильно сокращенным размером заголовка - это конечно идеальный вариант.

Вот еще пришли на ум 2 вещи, о нужности которых есть сомнения.
1. Инициация и завершение TCP-соединений (спец. пакетами).
2. Серверные порты (один порт на адресе, к которому могут быть подключены несколько клиентских портов, с точки зрения приложения на этом адресе - это несколько отдельных каналов связи). Нужно ли это, или хватит соединений "точка-точка", 1 порт - одно соединение.

Обе этих возможности в TCP/IP есть, но для реализации удлиннителя уарта особо не нужны. Надо подумать, что может быть еще кроме уарта, к чему может понадобиться такая функциональность. Датчики?

frig писал(а):а вот это зря ты так. как раз сможешь и будешь. а если оно будет соответственно обрисовано интерфейсами и описано, то оно вообще тебе будет как семечки щелкать. а что там внутри тебе будет глубоко фиолетово

Именно так.