1) Зачем вообще RTOS? От нее я особого проку не вижу, разве что поедание драгоценных машинных циклов и байтов памяти. Все тоже самое можно сделать без РТОС на связке конечных автоматов в одной задаче с меньшими потерями в производительности (хотя бы нет переключения контекстов). Правда самому придется чуть-чуть больше напрячь мозги.
2) Почему это ориентир на Гарвардскую архитектуру, которая якобы "обычно применяется". У меня например обычно применяется не Гарвардская, так как я любитель TI.
Теперь по делу. Все сказанное по-моему правильно, но... Много чего нету.
1) Может быть не внимательно прочитал, но по моему нету ничего про самое основное (на мой взгляд опять же), что может дать полезного RTOS. Это передача управления задаче с заранее заданным жестким временным интервалом.
2) Кроме свободен-занят ресурс очень важен флаг-событие (с автосбросом и без). То есть флаг, позволяющий сообщить о том, что что-то произошло. О нем я не заметил. Он отличается по поведению от флага занятости ресурса (английские термины - это соотв. mutex и event). Для флага-mutex'а (занятость ресурса) ф-ция ожидания при освобождении ресурса делает сразу захват ресурса, помечая флаг ID'ом задачи, что говорит, что ресурс в данный момент доступен данной задаче. И последующие ожидания этой задачей пройдут без остановки, а другими - с остановкой. Для влага-события (event) такого нет. Одна задача его устанавливает, сигнализируя кому-то о событии, другая - сбрасывает, среагировав на событие. Сброс может производиться автоматически в ф-ции ожидания.
3) ну и про приоритеты. Их, конечно же, не надо иметь для тех задач, которые выполняют обработку. Но кроме них часто еще бывают задачи, которые могут и подождать - интерфейс с пользователем, работа с жестким диском или флешкой через буфер в ОЗУ, и т.п. Для них можно иметь и вытеснение, и приоритеты, прибавив не-реалтаймовскую составляющую.
info@telesys.ru
