roboforum.ru

=DeaD= писал(а):Поступило предложение от Vooon'а поменять протокол прошивки шлюз-контроллера на протокол из этого проекта: http://www.tty1.net/userial/manual/userial.html, серьезный аргумент только один, но весомый сейчас прошивка поддерживает не все возможные запросы к i2c-устройствам. Моё предложение заключается в смене протокола, но сохранении унифицированного обращения к локальным устройствам - так же как к i2c-устройствам, но с адресом FF. Кто что думает?

Поковырял сегодня доки userial, сравнил с форматом команд шлюз-контроллера. Думаю есть 2 варианта как обращаться к локальным устройствам (из таких у нас пока есть драйвер двигателей):

1. как к устройствам на I2C.
2. отдельной командой

В обоих случаях считаю что было бы полезно ввести понятие регистра, как это сделано в устройствах Devantech. Это ничего не меняет в принципе работы, просто позволяет проще описывать команды : вместо "послать ISWFF11ss" - "записать ss в регистр 0x11". Ну по крайней мере мне это кажется проще

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

----------------
Now playing: Nirvana - Nothing as it seems

2blindman: Отдельные команды 100% надо запретить, как раз фишка продвигаемого мною подхода в унифицированности - всегда работаем по 1 транспортному протоколу - i2c, к локальным устройствам обращаемся так же, как к i2c-устройствами на шине, это позволит существенно сэкономить на разработке софта и драйверов на стороне ПК, откуда надо будет всем этим удовольствием рулить, а также юзать прошивку для i2c-slave и шлюз-контроллера для управления устройствами почти без изменений.

А в сторону userial я посмотрел по предложению Voon'а только потому, что мой протокол не поддерживает мультистарт, который много где нужен, например в том же I2C-It для Devantech'a.

Я согласен, что унификация важна. Но если делать как ты предлагаешь, мы все равно фактически получаем отдельную команду - потому что нам нужен способ выбора конкретного локального устройства - и это не получится отобразить напрямую на I2C. Не вижу разницы - использовать некий специальный адрес как индикатор того, что будет дополнительная суб-адресация, или использовать специально выделенную команду, показывающую, что обращаемся к локальному устройству. В любом случае на уровне управляющего устройства это будут либо 2 разных вызова API, либо один, но с флагом локального устройства в качестве параметра. Так что экономии на разработке софта никакой не будет. Это 2 абсолютно равноценных варианта.

blindman писал(а):мы все равно фактически получаем отдельную команду - потому что нам нужен способ выбора конкретного локального устройства - и это не получится отобразить напрямую на I2C.

В любом случае на уровне управляющего устройства это будут либо 2 разных вызова API, либо один, но с флагом локального устройства в качестве параметра. Так что экономии на разработке софта никакой не будет. Это 2 абсолютно равноценных варианта.

Почему это не получится? Просто будет 1 лишняя команда указывающая адрес который из нормального диапазона i2c адресов будет использоваться как родной локальным контроллером. А дальше как к устройству на шине и2с обращаемся и всё.

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

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

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

Давай представим что у нас лоакльные стройства идут по адресу 0xFF, а например порт А в локальном адресуется как 0x0A, и нам надо этот порт прочитать. Сравни что проще:

- адресовать 0xFF на запись, записать 0x0A, адресовать 0xFF на чтение, прочитать значение

или

- адресовать 0xFF0A на чтение, прочитать значение

blindman писал(а):Ну и нафига себе жизнь усложнять? Куча команд - сначала адресовать контроллер, потом записать в него команду, потом возможно переключаться в режим чтения.

Ничего не понял

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

Зачем субадресация для локальных устройств? Этот же контроллер может использоваться как подчиненный на шине i2c, значит по хорошему надо его весь на 1 адресе юзать, а то несколько таких контроллеров все адреса займут. А так - использовал 1 адрес - работаешь с локальным контроллером, использовал другой адрес - работаешь с подчиненным по шине и2с другим контроллером.

