roboforum.ru

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

Итак что же я хочу сделать:

- применить вытесняющую ОСРВ
- использовать shell'образную оболочку
- демоны оборудования, протоколов...
- общение через глобальные переменные
- сервера синхронизации (отсылки переменных)

Примерно так я хочу видеть работу с модулем:

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

Welcome on Open Robotics OR-STM32-DS

> help
gpiod    GPIO daemon
adcd     ADC daemon
motord   motor daemon
servod   servo daemon
print    print variables
set      set variable
ps       list running threads
bsync    binary variable syncronization service (via stream device)
isync    I2C variable syncronization service (???)
usync    USB variable syncronization service (via USB, not USB CDC)
orfa     old ORFA command interpreter
reset    reset module
> print
> gpiod
> print
port0_i=0xffff
port0_o=0xffff
port0_m=0x00000000000000
port1_i=0xffff
...
> adcd
> print
adc0=0xadc0
adc0_m=0x0000
...
adc16=0xadcf
adc16_m=0x0000
...
> motord
> print
...
motor0_p=0
motor1_p=-100
motor2_p=0
motor3_p=100
...
> servod
> print
...
servo0_p=1500
servo0_d=2000
servo0_t=200
servo1_p=2000
...
> set servo1_d 1500
> bsync
<-- binary transfer -->
^C
> print servo0_p
2000
> help servod
servod [-r a..b,c,d..e] [-m 0..16:s,3:a.2]
RC servo control daemon

-r    enabled channel ranges, default 0..16 (0..32)
-m    mode of servo: [s]tandard, potenciometer on [a]dc.<ch>


Добавлено спустя 15 минут 24 секунды:
Сервер синхронизации
Это программа которая позволяет читать и писать переменные контроллера через какой-либо внешний интерфейс.
Во время работы sync нельзя создавать и удалять переменные.

Например для bsync я думаю использовать такой алгоритм:
- при запуске отсылается таблица индекс-имя
- отсылается полный пакет изменений
- по изменению переменной она отсылается наверх (либо на следующем цикле)

Мастер может только отсылать пакет изменений (хотя может быть есть смысл запрашивать таблицу и данные).

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

И в целом - какие поставленные задачи сейчас ORFA не решает или решает плохо, чтобы её на что-то менять?
Особенно в части протокола. ИМХО, раздувать который - значит перестать пролезать с кучей команд 6-нога в стандартные 115200.

PS: Потеря совместимости с SSC-32 по командам - серьезный проигрышь.

Вот как раз с протоколами здесь проблем нет.
Хочешь протокол SSC-32 - запускаешь сервер синхронизации с протоколом SSC-32 (скорее всего это будет orfa).

Концепция переменных тем и хороша, что получается единый слой связывающий ПО модуля.
Например драйвер GPIO делает poll (POLLIN) на своих переменных, по событию выставляет пины.

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

Вообще я хочу получить более macine-friendly протокол связи,
и чтобы было проще писать "драйвера" для целевой задачи.
Я считаю, что такой подход позволит проще написать OPC-сервер или ноду для ROS'а.

В основном меня интересует как связать мозг на Cortex-A9 и модуль "УСО" OR.
На мозге я хочу запустить ROS.

Это будет не "machine-friendly" и даже не "user-friendly".
Это будет якобы программер-френдли, да и то... еще как сказать.

Можно подробнее, чем такой подход плох?

Володя предлагает очень правильную архитектурную концепцию.
однако ее нужно описать в плане того где и какой демон исполняется и может исполняться (в рамках нескольких контроллеров, а может и управляющего сервера x86)

Добавлено спустя 3 минуты 12 секунд:
а зачем команды демонов ?
ты ими управлять собирашься ??
тогда одну команду типа
daemon gpio ...

Добавлено спустя 1 минуту 43 секунды:
или cisco подобный cli c входом в подуровень работы с чем либо например gpio
main / gpio > help

