roboforum.ru

[=DeaD=]

Добавил в название темы ORFA - Open Robotics Firmware Architecture

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

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

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

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

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

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

[Duhas]

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

[blindman]

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

[=DeaD=]

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

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

[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 не больше?

[blindman]

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

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

[=DeaD=]

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

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

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

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

[blindman]

Есть драйверы каждый из которых должен явно занять какой-то 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