ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
1011611 Топик полностью
Связанные сообщения
Event DrivenRtosBigloop
А можно немного мыслей? Несмотря на кучу существующих ОС, набирающих разную популярность, всё же появляются новые. FreeRTOS, pro...2021-10-08
[Японские RTOS T-Kernel 2.0, μT-Kernel 3.0 и много других]. Регистрируют автоматом сразу, все дают качать. Очень качестве...2021-10-08
Очевидно, что без механизма ожидания -- получается полная ерунда, которая ничем не лучше биглупа. Когда событий станет мн...2020-12-06
Да, примерно об этом я и думаю. Что систему КА можно запускать параллельно, на пуле потоков, по выбирая готовые к запуску по мер...2019-10-22
Как запустить параллельную систему КА написано у Шалыто лет 20 тому назад. Впрочем и самому додуматься можно. Тема уже изъезженн...2019-10-22
Ровно наоборот. Конечные автоматы подразумевают ЯВНОЕ выделение всех возможных состояний программы (как множества состояний сист...2019-10-21
Выскажу ещё раз: FreeRTOS сырая недоделка, смысла особого, без реализации ряда перечисленного (см. ниже) не имеет и, хуже того, ...2019-10-18
"В контексте МК" никаких задач не должно быть! :) Контроллер рассчитан на обслуживание периферии, а потому никаких других событи...2019-09-20
Кооперативную не хотите попробовать? Написана на С, без ассемблера2019-09-02
Смотря какая ОС. В основном ОС делятся по типу: бывают корпоративные ОС и любительские.2019-03-20
Ты что-то не то говоришь. В тикле там свой встроенный цикл обработки событий, либо можно свой написать вместо него, смотря как у...2018-12-01
Это какое-то твоё определение. И оно не выполнимо, т.к. твои же задачи будут конкурировать и оттягивать на себя процессор, как т...2018-05-18
[Список RTOSов] всяких разных -> Проект osrtos.com2017-11-15
Обновлено: трехколесный вялошипет с квадратными колесами (многозадачка на Си). Рожалось в муках, труд всей жизни :)2015-11-16
Подход, если не нужно реальное вытеснение (т.е. критично время реакции), порочный: сложные системы в "больших компьютерах", наоб...2015-09-12
Кто-нибудь использует RTOS (не ядра) в своих проектах? Интересует их работа в защищённом режиме, взаимодействие пользовательског...2014-11-15
Вот и отличненько. Удалось значит понять суть: императивный стиль программирования повсеместно вдалбливаемый в (не)окрепший мозг...2013-07-31
Давно холиваров не было. Как насчёт RTOS vs Main Loop? Поделитесь практическим опытом. Сам RTOS не применял, да и не очень хочет...2013-07-24
правильное использование RTOS - научите уму разуму2011-12-21
Вот колеблюсь, какую RTOS использовать для ARM7. Вот приглянулись TN Kernel, ScmRTOS. Советуют AMX и FreeRTOS. Кто что подскажет...2011-11-28
Топик посвящён программированию микроконтроллеров в условиях необходимости экономии электроэнергии и архитектуре ПО в целом.2011-10-24
Нефиг си пинать за то, что он не хаскель ;)2011-08-14
Тут очень любят рассуждать о RTOS и всём таком. Но как-то массово замалчивается, что стандартная C-библиотека для неопределённог...2011-08-13
Ось для cortex-M3, в которой декларируется: "Interrupt latency is 0". В документации сказано, что критические секции организован...2009-12-08
Статья про атомарный доступ к битовым полям.2009-03-03
fk0, легенда (11.06.2020 19:54, просмотров: 1132) ответил lloyd на В protothreads мютексом будет просто любая булевская переменная (или битовый флаг, пофиг), даже volatile не обязателен. Проблема лишь в том, что любая система с обработчиком прерываний - уже вытесняющая многозадачность.
Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же самое, что конечные автоматы им. Шалыто, switch-технология. Удобней представлять в виде big loop всё-таки. Идея в том, что какой-то "протопоток", "автомат", отдал управление обратно циклу и он побежал вызывать остальные "протопотоки" или автоматы... 

