roboforum.ru

юзайте CAN

blindman писал(а):при адресации встроенного контроллера передаём адрес, регистр и данные
при адресации подчиненного - адрес, регистр и данные

Не понял, а это тогда что имелось в виду:

blindman писал(а):Адресация в протоколе - двухбайтная. Если старший байт == 0, адресуется устройство на шине I2C, иначе - внутренний ресурс контроллера. В последнем случае старший байт адреса задает I2C адрес контроллера, младший - внутренний адрес ресурса

Или уже не актуально? А то иначе получается, что формат передачи адреса и регистра для локального или подчиненного контроллера отличается, что не есть унификация?

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

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

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

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

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

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

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

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

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

Ну и ну !

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

=DeaD= писал(а):Не понял, а это тогда что имелось в виду:

blindman писал(а):Адресация в протоколе - двухбайтная. Если старший байт == 0, адресуется устройство на шине I2C, иначе - внутренний ресурс контроллера. В последнем случае старший байт адреса задает I2C адрес контроллера, младший - внутренний адрес ресурса

Или уже не актуально? А то иначе получается, что формат передачи адреса и регистра для локального или подчиненного контроллера отличается, что не есть унификация?

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

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

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

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

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

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

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

Ну и ну !

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

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

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

Duhas писал(а):как я вижу.. ваша задача - с одного устройства управлять множеством других... этот "стандарт" как раз ее и решает...

Эту задачу решает голый I2C

Добавлено спустя 6 минут 16 секунд:

Digit писал(а):Хотел сделать определение типов подключенных ИУ, т.к. интересна задача самообучения. На мембране как-то пробегала статейка про робота, который сам учился передвигаться... Вот хотелось копнуть в этом направлении.

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

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

Duhas писал(а):i2c решит проблему управления устройством висящим на SPI на накотором устройстве подключенным к ПК произвольным транспортом?

Погоди, а ты про что писал? Тут уже всё смешалось - и предложения Vooon'a и blindman'a, а теперь еще и Digit подключился, я думал ты про протокол Digit'a говоришь, который тут последний обсуждался?

Если более широко - да, одна из основных задач нового протокола - управлять через шлюз устройствами подключенными по I2C, SPI к головному контроллеру и периферией головного контроллера. С периферией более менее ясно - она должна управляться так, как будто бы она была подключена к дочернему контроллеру соединенному с головным по i2c протоколу. Как завернуть SPI - получается только вопрос и какими командами работать с дочерними i2c устройствами, так?

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

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

Хм, кстати, SPI-интерфейс предлагаю объявить пораженным в правах и его юзать только для реальных SPI-устройств
А интерфейс I2C объявить приоритетным и считать локальные девайсы работающими по I2C
Таким образом мы хотя-бы сведём к 2 стандартные протоколы.

А еще можно попробовать SPI и I2C обрабатывать одним набором команд, но тут я уже пасую перед тем как SPI устроен, вроде в нём параллельно в обе стороны данные передаются, я прав?

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