roboforum.ru

я еще не придумал куда прилепить. но в базовом виде секвенсер это функция независящая от времени и прошлого поожения. в нормальном варианте это уже добавляеться 4 измерение. т.е. время.
а вот зависимость положения от времени есть большое множество: ходьба. поворот. бег, ну и прочие шалости. эти шалости должен иметь возможность уже сам пользователь добавлять. ведь этой функцией может руководить допустим камера.
для его реалихации нам надо знать положение хекса во время t-1. а там дальше как вариант выпонять функцию каждый заданный промежуток времени. допустим каждые 0.1 сек.

какой формат входящих данных, это вам решать.

я надеюсь вы пойметя чо я тут написал. =)

2demoontz: Ну вообще зависеть от прошлого положения система должна на каком-то уровне, иначе всё сломается.
А пока можно написать функции инверсной кинематики положения серв по целевому положению конца конечности шестинога.

А дальше просто описывать траектории концов конечностей и через вышеуказанную функцию генерить положения серв.

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

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

траектории концов конечностей и через вышеуказанную функцию это и есть зависимость от времени и прошлого положения. я могу математически это все реализовать. буду заморачивацца если нет пока альтернативы. а я так понимаю она(ссц32) не особо альтернатива, так как не внутри контролера.

щас всеравно пока думаю над математикой
например надо сделать так
http://micromagicsystems.com/#/balance- ... 4517267257

Не знаю, в правильную ли тему написал я. Если что-поправите.
Добрался я до ORFA.
1. Скомпилировал как в wiki/ORFA
"Сборка ORFA под AVR Studio + WinAVR
Для этого вам потребуется:
1. Скачать .zip-архив с нужной версией (последняя версия: 0.7.4)
2. Создать в этом же каталоге проект ORFA без создания каталога и нового файла (имя важно, иначе AVR Studio не увидит скомилированный файл)
4. Добавить в только что созданный проект файл «main.c»
5. Прописать в свойствах проекта внешний Makefile из скачанного проекта
6. Создать в папке проекта файл local_config.mk и в нём прописать платформу (PLATFORM = OR_AVR_M128_S или OR_AVR_M32_D) и скорость UART (B115200 или B9600), например:
PLATFORM = OR_AVR_M128_S
BAUD = B115200
7. Скомпилировать прошивку"
Почему-то там п.3 не было.
2. Залил прошивку в контроллер OR-AVR-M32-D.
3. Перевел переключатели на USB программаторе OR-PROG-USB в противоположное положение: три переключателя "Prog" в положение Off, два переключателя "Bus" в положение On.
4. А теперь дальше, какой конкретно программой-терминалом можно ORFA-команды посылать из ПК в контроллер OR-AVR-M32-D и получать от него ответы? А то я уже собрался на Делфи его писать на основе обычного компонента COM порта.

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

1.Я скачал Advanced Serial Port Monitor 3.5.3 build 41.
2 Настроил в ней доступ к COM 3, скорость 115200.
3. Инициализировал устройство.
Как это выглядело в логе программы:
V [len=1]
V1.0 [len=4]
<LF>
L20 [len=3]
L20 [len=3]
<LF>
C0064 [len=5]
C0066 [len=5]
<LF>
X [len=1]
X [len=1]
<LF>
S 20 00 00 S 21 01 P [len=20]
SWAASR06P [len=9]
<LF>
А так это интерпретирую согласно wiki/ORFA где "<" помечены мои сообщения, ">" - ответ по COM порту модуля OR-AVR-M32-D.
3.1. Получил версию протокола
< V [len=1]
> V1.0 [len=4]

3.2. Set local address
< L20 [len=3]
> L20 [len=3]
3.3. Set bus speed (freq)
< C0064 [len=5]
> C0066 [len=5]
3.4. Clear I2C bus
< X [len=1]
> X [len=1]
3.5. I2C request
< S 20 00 00 S 21 01 P [len=20]
> SWAASR06P [len=9]
А теперь рассказывайте все, разработчики, где что и как тут с этой ORFA, мне чайнику и всем кому это интересно.
Я хочу подключить контроллер к моей программе на C++. Чем и как можно тут управлять и что и как получать по чьей инициативе?

[[ORFA - Выданные идентификаторы UID]]
Там список драйверов, и ссылки на описание каждого из них.
S 20 00 00 S 21 01 P - это был запрос к драйверу-интроспектору, который сообщил, что имеются 6 драйверов. Для каждого можно запросить дополнительную информацию, см. [[ORFA Introspection driver]]

Давайте по порядку.
wiki/ORFA_Introspection_driver
Рассмотрим ваш пример:
"Определяем сколько драйверов в устройстве.

Запрос: L40
Ответ: L40
Первый запрос - L40 - установить адрес локального устройства в 0x40. Ответ - L40 - адрес установлен. (Можно не делать, если вы уже установили адрес локального устройства ранее)."
1. Что такое "адрес локального устройства" и почему его можно установить в значение 0x40.
2. Кстати, это в Hex?
3. Какой допустимый диапазон адресов устройств?
4. Какому устройству посылаются все команды ORFA? Только мастеру и он пересылает после парсинга командной строки нужные Slave-устройствам если такие есть или в них тоже как-то можно напрямую посылать команды?

