Comments 30
А вы лицензию на это поделие читали? Вот вам выжимка:
1- данная ОС не лицензирована на тот чип который вы используете, фактически ваша статья является доказательством нарушения лицензии. Можете связяться с микрософтом чтобы узнать что вам за это будет.
2- вы должны соблюдать экспортные ограничения США, т.к. это требование лицензии то отмазаться по 25% не получится. Сейчас из Ирана ваш репо склонируют и вы потенциально влетите на проблемы. Я правда не знаю с кем- с М$ за нарушение лицензии или с правительством США за нарушение экспортных ограничений, но я думаю вам без разницы.
Так что уберите тег Open Source, это не он.
Немного не так.
Читатели этой статьи только лишь ограничены в “Distribution and Production Use” rights на изделия с этой RTOS на этом чипе.
Я же не ограничен портировать и писать статьи про это.
Но я не произвожу и не продаю. Это исследовательский проект.
1. INSTALLATION AND USE RIGHTS.
a) General. You may install and use the software and the included Microsoft applications solely for internal development, testing and evaluation purposes.Any distribution or production use requires a separate license as set forth in Section 2.
evaluation purposes
Угу, согласно этому определению бесплатное распространение вообще не существует т.к. его никто не покупает. Хотите апеллировать к значению слов давайте ссылку на словарь.
прерывание тика системы не дольше 8 мксС чем связано такое долгое прерывание тика?
Потому что так выбрана опция RTOS.
Все пользовательские таймеры отрабатываются в этом прерывании.
Если выставить опцию обработки таймеров в отдельной задаче, то прерывание тика длиться 0.52 мкс.
пользовательские таймерыЧто они делают?
Полагаю это программные таймера. Например, во FreeRtos пользовательские таймера обрабатываются в отдельной отдельной задаче. Обычно они посылают события, всякие разные, например, раз в 1 секунду моргать светодиодом. Можно конечно и аппаратные таймера задействовать, но их бывает не хватает.
Таймера организуются в демо приложении. Я не смотрел сколько точно их там.
Это не мое приложение и оно специально не оптимизировано, его цель только демонстрация работы сервисов.
К тому же включен профайлинг и сбор статистики которые тоже потребляют сотни тактов.
И наконец 8 мкс это худшее время, и оно появляется только когда истекает какой либо из таймеров. А так прерывание тика длится все так же в районе 0.6 мкс.
Кстати таймера требуются и сервисам с таймаутами. Так что там хватает таймеров.
для 8-и задач занимают всего около 2% процессорного времениКак Вы это посчитали?
Сложил длительность всех прерываний ядра за один тик. Не совсем точно, но дает представление о масштабах.
Восемь задач. И восемь прерываний от каждой в каждом тике в худшем случае.
Я считаю всегда худшие случаи.
Тогда опишите этот случай. Я его не вижу.
Пауза между прерываниями это тоже работа сервисов RTOS.
Поэтому накладные будут 100% в этом случае.
Да, с такими накладными будет работать программа с багом, например с deadlock или некорректным ISR ядра.
RTOS - не средство от багов, а скорее катализатор багов.
Но статья рассчитана на тех кто уже знает зачем им RTOS.
Пауза между прерываниями это тоже работа сервисов RTOS.Здесь я не понял. А программы когда исполняются?
с такими накладными будет работать программа с багом, например с deadlockРазве deadlock может как то поднять накладные расходы? Я думал что просто все участники deadlock'а заснут, а остальные продолжат свою работу.
RTOS — не средство от багов, а скорее катализатор багов.Т.е. ОС не упрощает, а усложняет жизнь программистам? Из этого следует вывод, что из более громоздких и сложных проектов необходимо исключить ОС для уменьшения накладных расходов и меньшего возникновения ошибок. Правильно я Вас понял?
Просто хочу разобраться.
Здесь я не понял. А программы когда исполняются?
Сначала это я не понял.
Не понял как вы по маленьком фрагменту таймлайна определили полный процент накладных.
Я решил что вы начали рассматривать гипотетические случаи.
В таком разе я вам привел гипотетический случай с двумя залочеными задачами. И в этом случае никакой полезный код не будет выполняться и накладные 100%
Что делать разработчикам громоздких и сложных проектов я советовать не буду. На то они и разработчики сложных проектов. Полагаю они знают как бороться со сложность раз берутся за такие проекты.
Аргументы за Azure RTOS приведены в начале статьи. И там нет аргумента по поводу уменьшение ошибок.
Как я отлаживаю свой проект планирую написать в следующей статье.
Это на ваше усмотрение. Как сделаете так и будет.
Задачи могут переключаться по команде из других задач явно или неявно (вызовом мьютексов, флагов и проч.), по внешним прерываниям , по тику RTOS (тоже прерывание) который может прервать затянувшуюся задачу и передать управление другой.
Но это все конфигурируется.
Вы свободны что-то из этого запрещать, что-то разрешать.
Разработка контроллера резервного питания. Установка Azure RTOS