roboforum.ru

юзайте CAN

...хммм... что-то не нашел законченного документа, хотя мне казалось, что он был. Правда я за это время несколько компов сменил...
Вот, в ПДФах мои размышления на тему протоколов и модульности.

Файл "Проектирование модульной системы" посвежее. Я его планировал потом дополнить дельными мыслями из более раннего айла, который тоже публикую. Вот он:

Гляньте - может что полезное для вас найдете.

ЗЫ
Кстати, прошу заметить, что RoboBUS мной использовался еще в 2006 году. И он не имеет никакого отношения к робобасу, который развивается сейчас на форуме.

ЗЗЫ
Еще раз извиняюсь, что выдаю плохоструктурированную инфу вместо полноценного документа.

Добавлено спустя 22 минуты 8 секунд:
Про адресацию.
Чтоб все было совместимо с и2с я надумал такую штуку (не помню уже, описано это в файликах или нет).
Вначале немного "терминологии".
Интеллектуальное устройство (ИУ) - устройство на шине и2с, которое может быть и мастером и слейвом, имеет на борту контроллер или ПЛИСbye какую-то и реализует протокол РобоБАС (в моем понимании).
НеИнтеллектуальное устройство (НИУ) - стандартное устройство и2с, типа памяти или прочего. Те же Девантехи - это НИУ.

Итак, и2с позволяет законным образом определить ИУ следующими путями:
1. широковещательное сообщение (адрес "0").
всякие МС памяти и т.п. нулевой адрес просто проигнорируют. вообще, не помню НИУ, которые отрабатывали бы броадкасты. Ну да не важно. Мы шлем броадкаст и следом байт команды, которая обозначает "ответь мне". Даже если НИУ будет отрабатывать такой броадкаст, то по стандарту и2с оно после адреса "0" получит адрес регистра и ничего страшного не произойдет. А ИУ будет в курсе, что после адреса "0" оно получило команду, в ответ на которую оно должно что-то (например, инфу о себе) заслать в шину в режиме слэйв-передатчик. Если ИУ много на шине, то они стандартными механизмами арбитража разрулят сами и все отчитаются на запрос.
Вот так и можно определить, что за устройство на шине и есть ли ИУ. И при этом стандарт не нарушим. Правда можно посбивать текущие регистры в НИУ... Ну и не очень изящно в целом - много всего гонять по шине.
2. второй вариант разруливать - это использовать зарезервированные адреса.
По стандарту и2с при 10-байтной адресации есть некоторые значения первого передаваемого байта (если надо - могу сказать, какие - лень счас в даташит лезть), которые обозначают, что общение идет по какому-то другому протоколу. Например, SMBus. Так вот, некоторые из этих значений обозначают конкретные шины, а некоторые - зарезервированы для последующего использования. Так вот можно оборзеть и прихватить такой "зарезервированный" диапазон. Тогда с НИУ можно общаться по стандартному и2с, а с ИУ - как по стандартному и2с, так и по "продвинутому". Одно ИУ может пинговать другое устройство по "продвинутому" протоколу. Если оно отвечает - значит оно ИУ и мы можем запрашивать у него инфу в рамках нашего протокола. А если не отвечает - значит мы с ним как с НИУ поговорим и все.

Ну вот как-то так.

2Digit: А можешь сформулировать, какие задачи ты решал своим новым протоколом, которые не были решены в штатном i2c? Автодетект подключенных к шине устройств?

blindman писал(а):Под устройством на шине I2C имеется в виду то, что Digit называет неинтеллектуальным устройством.

Короче ты хочешь принять стандарт расширяющий I2C, которому будут удовлетворять все наши модули?
А оно надо? Какую задачу мы решаем? Давай сначала её сформулируем и обсудим надо ли её решать?

Добавлено спустя 35 секунд:
А то я не знаю вопросы на ваши ответы

avr123.nm.ru писал(а):

Digit писал(а): I2C - мой протокол

Ну и ну !

Ну да, если отрывать от контекста, то забавно звучит.

=DeaD= писал(а):2Digit: А можешь сформулировать, какие задачи ты решал своим новым протоколом, которые не были решены в штатном i2c? Автодетект подключенных к шине устройств?

Я хотел сделать расширение для и2с, полностью совместимое (ну или максимально совместимое) со стандартом и2с и отвечающее задачам робототехники. Причем хотел сделать нечто вроде Robotis (о котором там где-то в файле написано). Что-то вроде плаг-эн-плэя тоже думал, но это не было задачей, а скорее получилось само собой.
Переделать и2с не собирался. Как раз наоборот - сделать такой протокол, чтоб стандартными возможностями и2с было удобно работать с различными модулями.
Почему подумал в сторону расширения протокола. Хотел сделать определение типов подключенных ИУ, т.к. интересна задача самообучения. На мембране как-то пробегала статейка про робота, который сам учился передвигаться... Вот хотелось копнуть в этом направлении.

Dead, создается ощущение, что после переезда думать стало сложнее.. i2c решит проблему управления устройством висящим на SPI на накотором устройстве подключенным к ПК произвольным транспортом?

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

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

да... в нем 1 минус.. адресация железная.. с помощью чип селекта )) кстати с вариантом blindmana мона разрулить и спи...