"Запрос: S40 00 00 S41 01 P
Ответ: SWAASR06P
Второй запрос - S40 00 00 - отправим в устройство 0x40 номер регистра 00 и тип запроса 00 - получить количество драйверов, S41 01 - получить ответ 1 байт, P - конец запроса. Ответ: SW - начали запись в устройство, AA - подтверждения записи 2 байт в устройство, SR - начали получать ответ от устройства, 06 - получили 1 байт ответа (количество драйверов), P - конец ответа."
5. Какую роль выполняет в устройстве 0x40 регистр с номером 00?
6. Где полный список типов запросов?
7. S41 - а этот адрес устройства откуда вылез? Или за устройством 40 сразу закрепляется какая-то зона адресов - 40, 41.... ? Каков тогда стандартный список такой зоны?
8. P - конец ответа. Тогда какова максимальная длина ответа в байтах или в количестве отдельных ответов?
9. Компьютер должен обязательно дождаться получения подтверждения конца ответа прежде чем давать новый запрос?

1. Согласно идеологии заложенной в ORFA - всё есть i2c-устройства, даже контроллер с которым мы напрямую общаемся через i2c.
2. да, это хекс;
3. 0-127, как в стандарте и2с;
4. Изначально только мастеру, другим оно пересылается уже по и2с шине, т.е. после парсинга строки полученной из УАРТА;
5. регистр с номером 00 не связан с адресом устройства - это регистр интроспектора ORFA, подробней указано на странице wiki/ORFA в разделе "Возможности встроенного/подчиненного I²C устройства (список драйверов)"
6. Он зависит от подключенных драйверов, в указанном в предыдущем пункте разделе есть таблица с текущими драйверами;
7. По стандарту и2с адрес 40 и адрес 41 это одно и то же устройство, последний бит - указатель направления запроса (запись=0\чтение=1);
8. Буферы сейчас выставлены вроде в порядка 100 байт внутри ОРФА;
9. Вроде можно не дожидаться, но не экспериментировал, как будут себя вести разные библиотеки СОМ-портов если не забирать информацию из входного буфера.

1. Что такое "адрес локального устройства" и почему его можно установить в значение 0x40.

Это адрес, на который откликается шлюз. То есть запросы по этому адресу он обрабатывает сам. Запросы по другим адресам просто транслируются на шину I2C.

2. Кстати, это в Hex?

Очевидно, да

3. Какой допустимый диапазон адресов устройств?

0x00 - 0xFF, младший бит игнорируется.

4. Какому устройству посылаются все команды ORFA? Только мастеру и он пересылает после парсинга командной строки нужные Slave-устройствам если такие есть или в них тоже как-то можно напрямую посылать команды?

Не понял вопроса.

5. Какую роль выполняет в устройстве 0x40 регистр с номером 00?

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

6. Где полный список типов запросов?

Что такое "тип запроса"?

7. S41 - а этот адрес устройства откуда вылез? Или за устройством 40 сразу закрепляется какая-то зона адресов - 40, 41.... ? Каков тогда стандартный список такой зоны?

2 адреса. Но на самом деле один, младший бит - это признак чтения/записи.

8. P - конец запроса. Тогда какова максимальная длина сообщения в байтах или в количестве отдельных запросов?

Длина сообщения ограничена буфером в 128 байт. В самом сообщении длина не указывается.

9. Компьютер должен обязательно дождаться получения подтверждения конца ответа прежде чем давать новый запрос?

Главное чтобы буфер не переполнился. Лучше дождаться.

Виктор, вы знакомы со спецификацией шины I2C? Протокол шлюз-контроллера был построен наподобие I2C, если вы в его почитаете, возможно ответ на вопросы 7,8 станет понятнее

Тогда еще вопросы.
1. Для ПК все контроллеры, выглядящие как набор устройств и где кол. устройств м.б. гораздо больше кол. контроллеров, - это один общий сервер с различными частями - устройствами, а сам ПК - клиент?
2. Как тогда работать с событиями, происходящими в МК? Например, сработал бампер. Какова последовательность взаимодействия МК и ПК в этом случае?

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

Упсс. Это получается, что если в МК части 100 всяких событийных устройств, то их все нужно сканировать? А для облегчения задачи нельзя хотя бы в общем драйвере взводить флаг что в каком-то устройстве произошло событие? Хотя для хранения очереди векторов необработанных событий тоже придется городьбу городить

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

Удобно было бы, когда каждое устройство, способное вырабатывать события, могло работать в 2 режимах.
1. Асинхронное событие. Выдал куда-то, например, главному устройству обработки событий всю событийную инфу и быстренько продолжил свою работу по обнаружению след. событий. При этом есть вероятность необработки данного события по разным причинам (переполнение очереди, медленность обработки и потеря актуальности вследствие этого и т.д.)
2. Синхронное событие. Устройство останавливает свою работу до тех пор, пока не дождется ответа (возможно даже от самого ПК), что событие обработано и только тогда продолжает работать.

Добавлено спустя 4 минуты 18 секунд:
Я м.б. еще не въехал в ORFA, но мне показалось, что она напоминает собой DOS для ПК. Те же регистровые передачи параметров в API. Они хороши тем, что довольно компактны и быстры. Но и гибкость такого подхода сомнительна. Однозадачность. Пока один запрос не будет подтвержден ответом, нельзя делать следующий. А если следующий запрос к др. устройству? А первое устройство повисло или разрушилось? Ждать ответа до "посинения"?
Мне кажется, что такая конфигурация ORFA совсем не реалтаймовская и не PnP-шная.