roboforum.ru

Чтобы не было недоразумений : заказ этих плат пока был отложен. В другой ветке про это писал, забыл здесь отметить.

bolt писал(а):Распишите, пока платы делают, протокол обмена с центральным процессором, pls.

Если есть мысли по этому поводу - предлагай.

Полагаю I2C, 8bit (3 бита ID датчика + 5 бит команды/данных)или 8+8, что расширит возможности.
Есть гнусная мысль убрать ограничитель тока и за счет длительности модулирующих импульсов регулировать мощность. С какого-то момента TSOP примет пачку правильно. Своего рода измеритель дальности, правда с поправкой на поверхность.

bolt писал(а):Полагаю I2C, 8bit (3 бита ID датчика + 5 бит команды/данных)или 8+8, что расширит возможности.

То есть ты хочешь упаковать фрейм в 1 байт?

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

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

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

Я тож это когда-то давно проверял. Реального расстояния мы так не узнаем, но оценить изменение можем.

Да, совсем забыл Если делать заменитель родного сенсора, то формат данных должен соответствовать принятому в проекте Open Robotics. Иначе центральный процессор нас не поймет.

А при чем тут "процессор не поймет"? Разве у нас строгий ОДИН протокол? Помойму ты не представляешь вообще как пишут программы для МК.

Добавлено спустя 17 секунд:
Без обид конечно, возможно я просто не так понял

Я не знаю как организован обмен данными с периферией в системе OpenRob.
С родными модулями система будет работать, как я понимаю, автоматически. Это изготовителем предусмотрено. Что и в каком формате должен передать сенсор, чтобы ЦП должным образом отреагировал мне не ведомо.
Этим и RIO месяц назад интересовался, но ответа так и не получил

В плане автоматически? Так говорите, как будто в МК главного модуля прошита какаято заводская прошивка. На то он и главный модуль, чтобы под него писать софт, уже пользователь определяет как ему общаца с остальными модулями

bolt

Если бы внимательно читали...
Нету никакого обмена с периферией.
У DeaD-а простейшая прошивка для модуля с возможностями, которой вы можете в Вики ознакомится.

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

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

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

RoboTok писал(а):Если бы внимательно читали...
Нету никакого обмена с периферией.
У DeaD-а простейшая прошивка для модуля с возможностями, которой вы можете в Вики ознакомится.

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

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

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

2bolt: Я по любому лучше вас знаю, что у нас есть. Описывать i2c протокол в 10-й раз смысла не вижу. Кроме i2c никакого протокола с датчиками не зафиксировано. Тчк.

никакого протокола с датчиками не зафиксировано.

Я именно об этом и говорю. Система не знает как сделать запрос конкретному датчику, а датчик на такой запрос неизвестно как должен ответить.
Интересует не описание стандартного протокола одной из шин, а описание семейства команд работы с периферией.
Какие ID закреплены за ИК сенсорами?
Разрядность и формат отклика?
и т.д.

Зачем какое-то семейство команд, если есть i2c? Есть классический подход - чтение и запись регистров\ячеек памяти, а дальше уже в зависимости от устройства. Только не надо тут продвигать какое-то хитровыдуманное семейство команд универсальное, уже всё давно придумано. Почитайте несколько даташитов от разных i2c устройств и всё поймёте... ну я надеюсь

Почитайте несколько даташитов от разных i2c устройств и всё поймёте.

Спасибо за подсказку, но я с этими устройствами не первый год работаю. Для чтения стандартной I2C EEPROM мой МК должен послать ряд вполне определенных команд. Ес-но что они известны и мне достаточно лишь включить их в прошивку. Если мой МК работает с чипом I2C тюнера, то команды будут уже другие. Эти команды я могу найти в dsh используемого чипа.
В случае с самодельным ИК сенсором такой информации нет, а без неё прошивки не разработать.

зы. Надеюсь теперь проблема изложена максимально доступно для понимания.