Перед тем как на конкретные вопросы отвечать, хотел пару слов сказать про Xenomai. Это что-то типа мини real-time OS. Иногда его еще супервизором называют. Он запускает Линукс как одну из своих задач и может его останавливать если есть необходимость (более приоритетная задача готова к выполнению). Т.е. поток (thread) запущеный с помощью Xenomai-ного API попадает под контроль супервизора и если нужно, то может выполняеться даже с более высоким приоритетом чем Линукс. За счет этого они добиваются хороших real-time характеристик (лучше чем preempt_rt patch который решает все внутри ядра). Собственно поэтому я и решил Xenomai использовать и вобщем поэтому и удивляюсь, что не идеально получилось и пытаюсь разобраться в чем проблема.
Еще один момент - я в тексте несколько ссылок на некоторые свои исходники дал. Весь проект полностью находится вот
тут.
Документации, как обычно, не много, но это лучше чем ничего
:
тут,
тут и
еще тут (но это надо git клонировать чтобы скачать).
Ну и блог, который я уже упоминал.
Strijar писал(а):Написать свой драйвер pwm который будет выдерживать точно длинну импульса с помощью udelay(). Правда в это время процессор будет именно простаивать - но зато точно.
Хотя можно попробовать и без udelay - но нет гарантии что при сильной загрузке будет работать гарантированно. Какая там тактовая? Может и хватит.
Писать драйвер мне тоже посоветовали на Xenomai-ном форуме. Но только не для Линукса, а для Xenomai. У них там тоже есть понятие драйвера и вроде бы он еще более точно выполняется. Ну и конечно посоветовали работать с таймерами в драйвере а не ждать, чтобы не тормозить всю систему.
Michael_K писал(а):Вы и сами прекрасно понимаете, что проблема не в арме, а в оси.
Я не знаю, как именно организовано в ксеномай и тем более, как вы реализуете работу с ШИМом.
Вероятно у оси есть какие-то тайм-слайсы, которые на порядок больше необходимой вам точности или что-то в таком духе.
Да, я понимаю. Скорее всего так и есть. Но может этот параметр можно как-то настроить... Вобщем это как раз то, что я пытаюсь выяснить (в том числе задавая вопросы на форумах
)
Michael_K писал(а):Зря заморачиваетесь с этим.
Если не хотите компиляторов-мейк-файлов и т.п. можно тупо купить готовый модуль в местном магазине или зашить ОРФА (см. местную вики) в свой контроллер. Они так и позиционируются как приложения к ББ.
Ну я на самом деле не так уж и боюсь МК
. Я умею с ними работать. Тут наверно больше дело принципа - ну раз теоретически можно сделать более компактный вариант с меньшим колличеством компонентов, то почему бы не постараться?!
Strijar писал(а):Из userspace он и не сможет - это не его задача. Из драйвера вполне. Я на 200мгц получал доступ в драйвер меньше чем 10мс ("тик" точней было не померять) Это при загрузке "под завязку".
Ну я не совсем в userspace. Как я в начале написал, поток, запущеный с помощью Xenomai-ного API, попадает под контроль супервизора. Т.е. если я правильно понимаю, он как-то сбоку от Линукса уже работает.
noonv писал(а):вопрос интересный, но мне кажется, что работу с железом лучше производить через отдельный контроллер. Просто, прозрачно и ресурсы не нужно тратить (если пока и есть свободные - это не проблема
)
Ну тасчет простоты я не совсем согласен. При работе с МК нужно будет самому очень точно планировать работу с таймерами, следить чтобы разные задачи, работающие с разной частотой (например генерация ШИМ и чтение и обработка данных с гиро/акселерометров) не мешали друг другу. Плюс надо будет организовать какой-то протокол общения между МК и основным компом. При использовании Xenomai это проще решается. Все работает в одном адресном пространстве. Плинировщик задач сам решает как работать с таймерами чтобы все задачи вовремя запускались и т.д. Т.е. просто говорю - запусти мне две периодические задачи с частотой 50Гц и 20Гц и могу быть уверенным, что мои функции будут вызваны в нужный момент. Мне кажется это проще чем с МК.
noonv писал(а):у вас в блоге показана работа со стереопарой. правильно ли я понимаю, что бигла только передаёт картинки с камер на ПК и обрабатывать их на самой плате не предусматривается?
Да, на бигле я снимаю кадр с двух камер, склеиваю их вместе, компримирую в h264 и передаю на "водительский" комп. Большую часть этой работы делает
Gstreamer. Причем есть заинтегрированные TI-шные кодеки которые используют DSP.
Вот тут можно посмотреть примеры пайплайнов для gstreamer-а которые я использую. Потом, на водительской стороне, после раскодирования, я делаю из двух склеяных кадров (левый и правый) анаглифную картинку. Использую OpenCV для этого. Сделать анаглиф легко и самому, но я всеравно планирую интенсивно OpenCV использовать, поэтому для анаглифа тоже им воспользовался. Если интересно, то
вот тут эта функция.
devel писал(а):я бы поставил сопроцессор ввода/вывода, который обрабатывал все риалтаймовские задачи.
Это наверно логично, но я пытаюсь уменьшить колличество компонент в системе. Если не получится, то наверно так и поступлю.
linvinus писал(а):andreynech, проблема не в линуксе, а в том как вы решаете задачу.
Линукс универсальная многозадачная система, есть несколько планировщиков задач и прерываний.
Есть специальные проекты по адаптации ядра для работы в реалтайм режиме, это ветка -rt
xenomai - как я понял как раз адаптирован для -rt
Как я писал в начале, Xenomai и ветка -rt (preempt-rt patch) это два разных подхода сделать из Линукса real-time систему. Xenomai дает лучшие результаты, но он всетаки "чужеродное" тело. Preempt-rt patch значительно более элегантное и "родное" для ядра решение, но пока оно дает результаты хуже чем Xenomai. Хотя, я думаю что будущее за preempt-rt. Я думаю когда-нибудь они его доведут таки до ума.
Да, конечно смотрел. На самом деле то что у меня сейчас работает, это измененный trivial-periodic.c. Вот, если интересно
мой исходник. pwm_func() это как раз функция, которая уже непосредственно генерит ШИМ.
linvinus писал(а):Ещё есть вариант использовать audio выходы, если вам достаточно двух каналов.
В этом случае pwm будет на плечах кодека, вам нужно будет только подавать специальные аудио данные через alsa или oss.
Ну я бы не хотел ограничиваться двумя выходами. Да и я вобщем хочу разобраться почему мой вариант не совсем хорошо работает. Я надеюсь, что если я научусь точно генерить ШИМ-ы, то потом смогу использовать ту же рехнику для работы с сенсорами и для других real-time задач.
Еще раз спасибо большое всем за комментарии!
Андрей.
