Я смотрю на перенос моего продукта из RTOS во встроенную Linux. У меня не так много требований в реальном времени, и несколько требований RT, которые у меня есть, составляют порядка 10 с миллисекунд.
Может ли кто-нибудь указать мне ссылку, которая расскажет мне, как в реальном времени находится текущая версия Linux?
Есть ли какие-либо другие проблемы, связанные с переходом на коммерческую RTOS в Linux?
Вы можете получить большинство своих ответов из Linux реального времени wiki и FAQ
Что такое возможности реального времени для ядра 2.6 linux?
Традиционно ядро Linux позволяет только одному процессу вытеснить другого только при определенных обстоятельствах:
- Когда ЦПУ работает в режиме пользовательского режима
- Когда код ядра возвращается из системного вызова или прерывания обратно в пользовательское пространство
- Когда код кода ядра блокируется на мьютексе или явно дает управление другому процессу
Если код ядра выполняется, когда происходит какое-либо событие, для которого требуется запуск потока с высоким приоритетом, поток с высоким приоритетом не может вытеснить код ядра, пока код ядра явно не даст контроля. В худшем случае время задержки может составлять сотни миллисекунд или больше.
Параметр конфигурации Linux 2.6 CONFIG_PREEMPT_VOLUNTARY вводит проверки на наиболее распространенные причины длительных латентностей, так что ядро может добровольно получить контроль над задачей с более высоким приоритетом, ожидающей выполнения. Это может быть полезно, но в то время как это уменьшает случаи длительных латентностей (от сотен миллисекунд до потенциально секунд или более), оно не устраняет их. Однако, в отличие от CONFIG_PREEMPT (см. Ниже), CONFIG_PREEMPT_VOLUNTARY оказывает гораздо меньшее влияние на общую пропускную способность системы. (Как всегда, существует классический компромисс между пропускной способностью --- общей эффективностью системы - и латентностью. С более быстрым процессором современных систем часто имеет смысл компенсировать пропускную способность для более низких задержек, но сервер классные системы, которые не нуждаются в минимальных гарантиях на задержку, могут очень хорошо использовать либо CONFIG_PREEMPT_VOLUNTARY, либо придерживаться традиционного невосприимчивого дизайна ядра.)
В ядре Linux 2.6 есть дополнительный параметр конфигурации CONFIG_PREEMPT, который заставляет весь код ядра за пределами областей, защищенных от спин-блокировки, и обработчиков прерываний, иметь право на недобровольное преемничество с помощью потоков ядра с более высоким приоритетом. С помощью этой опции наихудшая задержка ожидания уменьшается до (миллионных) миллисекунд, хотя некоторые драйверы устройств могут иметь обработчики прерываний, которые будут вводить задержку намного хуже, чем это. Если для приложения реального времени в Linux требуются задержки менее однозначных миллисекунд, рекомендуется использовать патч CONFIG_PREEMPT_RT.
У них также есть список "Gotcha's", как вы их называли в FAQ.
Что важны для хранения ум при записи в реальном времени приложения?
Уход за начальная фаза запуска:
- Вызовите mlockall() как можно скорее из main().
- Создайте все потоки при запуске приложения и коснитесь каждой страницы всего стека каждого потока. Никогда не запускайте потоки динамически во время показа RT, это разрушит поведение RT.
- Никогда не используйте системные вызовы, которые, как известно, генерируют ошибки страницы, такие как Еореп(). (Открытие файлов делает mmap(), который генерирует страница неисправности).
- Если вы используете "глобальные переменные времени компиляции" и/или "глобальное время компиляции" массивы ', затем используйте mlockall() для предотвращать ошибки страницы при доступе их.
Дополнительная информация: HOWTO: Создайте РТ-приложения
У них также есть большая страница публикаций , которую вы можете проверить.
Вы посмотрели Xenomai? Это позволит вам запускать процессы "жесткого реального времени" над Linux, но при этом позволяет вам получать доступ к обычным API-интерфейсам Linux для всех потребностей, не требующих реального времени.
Существует два принципиально разных подхода к достижению возможностей реального времени в Linux.
1) Замените существующее ядро такими вещами, как исправления rt-preempt. Это в конечном итоге приведет к полностью упреждающему ядру
2) Двухъядерный подход (например, xenomai, RTLinux, RTAI,...)
Есть много переходов, идущих от RTOS к Linux.
Возможно, вам действительно не нужно в реальном времени?
Я говорю о Linux в режиме реального времени в моем обучении: http://www.reliableembeddedsystems.com/embedded-systems_7.html
Ответ, вероятно, "достаточно хорош".
Если вы используете встроенную систему, вы, вероятно, имеете контроль над всем или большинством программного обеспечения на коробке.
Stock Linux 2.6 имеет несколько функций, подходящих для задач с малой задержкой - в основном это:
Предполагая, что вы используете одноядерную машину, если у вас есть только одна задача, которая установила свою политику планирования для SCHED_FIFO или SCHED_RR (не имеет значения, если у вас есть только одна задача) И заблокировала всю свою память in с mlockall(), тогда он будет назначен, как только он будет готов к запуску.
Тогда единственное, о чем вам нужно было бы беспокоиться, - это часть незаправляемой части ядра, которая занимает больше времени, чем ваша приемлемая латентность, - что вряд ли произойдет во встроенной системе, если не произойдет что-то плохое, например, чрезвычайная память давление или ваши водители являются изворотливыми.
Я думаю, что "попробуйте и посмотрите", это хороший ответ, но это, вероятно, довольно сложно в вашем случае (и может включать в себя записи драйверов устройств и т.д.).
Посмотрите на документ для sched_setscheduler для некоторой хорошей информации.