В настоящее время при создании систем цифровой обработки сигналов широко используется понятие «Операционная Система Реального Времени» или RTOS (Real Time Operating System). Подразумевается, что эта система многозадачная, имеет средства для синхронизации независимо исполняемых программных модулей и обмена информации между ними. В принципе, под это понятие попадает любая Операционная Система (ОС), которая имеет ограничение времени отклика на любой запрос, как со стороны аппаратной части, так и со стороны исполняемых программных модулей. Но использование RTOS, к сожалению, не гарантирует режима реального времени для всего аппаратно-программного комплекса, всей системы в целом. Причина состоит в том, что необходимо учитывать собственно задачи и аппаратную часть.
Введем новое понятие – Система Реального Времени, которое распространяется не только на RTOS, но и на исполняемые задачи и аппаратную среду.

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

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

1. Задачи должны исполняться одновременно и, следовательно, в режиме разделенного времени.
2. Задачи не должны прерывать друг друга и, следовательно, они все имеют одинаковый приоритет.

Последнее следствие неочевидно, поэтому остановимся на нем особо. Когда одна задача прерывает другую? Когда ресурсов системы не хватает на обе задачи одновременно. Т.е. прерывание задачи приведет к тому, что прерванная задача не успеет обработать данные (пройти реперную точку) за оговоренное время. Таким образом, при прерывании одной задачи другой, не выполняется условие для Системы Реального Времени. Если же ресурсов хватает на всё, то необходимость прерывания одной задачи другой отпадает. Естественно, если задачи не конкурируют между собой за ресурсы, то присваивание им приоритетов не имеет смысла.

Рассмотрим один из способов реализации СРВ. Наложим следующее условие: требование к аппаратной части и исполняемым задачам должны быть минимальны. Имеется в виду, что задачи и процессор никак между собой не связаны и не влияют друг на друга. Т.е. весь интерфейс по их взаимодействию поддерживается только RTOS. Теперь мы можем определить алгоритм функционирования Операционной Системы Реального Времени.
1. Т.к. несколько задач выполняется параллельно, то предлагается применить методологию выполнения нескольких программных блоков в «разделенном времени». Иначе говоря, система порождает тики, которые следуют через строго определенное время. Время между двумя тиками называется фреймом. В течение фрейма работает только одна задача. По окончании фрейма, если это необходимо, может начать работать следующая задача, либо продолжить работу предыдущая. Чередованием задач управляет Планировщик исходя из расписания. Планировщик также должен запускать процедуру сохранения и восстановления контекстов задач. На этом его функции заканчиваются. Тики организуются при помощи прерывания от таймера, обработчиком которого и выступает Планировщик.
2. Кроме планировщика, должен существовать программный модуль, принимающий по особому каналу команды для системы и доводящий эти команды до конкретных задач. Предлагается обработчик команд запускать в начале каждого фрейма.
3. Важной частью RTOS являются драйвера. По причинам, изложенным ниже, драйвера должны запускаться также каждый тик.

Наложим дополнительные ограничения на Систему Реального времени. Пусть она перерабатывает некую входную информацию, организованную в виде потоков, в информацию выходную, организованную подобным же образом (как выходные потоки). А задачи, работающие в реальном времени и параллельно, выполняют эту переработку. Это приводит к следующему: потоковая информация – это непрерывная последовательность неких чисел, следовательно, ее лучше всего обрабатывать по-блочно. Т.е. входные числа организуются в некий буфер, который передается задаче для обработки. Но время обработки этого буфера задачей может оказаться больше времени между приходом двух входных отсчетов. Потому для подобных систем, ориентированных на поточную обработку в реальном времени имеет смысл применить зеркальные буфера. Как они работают можно увидеть на следующем примере.
Пусть есть два входных буфера А1 и А2, а так же два выходных В1 и В2. Когда буфер А1 перерабатывается задачей в буфер В1, один драйвер RTOS заполняет из входного потока буфер А2, а другой из выходного буфера В2 формирует выходной поток. После того как Буфер А1 переработан в В1, буфер А2 заполнен, а буфер В2 опустошен, меняются местами А1 и А2, В1 и В2. Теперь задача перерабатывает буфер А2 в В2, А1 заполняется из входного потока, а из В1 данные отправляются в выходной поток. Затем буфера снова меняются местами. В том случае, если буфера достаточно длинные, а входной и выходной поток – короткие порции информации, то «набивка» входных буферов и выходных потоков должна происходить каждый фрейм, чтобы избежать потери данных.