И каждый из них начал проверять свои условия запуска, если выполняются -- начинает работать, остановившись (или если условия не выполняются) -- управление переходит к следующему автомату... В итоге, если набирается много автоматов (протопотоков) которые ждут каких-то событий (установки переменных в нужные значения) оно постоянно крутится и проверяет эти переменные в цикле. И эти проверки начинают занимать значительное время, хотя результат чаще негативный, время на проверки условий тратится.


В итоге очень низкая реактивность: после установки переменной нужно пробежать весь цикл, сделать 100500 проверок, увидеть, что условие выполнилось, установить пару переменных для сигнализации следующему автомату (протопотоку), и опять бежать по кругу весь цикл, чтоб запустить следующий автомат. А круг, из-за того, что переменных и автоматов много, оборачивается очень медленно. В итоге работает всё медленно, а CPU load стремится к 100%.


Это потому, что там нет планировщика, который бы избавил от необходимости одни и те же условия с одним и тем же негативным результатом вычислять бесконечное число раз в цикле. Который бы запускал соответствующий автомат (протопоток) только когда условие уж точно выполнилось.


Я давал ранее три шикарные идеи, которые можно скомбинировать в ОС 21-го века:


0) нужно ввести понятие события как атома [4, 5], события которое или произошло когда-либо в прошлом, или не происходило (событие не может нести ассоциированные данные, не может быть счётнмы -- для этого есть другие механизмы);


1) нужен разумеется планировщик, но не "планировщик задач" в многозадачной ОС, а планировщик событий, который решает какое из произошедших ранее событий требует обработки и запускает соответствующий обработчик (наподобии планировщика libevent) [3, 4, 5].


Пункты 0 и 1 -- база, фундамент для построения событийно-управляемой системы конечных автоматов, кооперативной или вытесняющей ОС. В последнем случае событие -- это срабатывание семафора, мьютекса и т.п.


2) разделение стеков [1], важный вопрос для микроконтроллеров при традиционном подходе к многозадачному программированию стек каждой задачи должен быть гигантского размера, такого, чтоб хватило на самый "глубокий" из возможных вызов функций. В итоге каждой задаче приходится выделять минимум несколько килобайт под стек. При объёме памяти в 32кБайта, например, много ли задач так запустишь? Идея в том, чтоб разделить все функции программы на два класса [2]:


* позволяющие вытеснение;


* не вытесняемые.


Функции использующие большой объём стека должны стать не вытесняемыми. Например, быстро исполняемые библиотечные функции. И все такие функции, независимо из какого потока/задачи вызваны, могут тогда использоват общий стек. Функции же которые допускают вытеснение должны использовать свои отдельные стеки, но они могут быть достаточно маленькими, буквально несколько десятков-сотен байт.


Остаётся вопрос с медленными и блокирующимися функциями требующими и большой объём стека, и вытеснение. Такие функции только остаётся реализовывать как отдельные задачи.


Разделение стеков можно реализовать с помощью функции split stacks реализованной в gcc, но её поддержка по-моему до сих пор находится на зачаточном уровне, и далеко не на всех платформах.


Альтернативой [2] может быть решение основывающееся на поддержке компилятором функции alloca или массивов переменной длины (C99). При этом указатель стека (SP) постоянно находится в "общей" области памяти предназначенной для не вытесняемых функций, но при исполнении вытесняемой функции возможно переключение задач заключающееся в смене значения регистра указателя кадра стека (FP, frame pointer), который указывает на короткий фрагмент памяти текущей задачи. Переключение задач возможно только пока не исполняется "невытесняемая функция". При переключении задач сохраняются регистры, короткий стек задачи, но общий для всех задач стек "невытесняемых функций" каждый раз инициализируется заново. Вызов вытесняемых функций при этом возможен не напрямую, а через специальный "враппер" обеспечивающий сохранение регистров и переустановку указателя стека.


Недостатком такого метода является факт, что компилятор для всех "вытесняемых" функции вынужден генерировать менее эффективный код поддерживающий отдельно кадр стека (через выделенный регистр frame pointer) -- потому, что значение SP в момент исполнения функции не детерминировано, и разумеется недопустимо в таких функциях использовать alloca или массивы неконстантной длины.


Ссылки:

1. http://caxapa.ru/458152

2. http://caxapa.ru/954365

3. http://caxapa.ru/953557

4. http://caxapa.ru/911520

5. http://caxapa.ru/841745

[ZX]