ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
16 июля
841745 Топик полностью
Связанные сообщения
Event Driven
Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же самое, что конечные автоматы им. Шалыто, switch-технология. Удо...2020-06-11
Да, примерно об этом я и думаю. Что систему КА можно запускать параллельно, на пуле потоков, по выбирая готовые к запуску по мер...2019-10-22
Как запустить параллельную систему КА написано у Шалыто лет 20 тому назад. Впрочем и самому додуматься можно. Тема уже изъезженн...2019-10-22
Ровно наоборот. Конечные автоматы подразумевают ЯВНОЕ выделение всех возможных состояний программы (как множества состояний сист...2019-10-21
Смотря какая ОС. В основном ОС делятся по типу: бывают корпоративные ОС и любительские.2019-03-20
fk0, легенда (18.05.2018 13:02, просмотров: 800) ответил argus98 на Дык несколько лет назад уже пояснял. RTOS начинается тогда, когда я могу задать периодичность выполнения для каждой задачи (в секундах/Герцах) и макс. время задержки (в секундах) обработки для каждого из событий. Всё остальное называть RTOS-ом
Это какое-то твоё определение. И оно не выполнимо, т.к. твои же задачи будут конкурировать и оттягивать на себя процессор, как ты максимальное время ограничишь??? Обычно под RTOS понимается многозадачная ОС в которой жёстко учитываются приоритеты потоков (не как в linux, высокоприоритетный поток всегда вытесняет), где приоритет потока динамически задаётся примитивом синхронизации, например, инверсия протоколов на мьютексах -- невозможна (в linux возможна). Причём здесь секунды или герцы? Тебе возможность дана. Как ты её используешь -- твоё дело. Вообще по-моему RTOS не нужна. Лучше что-то вроде libevent. Конечно гарантировать тебе, будучи зависима от тебя же, она не может, но обрабатывает события так быстро как может. Если к ней добавить тредпул, то можно позволить обработке более приоритетных событий вытеснять менее приоритетные. Разница в том, что не нужно вручную заводить "задачи" и морочить голову с их "синхронизацией". В embedded обычно задач уж очень много, не заводить же под каждую отдельный поток (и выделять стек!) Если перейти к событийно-ориентированному программированию, то вместо задач и классических примитивов синхронизации будут события и их слушатели (сигналы-слоты), но не с прямым вызовом обработчиков из сигнала, а через отложенный вызов процедур, через планировщик, упорядочивающий по приоритету события (а не задачи), обрабатывающий события в потоках тредпула. Как-то так. Потом здесь надо дать определение события, что событие -- это атом. Оно или произошло, и требует обработки, или нет. Событие не может быть счётным (произойти три раза), не может нести параметров (что подразумевает _очередь_, см. ниже). Планировщик события в принципе в битмапе хранить может, не в очереди. И обрабатывать согласно приоритету, а не по очереди. Вообще само понятие очереди практически изничтоживает идею стоющую за RTOS (обработка по приоритетам), т.к. подразумевает обработку в порядке помещения в очередь, в порядке возникновения событий. И ещё хуже, когда в очередь намешиваются разные события от разных подсистем. Тут вся идея RTOS просто умножается на ноль: приоритетов уже нет. Поэтому мне не нравится, что в ряде RTOS нет других механизмов ожидания того, что произошло одно из нескольких событий кроме очередей. Альтернативой были бы select() из linux, WaitForMultipleEvents() из windows, в TRON-подобных ОС, TNKernel, eCOS, RTEMS есть event flags (но их число обычно не больше 32-х). В FreeRTOS же ничего нет... Можно конечно устроить массу очередей и специальные задачи перекладывающие из одних очередей в другие. Напоминает костыли и подпорки. И мне не нравятся очереди в QuantumLeaps. Ровно по этой же причине, да и всегда задают следующий вопрос: а что будет, если очередь переполнится, авария же. Отказ от очередей и введение понятия атомарности события проблему нежелательного упорядочивания обработки событий решает. Конечно не все события так могут быть обработаны и для для отдельных задачи, например буфера ввода последовательного порта и т.п. никто не запрещает заводить отдельные FIFO очереди хранящие только один тип объектов, не смешивая всё в одной очереди. События с параметрами, счётные события, тоже могут быть размещены в отдельной очереди, либо вовсе поверх механизма атомарных событий может быть организован протокол синхронизации задач вроде принятого в QNX Send/Receive/Reply. Когда данные не сохраняются в очереди, а прередаются между разными компонентами/модулями системы синхронно, соответственно вопрос их хранения делегируется конкретному компоненту. Он по крайней мере знает что делать в ситуации переполнения очереди, если она вообще нужна. Для счётных событий очередь может быть заменена счётчиком тогда.
[ZX]