Исходя из вышесказанного, определим формальную структуру задачи для такой системы реального времени. Предлагается разделить задачу на алгоритмическую часть и данные. Это может быть особенно интересно для систем, реализованных на сигнальных процессорах DSP, потому как там обычно применяется Гарвардская Архитектура, когда память программ и память данных разделены. Алгоритмическая часть делится на три блока: процедура восстановления контекста, тело задачи и процедура сохранения контекста. Данные делятся тоже на три типа: управляющие данные, стек (или контекст задачи) и входные/выходные буферы. Таким образом, задача оформляется в виде следующей С-фунции:

task( descriptor* ddd)
{
….
}

Дескриптор тоже должен иметь некую структуру. Например:

typedef struct {
int Status;
int FrameNumber;
int CurrentFrameNumber;
int StackPointer;
void* ContextResoring;
void* FunctionBody;
void* ContextSaving;
int* *InputBuffer1;
…
int* *InputBufferN;
int* *OutputBuffer1;
…
int* *OutputBufferN;
int Control1;
…
int ControlN;
int Service1;
…
int ServiceN
} descriptor;


Status – переменная, которая характеризует статус задачи. Допустимые значения:
0 – задача пассивна, т.е. Планировщик ее всегда пропускает.
1 – задача активна и готова к выполнению. Планировщик, запуская эту задачу, присваивает статусу значение 2.
2 – задача исполняется.
Пассивный статус, выставляет себе сама задача. Например, задача является некой инициализацией. Тогда, выполнившись один раз, она более не запускается.
FrameNumber – количество фреймов, которые отводятся под выполнения данной задачи. Отвод под задачу одновременно нескольких фреймов, позволяет сэкономить на перезагрузке контекста и распределить производительность процессора оптимально между задачами.
CurrentFrameNumber – количество фреймов, которые задача уже выполняется.
StackPointer – текущий указатель стека данной задачи.
ContextResoring – указатель на процедуру восстановления контекста.
FunctionBody – указатель на тело задачи.
ContextSaving – указатель на процедуру сохранения контекста.
*InputBufferN - указатель на указатель входного буфера. Это удобно для переключения зеркал буферов, т.к. для этого в эту переменную всего лишь подставить указатель на новый буфер.
*OutputBufferN - указатель на указатель выходного буфера
ControlN – команды управления для данной задачи, формируемые особым программным модулем.
ServiceN – служебные переменные.

Наконец, рассмотрим синхронизацию и коллизии одновременного доступа к ресурсам нескольких задач одновременно. Предлагается разрешить эту проблему при помощи простейшего системного ресурса – флага. Любому ресурсу общего пользования может быть присвоен флаг. Флаг может иметь только два значения: 0 – ресурс свободен, 1 – ресурс занят. Непосредственный доступ к флагу никто не имеет. Изменить флаг можно только API-функциями, которые реализованы, как квантовые операции через критические секции. Иными словами, на момент доступа API-функции к флагу запрещены все прерывания.
В конце сделаем несколько полезных пожеланий:
1. Необходимо, по-возможности, объединять в одну задачу несколько подзадач с целью сокращения количества используемых стеков и уменьшения накладных расходов на перезагрузку контекстов.
2. Не использовать в задачах глобальные переменные, используя для подобных целей только дескриптор задач. Это позволит взять под контроль все источники воздействия на задачу, что чрезвычайно важно на этапе отладки.
3. Скрывать от задач «зеркальность» входных/выходных буферов. Это не требует больших накладных расходов (реализуется при помощи указателей на указатель буфера), но существенно упрощает саму задачу.
4. Максимально использовать API-протокол для каких либо внешних взаимодействий.

Теперь подведем итоги. В данной статье была определена типовая структура RTOS для задач Цифровой Обработки Сигнала. Описаны программные модули, на которых она строиться и их принцип функционирования. Определена формальная структура задачи и сделан практически важный для аппаратной части вывод, о возможности использования в системе только одного прерывания (от таймера) и отказа от приоритетов.

Да, fontp наглости и самомнения тут в избытке!

2 st256
Во-первых, ясно что не с Вами беседовать, а на этом форуме. К Вашему ПО это не относилось.

