roboforum.ru

В общем в связи с трудностью пояснения, чего же я такого предлагаю по интроспекции, попробую это сформулировать отдельным топиком

Какие основные требования, которым я хочу чтобы удовлетворяла архитектура:

1. Возможность писать программы, в которых можно будет средствами самой программы, или в худшем случае через INI-файл настраивать какое конкретно железо будет использоваться. При этом при настройке средствами программы она должна выдать информацию понятную для пользователя - т.е. скажем если на контроллере написано "Порт А", пины 0..7, тогда и выдаёт пользователю вопрос "куда у вас подключен передний ИК-дальномер" и список портов "А0,А1,А2,...,А7,F0,F1,...,F7".

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

3. Однотипные драйверы должны удовлетворять однотипным интерфейсам, допускается отличие только в количестве и адресах управляемых объектов (например - GPIO портов может быть разное количество и они могут быть по разному сгруппированы).

Теперь по реализации:
1. Уровень интроспекции ядра модуля должен отвечать на запросы:
1.1. Сколько драйверов на модуле;
1.2. Какие GPIO-порты по буквам имеются на нашем модуле (2 числа, 16 бит, A..Q);
1.3. Какие биты этих GPIO-портов доступны для использования всеми;
1.4. Какие регистры занимает драйвер №X и какой UID этого драйвера;

2. В программе пользователя должен быть уровень изоляции от конкретного оборудования, т.е. мы должны писать код типа:

Код: Выделить всё

  orBumperSensor frontLeftBumper=orCreateBumper("front-ir-left");


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

Код: Выделить всё

<robot id="my_robot">
<comm>
  <uart name="pri_uart" comport="COM4">
    <i2c_device address="0x20" id="or1"/>
    <i2c_device address="0x24" id="or2"/>
  </uart>
  <uart name="sec_uart" comport="COM9">
    <i2c_device address="0x22" id="or3"/>
  </uart>
</comm>
<devices>
<wheelbase mcu="or3" width="20cm" length="25cm" height="15cm" wheel_radius="10cm" wheel_xoffset="0cm">
<irrangefinder id="front-ir-left" mcu="or2" pin="PORTA.1" min_range="10cm" max_range="80cm" pos="10,10,5" dir="0,1,0"/>
<irrangefinder id="front-ir-right" mcu="or2" pin="PORTA.2" min_range="10cm" max_range="80cm" pos="-10,10,5" dir="0,1,0"/>
<irrangefinder id="rear-ir-center" mcu="or1" pin="PORTA.1" min_range="4cm" max_range="30cm" pos="0,-10,5" dir="0,-1,0"/>
</base>
</devices>
</robot>


а что это за слово такое страшное - интроспекция?

В черне как-то так, жду первых комментов.

Добавлено спустя 18 секунд:

frig писал(а):а что это за слово такое страшное - интроспекция?

Это средство спросить у модуля, чего у него там внутрях

=DeaD= писал(а):

frig писал(а):а что это за слово такое страшное - интроспекция?

Это средство спросить у модуля, чего у него там внутрях

Что-то вроде СОМ с его IUnknown?

Digit писал(а):Что-то вроде СОМ с его IUnknown?

Не знаю таких буков

=DeaD= писал(а):Какие основные требования, которым я хочу чтобы удовлетворяла архитектура:

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

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

Программа имеется в виду на ПК? Или прошивка другого модуля? Или связка и того и другого?

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

=DeaD= писал(а):Не знаю таких буков

вот: Википедия
и вот тут тоже: Использование COM/DCOM в Delphi

Digit писал(а):Программа имеется в виду на ПК? Или прошивка другого модуля? Или связка и того и другого?

Программа на ПК или на КПК.

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

Digit писал(а):Что-то вроде СОМ с его IUnknown?

Да, очень похоже. Но у нас много объектов типа "драйвер" внутри контроллера.

Хехе, use DCOM luke! Убей портируемость!

То есть насколько я понял, программа для ПК с дружественным к пользователю интерфейсом связи с модулями

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

Все это затевается для облегчения написания проги на стороне ПК или в разработке прошивок модулей эта радость тоже будет использоваться и облегчать существование?

Добавлено спустя 23 секунды:
И если будет, то как вы это видите?

Добавлено спустя 34 секунды:

Vooon писал(а):Хехе, use DCOM luke! Убей портируемость!

ну да

В разработке прошивок это не сильно повлияет. Основные упрощения написания прошивок уже изложены в ORFA.

Вернемся к теме ORFA, я думаю уже очевидно, что мы идём к ситуации, когда на роботе в 95% случаев будет стоять ровно 1 контроллер с ORFA. Но! Нельзя при этом забивать на оставшиеся 5%, иначе все бонусы растеряем. Поэтому предложение такое:

1. Оставить основную структуру ORFA (попробовал зарисовать в разноцветных схемах в приложенных PDF-ках и исходных файлах Open Office);

