roboforum.ru

**=DeaD=** » 18 июн 2011, 12:55

Пока вижу только одну поставленную задачу - снизить стоимость контроллера.

Все остальные как-то сферичны и в вакууме

в смысле практических целей и их массовости.

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

**Vooon** » 18 июн 2011, 13:06

Так нашу орфу с Авра особо не перетянешь. И писать драйвера HAL для всего на новой платформе не очень хочется.
Есть ОСРВ в которой многое из HAL'а реализовано. В том числе USB CDC (что многого стоит).
А раз и так получается крупная переделка, точнее фактически с нуля, то и хочу реализовать новые идеи, которые сложно вписать в старую орфу.
И да, я хочу приблизить среду орфы к среде наших ПЛК.

**=DeaD=** » 18 июн 2011, 15:04

Vooon писал(а):И да, я хочу приблизить среду орфы к среде наших ПЛК.

Еще бы знать что у вас там за среда, и что она даёт

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

Vooon писал(а):Так нашу орфу с Авра особо не перетянешь.

Вроде HAL выделяли как раз, чтобы можно было перетягивать всё, что не завязано на идеологии портов AVR.

Vooon писал(а):И писать драйвера HAL для всего на новой платформе не очень хочется. Есть ОСРВ в которой многое из HAL'а реализовано. В том числе USB CDC (что многого стоит).

Так вроде берешь функции из ОСРВ и объявляешь их HAL'ом - в чем может быть проблема? Главное сохранить идеологию парсеров UART-команд и проброски I2C в исходном виде, тогда это будет нормальный порт ORFA.

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

Vooon писал(а):Да, первоначальная идея результат NIH²

Это еще кто?

Добавлено спустя 26 минут 6 секунд:
Попробовал абстрагироваться и понять, как предлагается всё организовать. Не понял зачем вся эта затея с переменными? Мы полноценный shell с файловой системой делаем?

Я понимаю сделать просто пространство переменных и команды к нему, типа:

< srvExec=0,srvCmd0=1500,srvCmd1=1800,srvExec=1
> ok
< ?srvCmd1
> srvCmd1=1800
< ?srvPos*
> srvPos0=1500
> srvPos1=1800
> srvPos2=1500
.....
> srvPos31=1500

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

Но зачем в shell что-то знать про демоны?

**Michael_K** » 18 июн 2011, 15:28

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

Он хочет сделать "комп", в котором можно запускать "пользовательские" (или "сторонние") задачи. Но нафига это нужно - он не говорит. Тем более нафига это нужно конечному юзеру.

**=DeaD=** » 18 июн 2011, 15:33

Я тоже вижу что это похоже на полноценную ОС, но писать её самим с нуля - зачем???

**Vooon** » 18 июн 2011, 16:37

HAL из той ОСРВ не вытянешь, оно завязано на все примитивы синхронизации и IPC, каналы предоставляемые ядром.
И какой смысл делать свою ОС с нуля? Я думаю только дописать драйвер серв (остальное практически все есть).

Шелл на мой взгляд весьма ограниченный получится. А файловую систему использовать я не думаю. Нет необходимости.

И да, я хочу чтобы было легко добавить свой демон, которому будет достаточно оперировать ГП.

**=DeaD=** » 18 июн 2011, 17:02

Не понял тогда вообще - если всё уже есть, то зачем дописывание драйвера серв к этому уже имеющемуся называть ORFA2?

Или я опять всё пропустил? Что уже есть, а что предполагается написать в рамках этого самого ORFA2?

**Vooon** » 18 июн 2011, 22:51

Есть ядро, примитивы синхронизации, каналы, hal (adc, gpio, serial, usb cdc, gpt), есть набросок консоли.
Не хватает hal драйвера для серв, i2c. Последний мне мало нужен, т.к. центральный модуль сам умеет i2c.
Ядро с вытесняющей многозадачностью (нити).

Нужно дописать консоль, работу с ГП, сами демоны и сервера, части hal.

**Duhas** » 08 авг 2011, 12:03

я вот одного не пойму, в серьезных (по выч мощности требуемой) и т.д. задачах ты хочешь все молотить на модуле с выводами под сервы и прочую периферию ?

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

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

такое вот ИМХО

**Vooon** » 14 сен 2011, 10:46

Я не собираюсь молотить все. ORFA это прошивка для модуля (можно сказать УСО).
Модуль содержит интерфейс к исполнительным устройствам и интерфейс для сбора данных.
Может иметь мелкую целевую задачу. Смысл в ней простой - чем гнать весь поток наверх, лучше постараться обработать его на месте (тот же антидребезг).

Теперь обновленная концепция:

Vooon писал(а):Идея ORFA2.

1. Глобальные переменные
ГП служат для связи всех процессов в системе. Через них идет общение.
ГП представляет собой базу данных типа ключ - значение(я).
Процесс может проверить была ли произведена запись, ожидать ее.

2. Демоны
На каждую проблему выделяется свой процесс — демон.
Демон создает свой набор ГП через который идет обмен с системой и использует HAL для работы с железом.

Пример:

Демон АЦП:
- создает ГП adc/c и adc/i
- проверяет с, меняет настройки каналов
- обновляет i

Демон серв:
- создает ГП servo/raw/o, servo/c, servo/o ... /t
- проверяет c, ...
- проверяет raw/o, если менялось - ставит положение
- просчитывает шаги для o (за t)
- обновляет raw/o, изменяет выхода

3. Сервера синхронизации
Это процессы основная задача которых — обмен ГП.
Сервер сообщает ПК о всех ГП и их состояниях, позволяет читать и писать в них с ПК.
Т.е. дает доступ извне к базе ГП.

Для примера можно написать клиент в экселе.
Таблица, в которой отображено состояние, в которой можно его и изменять.

**=DeaD=** » 14 сен 2011, 10:50

А проброска I2C отменяется?

**Duhas** » 14 сен 2011, 10:52

Dead, а можно узнать что вы так за идваси уцепились ? )

Vooon, я буду только рад если будет хорошая платформа (набор модулей), если осилите довести до ума все это - дерзайте )

**=DeaD=** » 14 сен 2011, 10:56

Duhas писал(а):Dead, а можно узнать что вы так за идваси уцепились ? )

А глянь на интерфейсы сонаров, акселей, гиро и компасов

**Vooon** » 14 сен 2011, 11:18

Для I2C (мастера) — целевая задача.

От этого проброса одни проблемы, посмотри на "Управление роботом через OR-BT20-115.2"...

**=DeaD=** » 14 сен 2011, 11:37

В указанной теме проблема не от проброса, а от унификации с I2C интерфейса к ГП. Чего я вроде не прошу уже давно.

roboforum.ru

Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Re: Концепция ORFA2

Кто сейчас на конференции