Является ли ОСРВ играть важную роль или процессор играет важную роль в определении времени переключения контекста? Каков процент доли между этими двумя основными игроками при определении времени переключения контекста.Время переключения контекста - роль RTOS и процессора
Может ли кто-нибудь сказать в отношении ОСРВ uC/OS-II?
Я бы сказал так значительны, но это на самом деле не так просто:
Фактическое время переключения контекста является просто вопросом количества циклов команд, необходимых для выполнения переключателя, как что-либо в программном обеспечении он может быть закодирован эффективно или может не быть. С другой стороны, при прочих равных условиях процессор с большим набором регистров потребует больше циклов команд для сохранения контекста; но наличие большого набора регистров может сделать другой код намного более эффективным.
Процессор также может иметь архитектуру, которая напрямую поддерживает быстрое переключение контекста. Например, скромный 8-битный 8051 имеет четыре дублирующих банка регистров; поэтому переключатель контекста - это немного больше, чем переключатель банка регистров (если у вас не более четырех потоков), и учитывая, что Silicon Labs производит устройства на основе 8051 на 100MIPS, это может быть очень быстро!
Более сложные процессоры и операционные системы могут использовать MMU для обеспечения защиты потоковой памяти, это дополнительные служебные расходы коммутатора контекста, но с преимуществами, которые могут отменить это. Также, конечно, такие процессоры, как правило, также имеют высокие тактовые частоты, что помогает.
В целом, скорость процессора, архитектура процессора, качество реализации RTOS и функциональность, предоставляемая RTOS, могут повлиять на время переключения контекста. Но в итоге самый простой способ улучшить время переключения - это, безусловно, увеличение тактовой частоты.
Хотя приятно иметь больше запаса прочности, если время переключения контекста является проблемой для вашего проекта на любом уважаемом RTOS, вы должны учитывать пригодность вашего оборудования или вашего дизайна. Вы должны стремиться к дизайну, который минимизирует контекстные переключатели. Например, если преобразование АЦП принимает 6us, а переключатель контекста принимает значение 20us, то вам лучше заняться оживлением, чем использовать прерывание с полным завершением; лучше использовать передачи DMA, чтобы избежать переключения контекста на отдельные элементы данных, где это возможно.
ОСРВ uC/OS-II написано на C с некоторыми очень специфическими разделами (возможно, в сборке) для обработки процессора. Переключение контекста будет частью разделов, которые очень специфичны для процессора.
Таким образом, время переключения контекста будет сильно зависеть от выбранного процессора и конкретных разделов, используемых для адаптации uC/OS-II к этому процессору. Я считаю, что весь исходный код доступен, чтобы вы могли видеть, сколько источника требуется для переключения контекста. Я также думаю, что uC/OS-II имеет обратный вызов, который может позволить вам добавить некоторый код измерения производительности.
+1 для адресации части вопроса uC/OS-II и предоставления точной информации для загрузки. – Dan
Чтобы завершить то, что говорил Клиффорд, время переключения контекста также зависит от условий, которые вызывают контекстный переключатель, поэтому в основном это зависит от эталона.
В зависимости от реализации RTOS в некоторых случаях можно напрямую переключиться на первый процесс ожидания, минуя планировщик.
Это, конечно, дает огромный толчок в некоторых тестах.
Например мы делаем некоторые тест, который измеряет нагрузку (в мкс), необходимое для доставки сигнала и перейти к процессу высокого приоритета той или иной конкретной конфигурации ядра и целевой архитектуры: http://www.bertos.org/discover/context-switch-overhead
@Alexandre: Fixed - благодаря. Разумеется, вы могли отредактировать его самостоятельно. – Clifford
Вам нужно как минимум 2k rep отредактировать обычный пост. –
@Alexandre: моя ошибка. – Clifford