во-вторых, разговор про технологичность (библиотеки системных вызовов, макросы или круче язык высокого уровня) - Это к Вам вопрос был (извините за легкую синтаксическую ошибку). Вы это, мне как будущему пользователю, предложите (или только правила свои указываете и неправильные определения)? Зачем мне тогда эта фигня? Чем она мне поможет в моих задачах ЦОС на сигнальных процессорах? Я, что сама, не сумею использовать одно прерывание таймера для выделения квантов времени между задачами? Насколько Ваше ПО покроет круг моих настоящих или новых задач и поможет их решить быстрее (технологичнее), чем я это все сделаю сама? Это только один аспект, могу и продолжить..

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

Сообщение отредактировал Vic1 - Feb 22 2006, 12:45

Да вряд ли... Я уже за последние годы столько понаделал в этом ключе...
Кстати, доводами Вы побрезговали... Стьюдент? Бачелор?

А доводам Вы не внемлите. Посему ограничился пожеланием.
Из студенческого возраста вышел в начале 80x.

Да не надо воспринимать его коменты всерьёз. Он развлекается тем, что выводит людей из себя.
Типа прикалывется. Получается, как-то не очень, с переходом на личности. B общем-то он это особо не скрывает. Это давно знакомо всем на telesys. Интернет-образ такой.
Потому и говорю - корейский провокатор - в его же манере Ну пускай помашет своим единиственным флагом, мне, например не жалко, чего заводиться. Все же понимают, что всё это несерьёзно.

Только вот закончив пересчёт массива коэффициентов, если у вас, положим, для однозначности, авторегрессионный фильтр, да ещё и относительно высокого порядка (>13-21), коэффициенты которого не особо склонны к устойчивым значениям (быстро и по сложной зависимости меняются от требуемой АЧХ) ... вам требуется взаимодействие ваших задач:
- принудительно остановить MP3, а не по наступлению time-slice ...
- занести весь массив целиком (или вы будете использовать в фильтре коэффициенты 1-7 из старого "комплекта", а 8-13 - из нового? )...
- и после этого опять принудительно (не по наступлению time-slice) снова активизировать задачу МР3...



Это что? имеется в виду примитивная реализация мютекса на INC/DEC в рассчёте на их атомарность? Это может работать ... на некоторых архитектурах .



Я, к сожалению, не знаю uCOS, но знаю как это легко сделать в QNX + pSOS + VxWorks ...



Семафора или мютекса? - вы их различаете в лицо?
Видел, видел ... и обработчики прерываний ... более того, что обработчики могут быть идеологически принципиально разными (см. напр. InterruptAttachEvent QNX , который не совсем и обрабтчик, а ... перепланировщик ).
Только когда я использую, пусть при некоторых накладных расходах, стандартизованный и многие годы обкатанный механизм - я могу гарантировать его поведение, то, что он не выкинет "фортель" на 7-м году непрерывной эксплуатации ...



... сам с собой потихоньку разговаривать ...
и другие приятные штучки ...

Сообщение отредактировал Olej - Feb 22 2006, 14:52

Ну-ну, леди, Вы же понимаете, что Вам я в таком духе ответить не могу.
Фунту, могу, а Вам - никак. Правда, Фунт совершенно точно не леди



Нет. Такой как я - только один.



Зачем? Я предложил статью, в которой должны быть отысканы несуразности.



А какие мои определения неправильны? Можете назвать и обосновать? Кстати, там есть такие.



Дык, статьи нужны...



А Вы DSP инженер?




Все не так просто. Отконфигурите (задайте структуру блоков и их взаимодействие), например, следующую систему:

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

Кстати, памяти, всего... ну 32к. Прям как у меня сейчас. И как Вы все это склеете?





Я ж не знаю Ваших задач.




О! Это да. Щас своим американцам отпишу, что они используют термины неграмотные

А есть ли доводы у человека, пытающегося рассуждать на DSP темы и проживающего в Риге? Ну просто интересно, откуда у Вас такой апломб? Вот я Сигнальные Процессоры до недавнего времени разрабатывал, а что делали Вы? У Вас не может быть ни опыта, возможности его получить. Все, что Вы могли сделать, это переделать "Альфу" под супермаркет.
Потому, обижайтесь на себя. Я не виноват в Ваших проблемах.



Дорогой Фунт, у Вас явное желание меня уязвить. Но я неуязвим.

Припев:
Зато мы делали ракеты
И перекрыли Енисей,
А так же в области балету,
Мы впереди планеты всей...

Это в прошлом, теперь Ваши "знания" позвляют попытаться решать только "глобальные" проблемы типа разработки тупого MP3 плеера на слабопригодном для этого чипе. У многих других разработчиков
проблемы другие, посему непонимание Ваших проблем - переросли они их.

