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. Прочие возможные косяки? Вообще идея имеет право на жизнь?

Во-первых проще всего не стартовать все 8 серв одновременно, а отрабатывать их по очереди, тогда гарантировано не будет ситуации срабатывания 2 подряд прерываний с шагом 1мкс.

Мы так делаем в своем OR-AVR-M128-S, на счетчике 74hc4017d

Во-вторых 1024 положения не нужно, реально 256 позиций для сервы более чем достаточно, обычно сервы не имеют достаточной разрешающей способности, чтобы даже эти 256 позиций закрыть.

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

vadinator писал(а):Обычный десктопный Linux не является операционной системой реального времени из-за непрерываемости времени выполнения процессов ядра.

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

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

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

идея хороша, но действительно - стоит ли игра свеч? не лучше ли выдавать команды контроллеру, который будет управлять N-ым количеством серв?

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

Вообще использовать обработчик IRQ не очень удачная затея. Linux не является реалтайм системой не в последнюю очередь из-за кривости драйверов, работающих с прерываниями. Особенно это касается драйверов USB/SD и NAND. Есть даже такой патч PREEMPT_RT кажется называется. Он делает много чего, в том числе и превращает обработчики прерываний в потоки ядра, которые уже лучше управляемы, т.к. имеют приоритеты и могут быть прерваны из user space. Но к сожалению на S3C2440 оно не работает. Я думаю вам имеет смысл посмотреть в сторону FIQ. Он имеет приоритет выше чем любое прерывание и любая переферия ( если я не ошибаюсь, но таймера точно) могут быть сконфигурированы на FIQ или IRQ. Таким образом вы сможете обеспечить более-менее стабильную точность прерываний - дрожание в пределах 40-50 мкс. Столь высокий джиттер видимо определяется частотой попадания в кэш, но я не уверен. И еще, обработчик FIQ, написаный на Си, не очень сложный, при частоте прерываний 100 кГц отнимает примерно 50% производительности. Так что придется либо на асме делать, либо очень сильно оптимизировать код. И все равно, поскольку основной вычислительный процесс будет работать в user space, то вопрос обеспечения реалтаймовости передачи данных для обработчика FIQ таймера остается открытым, особенно при интенсивной работы дисковой подсистемы.
Все это из лично опыта.