roboforum.ru

frig писал(а):и как в i2c с контролем доставки, адрессацией, бродкастом, потоковой передачей, скользящими окнами и остальным? нормально?

Единственное чего реально может быть нужно на текущем уровне развития - контроль доставки. Однако побить пакеты по i2c вероятность думаю не больше, чем у того же ИК-дальномера или сонара выдать глючное измерение, а значит особого ужаса оно не представляет.

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

Не понял о чем речь?

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

О каком TCP/IP по UART'у может идти речь? Чего там нужно кроме контроля доставки?

Единственное чего реально может быть нужно на текущем уровне развития - контроль доставки.

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

Не понял о чем речь?

о том, что такое одоробло на роботе мало кому будет интересно.

О каком TCP/IP по UART'у может идти речь? Чего там нужно кроме контроля доставки?

тебе все равно прийдется все заворачивать в ip. другого способа отправить данные в ip сеть (коей является интернет) просто нет. это все равно произойдет. да и подозреваю, что ты упираешься, так как думаешь, что это сложно и дорого? но на сколько я понимаю, все это работает на доступных avr, которые здесь не новость. сильно не вчитывался, так как с ангельским плохо, но вот:
http://www.laskater.com/projects/uipAVR.htm
http://www.embeddedrelated.com/usenet/e ... 7424-1.php

frig писал(а):о том, что такое одоробло на роботе мало кому будет интересно.

Ху из одоробло?

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

Не, я просто думаю что это пока не нужно народ с i2c-мультимастером то не работает, а ты TCP\IP замутить предлагаешь... те проекты, которые ты предложил - не замечаешь, что там мега128 (сколько стоит?) и кучка обвязки еще, иначе это только логическая часть, ты серьезно считаешь что имеет смысл это городить? Кому это надо? Голосование устрой - кто не переживёт без TCP\IP между контроллером и датчиками?

Пробросить ком чезез tcp\ip? Не проблема — в примерах к PySerial есть махонькая програмка для этого.

Реализацию на ПК я вижу такой:

1. Нужно написать демона, который с одной стороны общается с платформой, а с другой предоставляет интерфейс к пользовательской программе. (бакэнд)
   Какой интерфейс не имеет значения, это может быть и tcp и unix-сокет и dbus и т.п.
   Главное чтобы пользовательское приложение могло получить высокоуровневый асинхронный доступ (мы же собрались замахнуться на веб)
2. Пишется веб-приложение (fcgi, wsgi, etc.) которое взаимодействует с пользователем. (фронтэнд)

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

Добавлено спустя 4 минуты 15 секунд:
Заворачивание всего низкоуровневого трафика в ip не вижу смысла.
Это не нужное переусложнение системы. Следуйте KISS.
В I2C есть адресация, и ее достаточно для работы с датчиками.
Броаткаст ЕМНИП тоже есть.

DeaD
Так вы хотите на базе своих модулей городить управление через инет ?
ИМХО слишком мутная штука выйдет и дорогая по железу.

Проще Линукс поставить на МК у которого уже есть встроенный Ethernet и библиотеки

Зато как красиво выйдет в реализации.
Представте сколько влезет полезного в МК с 512МБ ПЗУ и 64кБ ОЗУ на скорости 72МГц-а

Там вам и Telnet и Веб-сервер и стек нормальный...

Добавлено спустя 47 секунд:
И чип дешевле меги128

RoboTok писал(а):DeaD
Так вы хотите на базе своих модулей городить управление через инет ?
ИМХО слишком мутная штука выйдет и дорогая по железу.

Ничего себе выводы пока я наоборот говорю frig'у, что смысла нет делать TCP/IP до ИК-дальномера и нужно на нижнем уровне юзать i2c и UART.

А лучше, как я, взять NGW100 который работает на 150МГц с линем на борту и будет вам щастье

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

Ха, нада сделать переходник LAN->UART

Сергей писал(а):Ха, нада сделать переходник LAN->UART

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

Заворачивание всего низкоуровневого трафика в ip не вижу смысла.

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

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

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

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

А где они системно описаны-то эти чужие грабли и наработки?
Начинаешь делать что-то новое, пытаешься собрать информацию и понимаешь, что ничего нет, приведена какая-то отрывочная информация, используются какие-то супер-пупер чипы, которые, как по-волшебству что-то там делают, а что и зачем не всегда понятно.
И зачастую принимаешь решение сделать все с нуля!

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

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

Народу, когда нужен велосипед, не очень нравится постепенно урезать до него поезд

Добавлено спустя 1 минуту 33 секунды:

mandigit писал(а):выступаю противником мощной аппаратуры для простых роботов. не надо в радиоуправляемую тележку пихать 512К памяти и портированный линух, что-бы поморгать светодиодом

А вот тут всего лишь вопрос совокупной стоимости (включающей не только стоимость железа, но и стоимость времени на его освоение). Сейчас AVR работает на частотах 16МГц и имеет килобайты памяти, а на них делают робота, который может стукнувшись бампером отъехать назад и повернуть. И что?

=DeaD= писал(а):А вот тут всего лишь вопрос совокупной стоимости (включающей не только стоимость железа, но и стоимость времени на его освоение). Сейчас AVR работает на частотах 16МГц и имеет килобайты памяти, а на них делают робота, который может стукнувшись бампером отъехать назад и повернуть. И что?

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

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

Народу, когда нужен велосипед, не очень нравится постепенно урезать до него поезд

разобрать ip пакет несколько проще, чем урезание поезда. там вообще ничего сложного нет. а главное что содержит он тоже самое, что прийдется делать в своем протоколе. т.е. разницы в разборе своего пакета и ip НЕ БУДЕТ. разница будет в совместимости.

зы у меня такое впечатление складывается, что народ или не знает или придуривается, что не знает формата ip и tcp пакетов...