Давайте сразу я Вас поправлю. По непонятным мне причинам "авторегрессионными фильтрами" мы не пользуемся. Всегда добавляем туда фильтр "скользящего среднего". Мы и терминами такими не пользуемся. Говорим просто БИХ-фильтры. Кроме того, БИХ с 13-ю коэффициентами это даже не смешно. Он никогда не заработает. Он будет возбуждаться чего бы Вы с ним не делали. БИХи обычно бьют на звенья 2-го порядка. Они более-менее устойчивые.



А теперь выходит st256, все делает по-своему, ничего не прерывает, ничег не активизирует и у него все работает... Не верите?



Ну для задачи описаной выше хватило...



В uCOS (microC) просто все задачи могут иметь только разные преоритеты.



Да. Один толстый, другой худой. Но самый элегантный это флаг.
Я конечно понимаю, что во многих системах эти понятия реализованы по-разному, но мне так считать удобнее.



Когда говорят о QNX, я честно не понимаю куда ее засунуть. Ну в сотовых нуклеас и симбиан это последствия изнасилования разработчиков каким-нибудь Квалкомом, а QNX-то нафига??? Чем тогда уж LINUX не угодил? Кстати, на хосте, прикрученному к DSP, у нас крутилась LINUX. И все успевала. Даже тот же эквалайзер дергать.




Да это бывает.



Да нет. Плеер это только одна из задач. Там еще дофига чего было. Мы делали третий(мультимедийный) чип для сотовых. Второе направление чипов я четко не знаю, но мой шедуллер выдернули и туда, выкинув стандартные оси.
И почему в прошлом? Вы не забывайте, я живу в России. А это сегодня уже очень серьезная страна.

По моему раздел медленно переходит от темы исследования мнения народа о статье к исследованию мнения народа о авторе оной. Может мирно закрыть тему ?
А то, как говорил один мой знакомый ныне покойник - самый плохой мир лучше самой хорошей войны. )

Это я не о России, я о Вас.
Ну а насчет Росcии - серьезной страной был CCCP. После развала (к моему искреннему сожалению) которого руками Российского Руководства, моя страна оказалась на задворках Европы а Ваша на задворках Азии. Это единственная "разница" :-(. В России-Европе-Азии я часто живу и работаю
и могу судить о создавшейся ситуации и отношению к обломкам СССР самостоятельно.



Скорее наоборот - к неудержимиму выражению мнения Автора о народе :-), что впрочем, тоже приводит к мыслям о закрытии темы....

А там, в том виде как оно есть - всё несуразность, начиная с самой необходимости такой статьи...





... такого стиля, когда о-о-о-чень частность подаётся как откровение - не нужны.





Пожалуй что - да, хотя некоторые детали могли бы быть любопытными ... если бы это было "обсуждение" ...

" Я написал ОС РВ. Все свободны. Обсуждение. " (с)

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

По-моему надо писать в котексте того, что есть некоторая область применения (узкая!), в которой оптимальной/удобной/оправданной является диспетчеризация по принципу Round Robin, упора на реальном времени такого сильного как сейчас лучше не делать. В том контексте, в котором подан материал слишком большие претензии, которые вызывают немеренно вопросов. Если будете публиковать в существующем виде - готовьтесь к куче вопросов от читателей. рекомендую прочесть что-нибудь по ОСРВ, хотя бы первые главы того же Лабросса (ежели надо - пишите, пришлю на русском).

...Кстати задача непрерывности звука нормальным образом решается засчет буферизации самым классическим образом с двумя буферами.

А дисциплину Round-Robin наряду с вытесняющей многозадачностью предлагает FreeRTOS. Рекомендую взглянуть.

С уважением, Андрей Слабнов.

P.S. Чиста на всякий случай. Я не студент, не бачелор, а магистр с красным дипломом, кандидатскую к сожалению не защитил по личным причинам. Опыт серьезного коммерческого программирования (в основном Embedded) 9 лет, из них последние 5 лет в том числе и DSP, простенькие правда 16-битки от AD. И тоже в двух вузах преподаю... Курсы, которые я читаю называются "Программное обеспечение измерительных процессов" и "Системы реального времени".

Не знаю как прочим , а мне бы надо...
Только сколько там объёму?



URL ?

P.S. А вы вот такую позицию не смотрели? :
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- может в чём-то и там покажется "рациональное зерно"?