Причина для команд простая.
Т.к. для организации синхронизации лучше чтобы symtable не менялась, то все переменные создаются до старта sync сервера.
А конфигурацию многих демонов удобно передать в виде параметров командной строки (см. пример help servod).
Вообще есть идея иметь еще и минимальный скриптинг, по типу u-boot'овского.
Например bootcmd в котором прописано дефолтное поведение модуля.

bootcmd="gpiod && adcd && motord && servod && bsync"

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

Добавлено спустя 1 минуту 4 секунды:
появится например какой либо gpsd - не хотелось бы все перекомпилировать

Добавлено спустя 3 минуты 36 секунд:
в приложении то что можно использовать для автоматизации построения CLI парсера на C#

Перекомпилировать придется в любом случае.
Все таки cortex-m3 сравнительно слабая машинка, и делать на ней динамическую линковку слишком круто.
Да и незачем, фс-а все равно нет, флешка.

А демона имхо сделать будет не сложней. Тем более я хочу применить технику регистрации команд из u-boot'а.

Вообще мне понравились многие идеи u-boot'а. Ну еще тут часть идей из нашего TeNIX.

Vooon писал(а):Можно подробнее, чем такой подход плох?

Нельзя говорить о том, плох подход или хорош, не зная целей.

Плох он, например тем, что накладывает гораздо более высокие требования на железо.
Хорош, вероятно, удобством программирования - программист, в идеале, пишет отдельного демона, как независимую программу. Однако добиться реального отсутствия неявных связей с другими компонентами (временнЫх, например) будет очень непросто.
Юзер-френдли оставим пока за бортом - предположим, что со стороны пользователя все выглядит одинаково. (Ну... допустим).

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

Это не такой простой вопрос и, очевидно, зависит от целей и их приоритетов.

Michael_K писал(а):Это будет не "machine-friendly" и даже не "user-friendly".
Это будет якобы программер-френдли, да и то... еще как сказать.

И пользоваться кроме Vooon'a особо никто не будет. орфа2 - надуманная сложность имхо.
Что opc, что ноду ros писать не так долго, и это совсем не проблема для OR контроллера сделать.

Vooon писал(а):Использование сервера синхронизации позволит также связывать контроллеры между собой, то самое
когда на мастере ORFA даем команду, а она пересылается на слейв.

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

Vooon писал(а):Вообще я хочу получить более macine-friendly протокол связи, и чтобы было проще писать "драйвера" для целевой задачи. Я считаю, что такой подход позволит проще написать OPC-сервер или ноду для ROS'а.

Всё равно ничего не понял, может сформулировать саму задачу? Ну ту, которая не решается на ORFA или решается не очень хорошо, но зато отлично решается на предлагаемой ORFA-2. Иначе мы занимаемся традиционным уже на форуме выбором решения для неопределенной задачи.

Добавлено спустя 1 минуту 54 секунды:
Оффтоп, но всё равно - для движения проекта вперед полно других задач, а мы займёмся перерешиванием уже решенной

Что касается требования к железу, то да, собираюсь использовать STM32F103 256 KiB Flash, 20 KiB RAM.
В плане цены, то тут оказывается ситуация не в пользу OR-AVR-M128, STM-F103.

Вот в терре: Atmega128 - 200..300 р., а STM32F103 200-400 р.

А для серв я думаю с этим мк не придется ставить внешние таймер-счетчики.

Задачу бы сформулировать

По поводу ненужности внешней логики - не факт, 5В этот STM32 не выдаст.

Ну вот не нравится мне I2C. Как managment-control протокол, да он сойдет.
Но вешать на него все не хочу. Тем более что я хочу другие протоколы передачи использовать.
Например тот-же USB (а в перспективе TCP/IP via Ethernet).

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

Добавлено спустя 1 минуту 16 секунд:
5 вольт запросто: на 5V tolerant порты ставим режим OD + внешняя подтяжка к +5.