Средства и методы разработки

Это какое-то твоё определение. И оно не выполнимо, т.к. твои же задачи будут конкурировать и оттягивать на себя процессор, как ты максимальное время ограничишь??? Обычно под 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. Когда данные не сохраняются в очереди, а прередаются между разными компонентами/модулями системы синхронно, соответственно вопрос их хранения делегируется конкретному компоненту. Он по крайней мере знает что делать в ситуации переполнения очереди, если она вообще нужна. Для счётных событий очередь может быть заменена счётчиком тогда.