2. Сделать понятный человеку парсер с UART'а, который пользовался бы интроспектором и мог бы принимать SSC-32 подобные команды типа S12 1500 - установить серву 12 в 1500мкс. Или A4 - прочитать с помощью АЦП с 4 порта. Оставить трансляцию в произвольный i2c-запрос с UART'а. Оставить на будущее возможность отправки в похожем виде команд на соседний контроллер ORFA подключенный к головному через i2c-шину. например \2S12 1500 - отправка команды S12 1500 на контроллер с i2c-адресом "2".

Дальнейшие мысли на эту тему:

1. Оставляем в парсере механизм унифицированных запросов i2c-формата, в т.ч. к локальному контроллеру, по сути это будет почти то же самое, что сейчас типа "L40" + "S40 0D 01 04B0 P", только может буквы поменяем;

2. Делаем для части команд человеческие ALIAS'ы, максимально совместимые с командами SSC-32.

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

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

Чтобы детально это прописать далее нужно набить фактуру команд, которые мы хотим обрабатывать. Начнем с команд контроллера SSC-32:

Добавлено спустя 22 минуты 55 секунд:
Итак команды серводрайвера от SSC-32:

Servo Move or Group Move
Общая команда управления сервами (установить в нужное положение с ограничением скорости или конкретным временем выполнения):

Код: Выделить всё

# <ch> P <pw> S <spd> ... # <ch>  P <pw> S <spd> T <time> <cr>

Оставляем команду как есть.

Software Position Offset
Калибровка нулевых положений:

Код: Выделить всё

# <ch> PO <offset value> ... # <ch> PO <offset value> <cr>

Оставляем команду как есть.

Query Movement Status.
Запрос окончания движения:

Код: Выделить всё

"Q <cr>

Оставляем команду как есть.

Query Pulse Width.
Запрос положения которое мы требуем в данный момент от конкретной сервы:

Код: Выделить всё

QP <arg> <cr>

Оставляем команду как есть.

Discrete Output.
Byte Output.
Специфические команды выставления 0 и 1 в сервопорты не поддерживаем.

Read Digital Inputs.
Чтение 4 цифровых входов:

Код: Выделить всё

A B C D AL BL CL DL <cr>

Тут вопрос - наверное есть смысл модифицировать команду, а то никаких букв не хватит, если мы 32 порта где-то сделаем да и сейчас 16 портов - не так уж и мало. Вопрос в том, на что заменяем и как заменяем.
Можно оставить первые 4 канала с такими же буквами, а оставшиеся 4 для первых восьми сделать EFGH, а потом добавить номер порта типа следующий будет уже не ABCDEFGH, а A1B1C1 и т.п. А это типа A0,B0,C0,D0,E0,F0,G0,H0, просто мы разрешили 0 пропускать.

Read Analog Inputs.
Чтение аналоговых входов:

Код: Выделить всё

VA VB VC VD <cr>

Тут всё то же самое как с цифровыми входами, благо у нас АЦП в AVR всегда на 1 порту, вроде, по крайней мере в наших моделях M128 и M32

Get Software Version.
Получить версию прошивки:

Код: Выделить всё

VER <cr>

Оставляем как есть.

Transfer to Boot.
Перейти в бутлоадер:

Код: Выделить всё

GOBOOT <cr>

Вот эту команду можно заменить, нечего нам пытаться залить прошивку от SSC-32

Ну и там есть еще два крупных блока команд:

1. секвенсор для шестинога на 12 сервах - оно вообще кому-то надо эту совместимость?
2. регистры SSC-32 - тут надо изучить, где используются эти команды и нужно ли обеспечивать совместимость.

Добавлено спустя 16 минут 17 секунд:
Что покрыто из существующих драйверов:
1. Драйвер серв;
2. Драйвер АЦП;
3. Драйвер цифровых портов (в части входов);

Что осталось за кадром из существующих драйверов:
4. Драйвер управления коллекторными двигателями;
5. Драйвер цифровых портов (в части выходов);
6. Драйвер i2c-порта;
7. Драйвер spi-порта;

Добавлено спустя 11 минут 1 секунду:
4. Драйвер двигателей логично сделать с буквы M

5. Драйвер цифровых портов в части выхода можно сделать как A=*, B=* и т.п. Т.е. установить высокий уровень это A=1, низкий это A=0.

6. Драйвер i2c порта с первой буквой S или настройка его с первой буквой L вроде не перекрывается с командами I2C, а вот скорость с буквой C перекрывается с опросом цифрового порта №3 (A,B,C,D). Наверное не критично и можно поменять команду, например, на I.

7. Про spi-драйвер не знаю.

Глубокое имхо и оффтопик:
По-моему, нужно начать снизу - сделать простой и удобный API
к ходовому железу (сервам, моторам, бамперам, энкодерам, линейкам датчиков цвета и т.д.)
И описанный, и с примерами использования.

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

Это само по себе позволит писать собственные парсеры, не заморачиваясь
с прерываниями, опросом и т.д. и превратить робота в автономного
минимальными усилиями.

Готовый парсер должен допускать безгеморройные расширения, то есть тоже должен иметь API.
Например, мне хочется поуправлять через модем, "не столь прозрачный" блютус
или ГПРС. Очевидно мне придется дополнить парсер функциями типа "найти", "подключиться",
"авторизоваться", "открыть канал", "разорвать связь" и т.д.