Удивлен, как ваш ретранслятор еще не сп… прибрали к рукам местными любителями «желтого» и другими несознательными элементами. Неужели такие не бродят по сопкам, как и Вы? =)
Автор Андрей Курниц, "FreeRTOS — операционная система для микроконтроллеров". Это хороший обзор FreeRTOS, почти дословный перевод официальной документации по FreeRTOS — «USING THE FREERTOS REAL TIME KERNEL» Ричарда Барри. Обзор публиковался в журнале «Компоненты и технологии», 2..10 номера 2011 года.
Увы, снова тема не раскрыта. Нет в статье смысла, и без этого выходит цитирование справочных данных в виде имен функций, названий параметров. Такое нагромождение непонятных данных никто, особенно новичок, ни за что не запомнит. Опять надо было начать с главного — почему, зачем?
Вот вы упомянули про очереди, про семафоры, межпроцессное взаимодействие. Без понимания смысла — для чего все это надо — изложение превращается для читателя просто в набор пустых терминов. ИМХО, надо было начать с проблем, которые решают все эти сущности — очереди, семафоры, мютексы и проч. И наглядно, с картинками, диаграммами, которые раскрывают главное — смысл. Тогда не нужно было бы цитировать справочные данные, которые пользователь FreeRTOS сам прочитает в руководстве (если заинтересуется).
Пока что статья только отпугивает новичков и затуманивает мозги. Намного полезнее прочитать оригинальное руководство от создателей FreeRTOS — там все просто, последовательно и логично разложено по полочкам.
FreeRTOS- это именно system for hard real time, то есть система, СПЕЦИАЛЬНО СПРОЕКТИРОВАННАЯ для того, чтобы обеспечить поддержку ЖЕСТКО ГАРАНТИРОВАННОГО времени отклика на внешние события. Время ожидания в ней действительно учитывается — при принятии решения шедулером о переключении задач, имеющий одинаковый относительно друг друга приоритет. Ни более ни менее. Гарантия времени реакции на события достигается настройкой приоритетов задач и прерываний.
Автору: статья нужная и интересная. Неплохо было бы вначале немного написать — "зачем все это надо?". Я имею в виду — почему появилась FreeRTOS, чем она отличается от обычных операционных систем и от обычной программы, которую пишет программист? Что она вообще дает программисту? В оригинальном руководстве «Using The FreeRTOS Real Time Kernel» Ричарда Барри этот вопрос рассматривается очень хорошо.
Константы configKERNEL_INTERRUPT_PRIORITY и configMAX_SYSCALL_INTERRUPT_PRIORITY также настраиваются в файле FreeRTOSConfig.h. Все свежие релизы FreeRTOS поддерживают вложенность и аппаратные приоритеты прерываний (на тех архитектурах, которые предусматривают настройку приоритета аппаратных прерываний).
С прерываниями там все очень умно и шоколадно устроено. Можно гибко настроить, каким прерываниям можно вытеснять код ядра, а каким — нельзя. При выходе из прерывания можно принудительно переключить контекст, то есть вернуться не в ту задачу, в которая была прервана прерыванием, а в ту, у которой приоритет выше. Например, пришел в UART символ, на него сработало прерывание, и при выходе из прерывания можно сразу принудительно переключить контекст на задачу, которая обрабатывает прием. В общем, FreeRTOS сделана с заботой о нас, о программистах. Просто бери готовенькое на блюдечке.
У Embox что-то мало поддерживаемых платформ. У FreeRTOS платформ намного больше (только под GCC я насчитал аж 19 наименований). Кроме того, есть коммерческие форки — OpenRTOS и SafeRTOS. Поэтому для разработчика FreeRTOS гораздо привлекательнее. Можно сначала потренироваться на кошечках (FreeRTOS), а потом при необходимости прикупить тяжелую артиллерию (OpenRTOS и SafeRTOS).
Это время конфигурируется константой времени компиляции configTICK_RATE_HZ в файле FreeRTOSConfig.h, которая представляет из себя частоту в Герцах. Например, если configTICK_RATE_HZ установлена в 100 (Гц), то длительность слайса (тика времени, через которые происходит переключение контекста) составит 10 мс.
Во FreeRTOS переключение контекста выполнения реально может происходить намного чаще, чем каждый слайс времени — при окончании аппаратного прерывания, при добровольной передаче контекста (вызовом taskYIELD()), при наступлении событий.
Шедулер (планировщик) отвечает за принятие решения о переключении контекста выполнения (т. е. какой задаче передать ресурс процессора). Решение это принимается на основе приоритета задач, а также на основе подсчета времени, которое задача провела в состоянии ожидания (чем дольше задача бездействовала, тем больше у неё прав на запуск). Приоритет назначается при создании задачи (uxPriority, упомянутый в статье), и может быт изменен или считан в ходе выполнения программы через специальные функции API FreeRTOS (vTaskPrioritySet(), uxTaskPriorityGet()).
Моменты времени, когда происходят переключения задач с использованием шедулера, бывают в точках окончания каждого тика времени (для этого используется прерывание по таймеру), а также в момент вызова функций API FreeRTOS, и при наступлении специальных событий (окончание аппаратного прерывания, окончание времени блокировки задачи, наступление момента обновления очереди или семафора).
Задачи, которые имеют равный приоритет, имеют одинаковые права на процессор, и переключаются на выполнение по очереди. Задачи, которые имеют более высокий приоритет, вытесняют (preempt) все задачи, которые имеют приоритет меньше. Высокоприоритетные задачи могут принудительно отдать свое процессорное время (вызовом taskYIELD(), если они завершили свою нужную работу), или заблокироваться в ожидании специального события, позволяя тем самым менее приоритетным задачам возможность запуститься. Таким образом во FreeRTOS для переключения задач используется алгоритм приоритетного (с фиксацией приоритета) планирования запуска задач с вытеснением, вытесняющая многозадачность (Fixed Priority Preemptive Scheduling). Однако имеется возможность применить и другой алгоритм переключения задач — кооперативная многозадачность (Co-operative Scheduling). У каждого алгоритма свои достоинства и недостатки, и соответственно разная область применения.
Для обмена данными задача-задача, задача-прерывание, прерывание-задача во FreeRTOS имеются специально предусмотренные объекты — очереди. При обмене данными или событиями предусмотрена синхронизация высокоприоритетной задачи (или прерывания) и менее приоритетной задачи. Синхронизация происходит с помощью блокировки на очереди или семафоре, при этом можно задать время блокировки (таймаута процесса передачи). Для атомарных операций есть возможность создавать критические секции кода.
Где Вы тут увидели «категоричное заявление»? Это просто констатация фактов, которые мы видим каждый день.
Прогресс не стоит на месте. Физическая модель организации памяти уже давно мало кого интересует, кроме как разработчиков операционных систем. Это совершенно нормально, так и должно быть, так как мы хотим видеть в компьютере удобный в производстве инструмент, а не набор проводков и микросхем.
Сейчас основной мейнстрим производства ПО — верстка сайтов, бизнес-приложения, производство и обработка графического и звукового материала. Программы для этих целей давно пишутся на основе высокоуровневых библиотек и операционных систем, скрывающих (и слава богу) от программиста кучу ненужных деталей. Поэтому я не стал говорить, что знания устройства памяти устаревшей архитектуры x86 стопроцентный мусор — это просто знания, которые уже редко кому нужны. То есть это мусор примерно на 95%, отвлекающий нас от реальности.
Да, апноут у Microchip очень хороший по управлению моторами BLDC (Brusheless DC) — принцип описан очень понятно и наглядно. Но почти все контроллеры делают все равно почему-то на Atmel.
В статье описано простейшее малоэффективное управление фазами без обратной связи, у такого принципа генерации фаз слишком мал КПД и крутящий момент. Намного более эффективен метод генерации фаз с отслеживанием положения ротора — по датчикам Холла или по ЭДС самоиндукции, причем необязательно для фаз генерировать синусоиду — достаточно просто применить простое ключевое управление напряжением на обмотках.
В профессиональных массовых приложениях, когда нужно получить максимальный КПД и наиболее дешевое железо — например, в жестких дисках или в моторчиках авиамоделей — генерируют фазы грубой аппроксимацией синусоиды с отслеживанием положения ротора по ЭДС самоиндукции. В жестких дисках для этой цели не изобретают велосипед и применяют специализированные контроллеры. В контроллерах авиамоделей применяют микроконтроллер AVR ATmega8 или ATmega16. Есть реализации таких контроллеров с открытой принципиальной схемой и исходным кодом, см. например http://www.mikrokopter.com.
Вот вы упомянули про очереди, про семафоры, межпроцессное взаимодействие. Без понимания смысла — для чего все это надо — изложение превращается для читателя просто в набор пустых терминов. ИМХО, надо было начать с проблем, которые решают все эти сущности — очереди, семафоры, мютексы и проч. И наглядно, с картинками, диаграммами, которые раскрывают главное — смысл. Тогда не нужно было бы цитировать справочные данные, которые пользователь FreeRTOS сам прочитает в руководстве (если заинтересуется).
Пока что статья только отпугивает новичков и затуманивает мозги. Намного полезнее прочитать оригинальное руководство от создателей FreeRTOS — там все просто, последовательно и логично разложено по полочкам.
Константы configKERNEL_INTERRUPT_PRIORITY и configMAX_SYSCALL_INTERRUPT_PRIORITY также настраиваются в файле FreeRTOSConfig.h. Все свежие релизы FreeRTOS поддерживают вложенность и аппаратные приоритеты прерываний (на тех архитектурах, которые предусматривают настройку приоритета аппаратных прерываний).
Во FreeRTOS переключение контекста выполнения реально может происходить намного чаще, чем каждый слайс времени — при окончании аппаратного прерывания, при добровольной передаче контекста (вызовом taskYIELD()), при наступлении событий.
Моменты времени, когда происходят переключения задач с использованием шедулера, бывают в точках окончания каждого тика времени (для этого используется прерывание по таймеру), а также в момент вызова функций API FreeRTOS, и при наступлении специальных событий (окончание аппаратного прерывания, окончание времени блокировки задачи, наступление момента обновления очереди или семафора).
Задачи, которые имеют равный приоритет, имеют одинаковые права на процессор, и переключаются на выполнение по очереди. Задачи, которые имеют более высокий приоритет, вытесняют (preempt) все задачи, которые имеют приоритет меньше. Высокоприоритетные задачи могут принудительно отдать свое процессорное время (вызовом taskYIELD(), если они завершили свою нужную работу), или заблокироваться в ожидании специального события, позволяя тем самым менее приоритетным задачам возможность запуститься. Таким образом во FreeRTOS для переключения задач используется алгоритм приоритетного (с фиксацией приоритета) планирования запуска задач с вытеснением, вытесняющая многозадачность (Fixed Priority Preemptive Scheduling). Однако имеется возможность применить и другой алгоритм переключения задач — кооперативная многозадачность (Co-operative Scheduling). У каждого алгоритма свои достоинства и недостатки, и соответственно разная область применения.
Для обмена данными задача-задача, задача-прерывание, прерывание-задача во FreeRTOS имеются специально предусмотренные объекты — очереди. При обмене данными или событиями предусмотрена синхронизация высокоприоритетной задачи (или прерывания) и менее приоритетной задачи. Синхронизация происходит с помощью блокировки на очереди или семафоре, при этом можно задать время блокировки (таймаута процесса передачи). Для атомарных операций есть возможность создавать критические секции кода.
Прогресс не стоит на месте. Физическая модель организации памяти уже давно мало кого интересует, кроме как разработчиков операционных систем. Это совершенно нормально, так и должно быть, так как мы хотим видеть в компьютере удобный в производстве инструмент, а не набор проводков и микросхем.
Сейчас основной мейнстрим производства ПО — верстка сайтов, бизнес-приложения, производство и обработка графического и звукового материала. Программы для этих целей давно пишутся на основе высокоуровневых библиотек и операционных систем, скрывающих (и слава богу) от программиста кучу ненужных деталей. Поэтому я не стал говорить, что знания устройства памяти устаревшей архитектуры x86 стопроцентный мусор — это просто знания, которые уже редко кому нужны. То есть это мусор примерно на 95%, отвлекающий нас от реальности.
Неплохо еще сюда добавить — в 95% технологий современного программировании все знания, описанные здесь — мусор, который не пригодится.
В профессиональных массовых приложениях, когда нужно получить максимальный КПД и наиболее дешевое железо — например, в жестких дисках или в моторчиках авиамоделей — генерируют фазы грубой аппроксимацией синусоиды с отслеживанием положения ротора по ЭДС самоиндукции. В жестких дисках для этой цели не изобретают велосипед и применяют специализированные контроллеры. В контроллерах авиамоделей применяют микроконтроллер AVR ATmega8 или ATmega16. Есть реализации таких контроллеров с открытой принципиальной схемой и исходным кодом, см. например http://www.mikrokopter.com.