|
|
=== Зачем вообще RTOS? От нее я особого проку не вижу, разве что поедание драгоценных машинных циклов и байтов памяти. Все тоже самое можно сделать без РТОС на связке конечных автоматов в одной задаче с меньшими потерями в производительности (хотя бы нет переключения контекстов). Правда самому придется чуть-чуть больше напрячь мозги.
Согласен со всем, кроме последнего предложения. Мозги придется напрячь не чуть-чуть, а прям, до их, мозгов, посинения. Просто как иллюстрация.
В моей последней корейской фирме, до меня делали только жестский ASIC (hardware design). Естестевенно, он был гораздо лучше, по сравнению с использованием ядра. Но корейцы, которых можно обвинить в чем угодно, но только не в непрактичности, перешли только на покупные ядра. Т.е. из практических соображений (скорость и простота разработки готового продукта) RTOS очень нужна. Вот решаю я ныне задачу:
1. нужен непрерывный реал-тайм для группы измерителей
2. нужна одновременная мощная спектральная обработка
Ну не бьются у меня эти задачи никак! Только таймером смог придумать...
=== 2) Почему это ориентир на Гарвардскую архитектуру, которая якобы "обычно применяется". У меня например обычно применяется не Гарвардская, так как я любитель TI.
Pardon???
=== 1) Может быть не внимательно прочитал, но по моему нету ничего про самое основное (на мой взгляд опять же), что может дать полезного RTOS. Это передача управления задаче с заранее заданным жестким временным интервалом.
Не понял, что тут имеется ввиду. Фиксированное время отклика RTOS на запрос или что-то другое?
=== 2) Кроме ...
На счет флага-уведомления согласен.
Про мьютекс. Как мне объяснял один товарищ, мьютекс это вовсе не флаг, а переменная, которая имеет множество значений, а не только 0 и 1. Т.е. мьютекс - более сложное понятие. Следующая ступень - семафор, который уже представляет из себя структуру.
=== 3) ну и про приоритеты. Их, конечно же, не надо иметь для тех задач, которые выполняют обработку. Но кроме них часто еще бывают задачи, которые могут и подождать - интерфейс с пользователем, работа с жестким диском или флешкой через буфер в ОЗУ, и т.п. Для них можно иметь и вытеснение, и приоритеты, прибавив не-реалтаймовскую составляющую.
На счет добавление нереалтаймовской составляющей тоже согласен. Но не согласен с конкретным примером. Работе с флэшью можно дать 1 временной фрейм из 1000. Пусть телится по-тихоньку. Зачем ее прерывать?
|
|
E-mail: 
info@telesys.ru