blindman писал(а):Давай представим что у нас лоакльные стройства идут по адресу 0xFF, а например порт А в локальном адресуется как 0x0A, и нам надо этот порт прочитать. Сравни что проще:

- адресовать 0xFF на запись, записать 0x0A, адресовать 0xFF на чтение, прочитать значение

или

- адресовать 0xFF0A на чтение, прочитать значение

Вот это вообще не понял, что есть "адресовать 0xFF0A" в стандарте и2с? Как переписывать потом код если этот контроллер придется сделать подчиненным, а основным поставить другой контроллер?

Добавлено спустя 8 минут 22 секунды:
У меня очень простая концепция - при замене локального контроллера на такой же, но подчиненный, в программе должен поменяться только адрес. Это даёт понятные и существенные преимущества при разработке драйверов устройств и вообще при развитии робота.

Ты своей концепцией икусственно делаешь I2C - и вносишь его ограничения. Я же предлагаю не завязываться на него, и сразу сделать удобный протокол, с расширенной адресацией.

=DeaD= писал(а):Вот это вообще не понял, что есть "адресовать 0xFF0A" в стандарте и2с? Как переписывать потом код если этот контроллер придется сделать подчиненным, а основным поставить другой контроллер?

Да не зацикливайся ты на I2C. Рассматривай его просто как еще один транспорт для протокола более высокого уровня - более удобного и универсального.

Мои соображения:

