roboforum.ru

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

Очень хочется управлять сервами при помощи имеющихся портов ввода вывода из под линукса. Проблема в том, что импульс ШИМ для серв изменяется в пределах 1 миллисекунды. Если предположить что у сервы хотя бы 1024 возможных степеней свободы то необходимо выдержать точность импульса в пределах 1 микросекунды, что абсолютно невозможно программным путем в многозадачной системе. Это легко сделать без ОС но хочется сделать именно под Linux.

В общем идея такова.
У нас имеется порты ввода вывода и один таймер при помощи которых есть желание программно управлять сервами.
Необходимо будет реализовать драйвер таймера.
В общем алгоритм работы описан здесьhttp://easyelectronics.ru/upravlenie-mnozhestvom-servomashinok.html.
Немного процитирую.

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

Обработчик прерывания стартует все импульсы одновременно, выставляя уровни на портах в 1.
Затем в таймер, заносится время длительности первого импульса, прерывание завершается.
По следующему прерыванию от таймера происходит:
Сброс бита на порту нужного канала
Загрузка в регистр таймера значения оставшейся длительности второго импульса
Завершение прерывания
И таймер продолжает считать дальше. Загружая по очереди длительности импульсов и отрабатывая все каналы. Когда все импульсы для машинок будут выданы загружаем в таймер остаток от 20 миллисекунд. По следующему прерыванию все повторяется. Имеем конечный автомат который сам загружает данные в таймер, сам устанавливает и сбрасывает биты. На ассемблере обработчик может уложиться в 10-15 инструкций.

При 8 сервах будет 450 вызовов прерывания в секунду, это 4500-6750 тактов в обработчике прерывания в секунду это 0,0016875% загрузки системы при 400MHz.

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

Вот здесь и возникают вопросы.
1. Какова вероятность того, что из за вложенных прерываний тайминги будут плавать слишком сильно?
2. можно ли контроллеру прерываний без особого вреда для системы сказать поставить приоритет этого прерывания повыше? или имеем большую вероятность получить кернел паник?
3. Имеет кто либо на форуме опыт написания драйверов для Linux.
4. Прочие возможные косяки? Вообще идея имеет право на жизнь?

Обычный десктопный Linux не является операционной системой реального времени из-за непрерываемости времени выполнения процессов ядра. Для задач требующих гарантированного времени выдачи управляющих сигналов и создана RTLinux в которой "ядро" системы не является "ядром" в полной мере, а сущестует как процесс который запускается диспечером реального времени, который и запускает процессы с учётом требуемого времени реакции, при этом "ядро" вместе со всеми выполняемыми им процессами так же является процессом.... Вообще это удивительная вещь и простая по сути (дай бог врубиться )...тьфу ты, сам запутался
Вот здесь основы>>>
http://info.krc.karelia.ru/Linux/rt/rtlinux.shtml
PS. самое популярное применение RTLinux нашёл пожалуй в ЧПУ системе Linux EMC2...

Моё глубокое убеждение: не стоит этого делать. Можно и козла курить научить, но для чего?

У меня стояла подобная задача и я "прикрутил" Arduino (или любой другой) к миньке через TTL-Com порт.
Чего и тебе советую. Программа для Arduino есть, писал сам. Могу поделится. Минька только даёт команды: номер сервы и положение,а Arduino их успешно выполняет. Ни нагрузки на процессор, ни замысловатых схем, ни танцев с ядром системы и RTOS.

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