Обсуждение реализации шлюз-контроллера [ORFA]

=DeaD=

Модератор blindman:Добавил в название темы ORFA - Open Robotics Firmware Architecture

На самом деле назрела уже потребность обсудить более важный вопрос - драйверы устройств в шлюз-контроллере.

Уже сейчас есть 4 типа устройств:
1. Простейшие устройства - цифровой вход и цифровой выход;
2. Устройство работающее только на специфичных ногах МК - аналоговый вход (АЦП);
3. Хитрое программное устройство - управление сервоприводами на любых ногах;

Потихоньку намечается еще два устройства:
1. Настраиваемый ёмкостный вход (это как у нас датчик цвета поверхности сделан - там кондёр стоит который сначала через настройку ноги на выход разряжается мгновенно, а потом плавно заряжается от датчика и в зависимости от того через сколько мы запросим состояние цифрового входа можно проверить насколько датчик "открыл" зарядку кондёра);
2. Вход+выход для ИК-бампера.

Надо как-то свести всё к единому знаменателю, чтобы не было солянки из подходов к управлению такими устройствами.

Добавлено спустя 9 минут 39 секунд:
Есть мысль оставить для каждого порта тип устройства на нём. Но тогда с ИК-бампером надо будет видимо поделить его на 2 устройства - ИК-излучатель 36КГц и ИК-приёмник.

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

Duhas

вот это правильный подход для вашего проекта... только геморный )))
постараюсь следить за процессом и устраивать диверсионный анализ ))

blindman

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

=DeaD=

Duhas писал(а):

только геморный )))

Весь вопрос в терминологии

мы же не собираемся подгружаемые в риал-тайме драйвера делать

Duhas

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

Vooon

Я тут уже думал "плагинную" систему прикрутить
массив структур(указатель на ф-цию чтения; указатель на ф-цю записи)
где индекс соответствует режиму порта (0x20+pn), но имхо тяжело это выходит.
Уже сейчас прошивка занимает 7 КиБ в отладочном и 5.5 в релизном выриантах, а фактически ничего не умеет.

И наваял простенькую библиотеку для питона (хотел сначала на сях, но не асилил) http://hg.vehq.ru/pyor/

blindman

Вот как я вижу возможный вариант реализации шлюза. В архиве - исходники, документация и пример реализации драйверов портов ввода/вывода и SPI

Vooon

blindman мне очень понравилось!
переделал немного свою прошивку,
теперь собираются две библиотеки: serial to I²C (libserialgate.a) и твой интерфейс (libregisters.a)
а в main.c только склейка первой либы со второй.

Еще правда не успел на железе проверить

http://hg.vehq.ru/i2c-gate/file/tip

=DeaD=

2blindman: А можно это как-то сохранить с CR+LF разделителями строк? А то у меня или строки не переносятся или русских буков нету

Добавлено спустя 2 минуты 27 секунд:
И еще бы краткое описалово на русском основной идеи? Ну предложений на 5-10 не больше? :oops:

blindman

А что, и в HTML-документации русских букв не видно?

Поставь себе редактор с нормальной поддержкой UTF-8 и различных разделителей строк. Рекомендую vim

=DeaD=

Блин, слона (доксиген) то я и не заметил

виновен

Добавлено спустя 5 минут 3 секунды:
Т.е. есть разделяемый ресурс - порты ввода-вывода МК, есть способы работы с ними - общие (цифровый ввод-вывод) и специализированные (типа ШИМ, АЦП и т.д.).

Есть драйверы каждый из которых должен явно занять какой-то 1 или более портов.

Шлюз-контроллер собирается из общего ядра + набор конкретных драйверов настроенных под наш конкретный МК - так?

blindman

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

Есть драйверы каждый из которых должен явно занять какой-то 1 или более портов.

Не должен, а может. Конкретный драйвер можно и не включать, если соответствующее устройство не нужно. Ну и не 1 или более портов, а 1 или более битов одного или более портов

=DeaD=

Ну я имею в виду для работы "должен"

Про биты портов - да, всё так, разумеется

Теоретически наверное могут быть устройства и без портов

например часы или какой-нибудь встроенный в МК датчик

Добавлено спустя 43 минуты 51 секунду:
А вообще с драйверами всё красиво, мне нравится, вот только надо как-то приземлить критичные ко времени вещи - у меня в прошивке шлюз-контроллера сервы, АЦП и управление ДД повешано на таймеры и достаточно сурово на них завязано, как будем поступать в драйверной идеологии? Так же вешать обработчик? Надо тогда будет гарантировать, что он не долго работает... ?

blindman

Реально критично по времени только управление сервами. Для управления двигателями прерывания довольно редкие, десяток микросекунд задержки ничего не испортит. У АЦП свое прерывание. Надо выделить 1 таймер только на управление сервами. Движки - по другому таймеру. Во всех прерываниях, кроме серв - разрешение прерываний настолько рано, насколько возможно.

Добавлено спустя 6 минут 23 секунды:
Таймеры можно распределить так:
TCNT1 - ШИМ для моторов, периодические прерывания для изменения скорости по заданной программе.
TCNT0 - ШИМ для бамперов
TCNT2 - прерывания для серв, отсчет временных интервалов (бамперы, датчики линии)

Добавлено спустя 8 минут 35 секунд:
Re: Обсуждение реализации шлюз-контроллера
Отделил обсуждение реализации устройств от обсуждения протокола

Vooon

Сделал простой драйвер моторов (прямое управление).

Регистры:

PWM1 — 0x60 (1 byte r/w);
PWM2 — 0x61 (1 byte r/w);
DIR1 — 0x62 (1 byte r/w, 0/1 - fwd/bkwd);
DIR2 — 0x63 (1 byte r/w, 0/1 - fwd/bkwd);

Если задать PWM = 0, то таймер отключается от вывода OC1x (не будет писка)

Таймер 1 настраивается в init_motor_driver(),
прерывание не задействовано, TIMSK не изменяется

Добавлено спустя 17 минут 7 секунд:
Кстати бонус возможности мультистарта — можно почти одновременно отдать команду моторам
(быстрее, чем выполнить два запроса под ряд).

Пример:

Код:

> L20
< L20
> S2060 40 S2063 01 S2061 40 P
< SWAASWAASWAAP

Эквивалентно:

Код:

> L20
< L20
> W2060 40
< SWAAP
> W2063 01
< SWAAP
> W2061 40
< SWAAP

Но за счет отсутствия фазы парсинга запроса, первый вариант будет выполнен быстрей.
Также позволяет просто проверить статус выполнения, чтением регистра 0x00 (нужно после каждой записи добавить S2000S2101

roboforum.ru

Правила форума

Обсуждение реализации шлюз-контроллера [ORFA]

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