1. Можно доделать там 10-и битную адресацию (в соответствии со стандартом)
2. Удобно использовать именно модель регистров
3. Подход «все по I2C» значительно снижает сложность драйвера, ему нужно будет создать только /dev/i2c-n
   Драйвер SPI и тд уже может быть отдельным от основного драйвера и работать с /dev/i2c-n (на сколько я понимаю доступ к i2c девайсу от нескольких приложений осуществить легче, чем /dev/ttySn (/dev/rfcommn)

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

Я начал потихоньку переделывать userial под OR, но без железа пока сложно.
Посмотреть можно здесь: http://hg.vehq.ru/or-i2c-gate-firmware/

ПС: Мое репо сейчас работает немного нестабильно, я перевел его на WSGI и вход не через файл с паролями а через малюсенький WSGI скрипт, который проверяет логин/пароль и права на запись(изменение) реп по базе юзеров Django.
А сейчас пишу простенького менеджера репа, от него нужны две фичи: изменять hgrc в соответствии с моделью Repository (Acl, Contact связаны с пользователями джанги) и создавать новые репо.

Vooo, =DeaD= - а можете без всяких там концепций показать примерно как будет выглядеть код на стороне ПК для такой ситуации:

Есть МК с программой шлюза, через UART подключен ПК. К МК по I2C подключено некое устройство с адресом 0xC0. Имеется еще одно устройство на SPI. Есть 2 мотора, и 2 порта ввода-вывода.

1. Записать в I2C-устройство 10 байт, прочитать 20 байт
2. Записать в SPI-устройство 10 байт, вернуть полученные от него данные
3. Установить скорость вращения мотора
4. Настроить режимы ввода/вывода портов
5. Записать/прочитать данные из портов.

А теперь то же самое, но вместо ПК подключаем второй МК, по I2C, и с него рулим.

Только не надо писать SetMotor(LEFT, -20) . Я хочу посмотреть как вы видите взаимодействие с драйвером. А то мы все понаписали, каждый по-своему, и каждый только те моменты, которые ему кажутся существенными. Короче,

Linus Torvalds писал(а):Talk is cheap. Show me the code.

Думаю такого плана (в командах шлюзу):

1. IS 20 W 01 02 03 04 05 06 07 08 09 0a S 20 R 0b P (не помню точно, нужно менять адрес или нет)
2. IS 60 W ff 01 02 03 04 05 06 07 08 09 0a S 60 R 0a P (60 — локальный адрес, ff — код послать по spi)
3. Записать в регистр скорости мотора число IS60Wa0ffffP (a0 — адрес регистра)
4. Тоже запись в регистр
5. Прочитать регистр IS60W10S60R01P

Меняем прошивку чтоб процессор команд i2c получал их не от процессора команд usart а от twi.
Запросы от другого мк будут выглядеть также, только изменится адрес подчиненного устройства.

А вообще я не думаю вырезать существующие команды userial,
на 32 КиБ кода место обычно находится и на прошивки без оптимизации

Дык я ж то же самое и предлагаю, только с небольшой вариацией:

1. IS 00 20 W 01 02 03 04 05 06 07 08 09 0a S 00 20 R 0b P
2. IS 60 ff W 01 02 03 04 05 06 07 08 09 0a S 60 FF R 0a P
3. IS 60 a0 W ff ff P
4. IS 60 bc W f5 aa P
5. IS 60 10 R 01 P

То есть более четко отделяем адресацию от данных

----------------
Now playing: AC/DC - Show Bisiness (Radio-OMa)

Добавлено спустя 24 минуты 41 секунду:
Причем IS тут вообще лишнее - у нас фактически 2 команды - запись и чтение.

1. W 00 20 01 02 03 04 05 06 07 08 09 0a R 00 20 0b P
2. W 60 ff 01 02 03 04 05 06 07 08 09 0a R 60 FF 0a P
3. W 60 a0 ff ff P
4. W 60 bc f5 aa P
5. R 60 10 01 P

----------------
Now playing: Delia - Спогад (Radio-OMa)

2blindman: Представь, что ты месяц разрабатывал прошивку для slave-устройства по шине i2c со всей этой периферией, еще столько же писал код для ПК использующий эту прошивку, а тебе за час перед ответственным представлением устройства сказали, что надо еще чтобы такое же можно было делать на локальном устройстве (т.е. чтобы это устройство можно было сделать шлюз-контроллером, при том что код шлюз-контроллера имеется). Какой самый быстрый и надежный способ сделать это, кроме как обеспечить на месте поддержку обработки обычных и2с запросов к спец-адресу (для меня не важно из нормального диапазона или 0xFF)?

2Vooon: А ты про SPI предлагаешь их обрабатывать в формате i2c запросов тоже?

=DeaD=, я ничего не понял, что ты хотел сказать

Ну как же так же

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

Я вижу только один способ этого достичь - писать всё как будто под дочернее i2c-устройство и потом на локальном устройстве просто перехватывать часть запросов к одному из адресов и обрабатывать их локально, тогда весь вопрос будет только в том, какой адрес мы так перехватываем. Я в принципе согласен с Vooon'ом - можно сделать этот адрес валидным, чтобы не париться с отклонением от стандартов. И просто сделать спец-команду выбора этого адреса для локального контроллера - ведь какой-то из 127 адресов всё равно будет свободным.

blindman: то что ты предлагаешь очень похоже на 10-и битную адресацию I2C, только первый байт там имеет определенные значения.
И если реализовать 10-и битную адресацию, то мы вполне под каждый регистр можем занять адрес.
Кстати это избавляет нас от проблемы собственного адреса устройства и его хранения в eeprom
т.к. устройств понимающих 10 бит мало. Но сам пакет менять не стоит, ты забыл IC (имхо нужная комманда)
V тоже полезна.

Сейчас заглянул в суммари i2c
для 10и бит: 11110xxo xxxxxxxx x — adress bit, o — operation bit

Добавлено спустя 4 минуты 45 секунд:
Те, если шлюз принимает адрес Fx то это 10и битная посылка, нужно достать еще один байт из пакета
проверить не наши ли адреса, и отправлять.
Только не знаю поддерживает ли twi 10-режим, но исходники OSIF говорят что вроде да.

IS F1 10 W ffff P но IS 20 W e0 P

Добавлено спустя 3 минуты 31 секунду:
2 Dead: да, я предлагаю со всем работать как с i2c.
для SPI вполне нормально сделать запись, потом чтение
тем более что количество байт нам всегда известно