Народ, что думаешь про эту писанину? В принципе, это статья :) Опции

[st256]

В настоящее время при создании систем цифровой обработки сигналов широко используется понятие «Операционная Система Реального Времени» или 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 для задач Цифровой Обработки Сигнала. Описаны программные модули, на которых она строиться и их принцип функционирования. Определена формальная структура задачи и сделан практически важный для аппаратной части вывод, о возможности использования в системе только одного прерывания (от таймера) и отказа от приоритетов.

[_artem_]

не судите строго , по моему вы своими словами описали то что уже давно сушествует , может и не все вместе не по большому счету это уже есть .
Распределение выполнения задач в соответствии с тиками (слотами для каждой задачи) называется у буржуев - round robin algorithm. Буферные API тоже есть, флаг - mutex ...

Кстати если вы планируете для реального времени round robin - то он не очень то и хорош потому что момент переключения задачи не контролируется програмистом.

[Andy Mozzhevilov]

не судите строго , по моему вы своими словами описали то что уже давно сушествует , может и не все вместе не по большому счету это уже есть .
Распределение выполнения задач в соответствии с тиками (слотами для каждой задачи) называется у буржуев - round robin algorithm. Буферные API тоже есть, флаг - mutex ...

Кстати если вы планируете для реального времени round robin - то он не очень то и хорош потому что момент переключения задачи не контролируется програмистом.

В общем согласен, не совсем понятно, как в такой системе реагировать на асинхронные события.
Тут либо процессор должен быть настолько быстрым, что бы его длительность тика заведо была бы меньше необходимого времени реакции на любое аснихронное событие, либо опять же придется вводить вне-осевые прерывания, которые такие события будут подхватывать, делать первичную обработку, а затем уже будут подхвачены ОС на уровне тиков, что уже противоречит утверждению об использзовании в системе прерываний только от одного таймера.

Сообщение отредактировал Andy Mozzhevilov - Feb 20 2006, 04:27

[st256]

не судите строго , по моему вы своими словами описали то что уже давно сушествует , может и не все вместе не по большому счету это уже есть .
Распределение выполнения задач в соответствии с тиками (слотами для каждой задачи) называется у буржуев - round robin algorithm. Буферные API тоже есть, флаг - mutex ...

Естественно, что многое уже есть. Но для меня интересно положение об отсутствии прерываний (точнее замена прерываний на полинг) и отсутствие приоритетов.

Кстати если вы планируете для реального времени round robin - то он не очень то и хорош потому что момент переключения задачи не контролируется програмистом.

А зачем его контролировать?

Вообще-то, это разрабатывалось, для систем, допустим, аудиообработки. Когда, у вас есть куча потоковых задач типа МР3 и могут быть еще спорадически возникающие, типа файдинга или отработки перестройки эквалайзера.

не судите строго , по моему вы своими словами описали то что уже давно сушествует , может и не все вместе не по большому счету это уже есть .
Распределение выполнения задач в соответствии с тиками (слотами для каждой задачи) называется у буржуев - round robin algorithm. Буферные API тоже есть, флаг - mutex ...

Кстати если вы планируете для реального времени round robin - то он не очень то и хорош потому что момент переключения задачи не контролируется програмистом.

В общем согласен, не совсем понятно, как в такой системе реагировать на асинхронные события.
Тут либо процессор должен быть настолько быстрым, что бы его длительность тика заведо была бы меньше необходимого времени реакции на любое аснихронное событие, либо опять же придется вводить вне-осевые прерывания, которые такие события будут подхватывать, делать первичную обработку, а затем уже будут подхвачены ОС на уровне тиков, что уже противоречит утверждению об использзовании в системе прерываний только от одного таймера.

Это не универсальная система, а такая узкоспециализированная. Естественно, время тика должно быть меньше времени реакции системы. Кстати, подобную систему моей разработки сравнивали с микроСи. МикроСи даже близко не лежала по времени реакции

[Andy Mozzhevilov]

Это не универсальная система, а такая узкоспециализированная. Естественно, время тика должно быть меньше времени реакции системы. Кстати, подобную систему моей разработки сравнивали с микроСи. МикроСи даже близко не лежала по времени реакции

Тогда во вступлении нужно четко оговорить круг применяемости такого подхода, дабы не возникало лишних вопросов. Но по моему опыту работы (хотя с DSP-процессорами я не работал практически, лишь реализовал некоторые DSP-шные алгоритмы на ARM), система, как правило, нуждается в 1-2 детерменированных по времени реакции процессах. Для остальных процессов время реакции зачастую уже не имеет значения в разумных границах. А в таких случаях более оптимально время процессора распределяется как раз в вытесняющих ОС.

[Виктория]

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

Это не универсальная система, а такая узкоспециализированная. Естественно, время тика должно быть меньше времени реакции системы.

Легкое противоречие...
Если краткое резюме - RTOS я бы не стала это называть. А так все нормально, проблемно-ориентированное ПО. Вопрос то в чем? Оценка хорошего проекта? Найти и определить область применимости?

[Olej]

В настоящее время при создании систем цифровой обработки сигналов широко используется понятие «Операционная Система Реального Времени» или RTOS (Real Time Operating System).

Во-первых, RTOS - термин намного шире, чем "создании систем цифровой обработки сигналов" - много чести будет - для отдельной прикладной области городить столь сложное изделие как RTOS...
Во-вторых, само "реальное время" - во многом спекулятивный и спорный термин, вот хоть здесь см.:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- и требовал бы намного более строгого использования, чтобы использоваться именно как термин, а не только для солидности изложения .

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

Последнее следствие неочевидно, ...

Последнее следствие не только не очевидно, но, как на мой взгляд - и глубоко ошибочно...
Для анализа фиксированных deadline-ов параллельно выполняющихся задач - есть, по крайней мере, немного строгих математических моделей анализа и предсказания поведения:
http://qnxclub.net/files/articles/rta/rta.doc
http://qnxclub.net/files/articles/rms/rms.doc
- и все они строятся в предположении наличия в исполняющей системе большого числа уровней приоритетов... а без этого так и не придумали формальных математических технологий анализа, и всё становится на уровне умозрительных "доказательств": "... а мне кажется что здесь мы укладываемся в критический интервал..." - " ... а мне так не кажется..."
И то же самое (рост числа уровней приоритетов) наблюдается в реально используемых RTOS: VxWorks - 256 уровней, QNX 6.2.1 - 64 -> QNX 6.3 - 256 - на лицо миграция к большему числу...
Но уж, по-крайней мере, если если уж утверждать нечто, противоречащее общей в мире практике на протяжении 10-20 лет принятой - то это что-то нужно уж о-о-о-очень сильно доказывать...

Когда одна задача прерывает другую? Когда ресурсов системы не хватает на обе задачи одновременно. Т.е. прерывание задачи приведет к тому, что прерванная задача не успеет обработать данные (пройти реперную точку) за оговоренное время.

Совсем не так! - это только 1 из многих частных случаев... Задача может прерывать другую - когда для неё наступит асинхронное событие, которого она молча, может быть, 3 часа ожидала - это классика всех сетевых обменов... Или задача может прерывать другую, когда для неё сработают взведенные ею таймерные процедуры - а это целая область специальных техник в RT-программировании (таймеры и всё с ними связанное)...

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

Всё это умозрительно, "на пальцах" и ... не убеждает.

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

Это, как уже отмечали - описана одна из возможных дисциплин диспетчирования: round-robin - но этого мало для всего множества реальных задач, см. ещё дисциплины: fifo, адаптивная, спорадическая (это - особенно)...

3. Важной частью RTOS являются драйвера. По причинам, изложенным ниже, драйвера должны запускаться также каждый тик.

Драйверы, вообще-то, являются достаточно важной частью любой OS, не только RT...
Но только в RTOS с хорошо продуманной и проработанной архитектурой (кто понимает о чём это я - догадывается : микроядерной) - так драйверы могут выполняться как "ещё один рядовой пользовательский процесс" - так что о них и говорить отдельно нужды нет...

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

- это описание, может и достаточно адекватное, но одного очень частного класса задач: digital signal processing... Но не нужно применительно к частному классу оперировать терминами RTOS etc. - можно нарваться на очень серьёзные возражения, только потому, что область RTOS намного-намного шире... Тогда и говорить о чём-то таком "исполняющая система (планировщик) потоковой сигнальной обработки"...

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

Именно API, и, желательно, стандартный, и для всего этого - уже давно есть такой стандарт API: POSIX 1003b - расширения реального времени...

P.S. Если у вас будет возможность - посмотрите вот это:
http://www.books.ru/shop/books/357604

[Виктория]

Olej, Вам респект !
за то, что все так разложили по полочкам .
Тема вообще то интересная даже и в таком ключе

"исполняющая система потоковой сигнальной обработки"...

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

[Arch_Grey]

Действительно, автор статьи пытался рассмотреть очень узкую задачу - чистая ЦОС РВ, т.е. имеются только задачи обработки данных, которые, естественно, должны обработать данные одного отсчета до начала следующего. В таком случае все задачи должны успеть отработать в течение одного фрейма. Тут действительно не до приоритетов. Но в реальной работе кроме ЦОС требуются мониторинг, статистика, диагностика и т.д. и т.п. - т.е. куча других задач.
И вот тогда высказывание :

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

в общем случае является неверным, поскольку основным ресурсом для задач на самом деле является время их обраработки процессором.

[dxp]

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

Ну, это как посмотреть. Вот, к примеру, если процессор задействован на обработке не одного потока данных, а у него таких потоков эн (при условии, разумеется, что успевает их обрабатывать с некоторым запасом) и они (потоки данных) еще и имеют разные скорости, источники и приоритеты (а кроме этого еще есть всякого другого служебного хозяйства и других задач, помимо ЦОС), то RTOS тут может оказаться очень кстати. Естественно, что накладные расходы на RTOS должны быть адекватными возможностям процессора и задаче, поэтому крутые и толстые ОС, сделанные по всем правилам, тут не рулят. А вот какая-нить uC/OS-II или ThreadX (и их калибра) могут вполне себе неплохо решать задачу.

Вообще, в embedded (на МК, коим вполне может быть и DSP ), где система и программа зачастую составляют единое целое, процесс разработки программы и использования (при этом) RTOS весьма отличается от писания приложений под [RT]OS, когда система о приложении ничего не знает, а только лишь предоставляет правила и сервисы. При рассуждениях этот момент, имхо, упускать нельзя - он очень значим.

[st256]

Тогда во вступлении нужно четко оговорить круг применяемости такого подхода, дабы не возникало лишних вопросов. Но по моему опыту работы (хотя с DSP-процессорами я не работал практически, лишь реализовал некоторые DSP-шные алгоритмы на ARM), система, как правило, нуждается в 1-2 детерменированных по времени реакции процессах. Для остальных процессов время реакции зачастую уже не имеет значения в разумных границах. А в таких случаях более оптимально время процессора распределяется как раз в вытесняющих ОС.

Представьте себе такую систему (Вы с ней сталкиваетесь очень часто). Сигнальный процессор. На нем реализованы следующие функции:
- МР3
- эквалайзер, стерео на 5 полос в каждом канале.
- 3D-sound
- басс-бустер (не знаю как по русски)
- плавная регулировка громкости (страшно пакостная вещь из-за мощного канала управления)
- передискретизатор из 44.1кГц в 96кГц

И кто тут кого должен вытеснять?

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

Это не универсальная система, а такая узкоспециализированная. Естественно, время тика должно быть меньше времени реакции системы.

Легкое противоречие...

Пока не понял в чем именно.

Если краткое резюме - RTOS я бы не стала это называть. А так все нормально, проблемно-ориентированное ПО. Вопрос то в чем? Оценка хорошего проекта? Найти и определить область применимости?

Ну назовите планировщик... Хотя МикроСи называют все-таки RTOS. Вопрос в том, чтобы не печетать совсем уж явные ляпы. Всплывают они именно при подобных обсуждениях. А применяют этот софт в уже разных странах

[BVU]

А какая позразумевается структура (иерархия) на запросы аппарантой и программной частей? Если будет как оговаривается: "ограничение времени отклика на любой запрос, как со стороны аппаратной части, так и со стороны исполняемых программных модулей" - т.е. если они будут равноценными, то получиться - полный бедлам! И грош цена такой RTOS.

[st256]

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

Последнее следствие неочевидно, ...

Последнее следствие не только не очевидно, но, как на мой взгляд - и глубоко ошибочно...

Приведите пример, когда нужно использовать в реал-тайме вытеснение. Все остальное - лишнее.

Когда одна задача прерывает другую? Когда ресурсов системы не хватает на обе задачи одновременно. Т.е. прерывание задачи приведет к тому, что прерванная задача не успеет обработать данные (пройти реперную точку) за оговоренное время.

Совсем не так! - это только 1 из многих частных случаев... Задача может прерывать другую - когда для неё наступит асинхронное событие, которого она молча, может быть, 3 часа ожидала - это классика всех сетевых обменов...

Пример не корректен, во-первых TCP/IP не реал-тайм уже по определению.
Во-вторых, я бы попросил объяснить мне, кто и кого должен прервать, если в плеере, Вы начали дергать эквалайзер, а это означает, что запустилась задача пересчета коэффициентов.
И так, кто кого дожен прервать, чтобы звук не прервался?

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

Всё это умозрительно, "на пальцах" и ... не убеждает.

Убедите меня тогда Вы. Приведите пример, когда есть необходимость прерывания в отсутствиии конкуренции за рессурсы.

3. Важной частью RTOS являются драйвера. По причинам, изложенным ниже, драйвера должны запускаться также каждый тик.

Драйверы, вообще-то, являются достаточно важной частью любой OS, не только RT...
Но только в RTOS с хорошо продуманной и проработанной архитектурой (кто понимает о чём это я - догадывается : микроядерной) - так драйверы могут выполняться как "ещё один рядовой пользовательский процесс" - так что о них и говорить отдельно нужды нет...

А если не получается их оформить в процесс? Ну у Вас задача обработать буффер в 1024 слова. Эта задача выполняется 5 мс, а данные прут со скоростью одно слово зо 5мкс. Как не потерять данные во время выполнения задачи, если ее прерывать нельзя?

Действительно, автор статьи пытался рассмотреть очень узкую задачу - чистая ЦОС РВ, т.е. имеются только задачи обработки данных, которые, естественно, должны обработать данные одного отсчета до начала следующего. В таком случае все задачи должны успеть отработать в течение одного фрейма. Тут действительно не до приоритетов. Но в реальной работе кроме ЦОС требуются мониторинг, статистика, диагностика и т.д. и т.п. - т.е. куча других задач.
И вот тогда высказывание :

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

в общем случае является неверным, поскольку основным ресурсом для задач на самом деле является время их обраработки процессором.

Ну и как они конкурируют? Зъим сколько смогу, а остальное покусаю? Нафиг, такие этнически ориетированные задачи...

А какая позразумевается структура (иерархия) на запросы аппарантой и программной частей? Если будет как оговаривается: "ограничение времени отклика на любой запрос, как со стороны аппаратной части, так и со стороны исполняемых программных модулей" - т.е. если они будут равноценными, то получиться - полный бедлам! И грош цена такой RTOS.

Не понял, Бедлам-то откуда возмется? Можете субсидировать Афтара примером?

[Olej]

Приведите пример, когда нужно использовать в реал-тайме вытеснение. Все остальное - лишнее.

Вот так сразу?
Так давайте сначала определитесь, что вообще такое "реал-тайм" ... поскольку ваша модель потоковой сигнальной обработки к риал-тайму то, вообще то говоря, отношения и не имеет ... А вот когда с моделью самой "реал-тайм" определитесь - тогда можно и о вытеснении и о примерах говорить...
Если у вас там 5, ну хоть 50 - неперерывных потоковых задач, и вы их RR-диспетчируете - то может вытеснений у вас и не возникать (вы бы ещё 1 поток RR диспетчировали, и сокрушались, что там вытеснять нечего )... но как только ваши 5 задач надумают взаимодействовать (синхронизации там и т.д. - Дэйкстра там, Хоар ... - слышали?) вот тут вашей "гребёнке" RR и ... "приехали": даже простейшие операции на семафоре потребуют перепланирования, а что это как не вытеснение?

Пример не корректен, во-первых TCP/IP не реал-тайм уже по определению.

Пример корректен - потому что вы просто не знаете TCP/IP "по определению" ... цитату покажите, где такое "по определению" написано?
Но я не говорил, кажется, о TCP/IP ... ни буквы ... а с MAC-уровнем как будем? он тоже "по определению"?...
Но это всё суть не принципиально важно: я вам указал, что все системы сетевые, обмена данными, поступление данных на RS-232 ... все они построены на асинхронных событиях, на которые нужно немедленно реагировать, и никакие синхронные процедуры диспетчирования - не решат вам проблемы реакции на асинхронные события.

Во-вторых, я бы попросил объяснить мне, кто и кого должен прервать, если в плеере, Вы начали дергать эквалайзер, а это означает, что запустилась задача пересчета коэффициентов.
И так, кто кого дожен прервать, чтобы звук не прервался?

- когда вы начали дёргать свой эквалайзер, то, в принципе, здесь вы никого можете и не прерывать (как вы может быть предполагали )...
- но вот когда вы этой задачей пересчитаете свои коэффициенты и попробуете их "вписать" задаче потоковой обработки "чтобы звук не прервался" - вот так "на ходу", без синхронизации и перепланирования задач...
- ... нет, если это у тинэйджера плеер на шее - то вы можете и "на ходу" поменять коэффициенты;
- а вот если у меня это система управления движением, или управления полётом - то лучше так не делать... "не ровён час"...

Убедите меня тогда Вы. Приведите пример, когда есть необходимость прерывания в отсутствиии конкуренции за рессурсы.

Вы что ресурсами называете? только процессорные циклы? а если видов ресурсов у вас намного больше, тогда как? Кому нужно ОС вообще, если потоки не конкурируют за ресурсы?

А если не получается их оформить в процесс? Ну у Вас задача обработать буффер в 1024 слова. Эта задача выполняется 5 мс, а данные прут со скоростью одно слово зо 5мкс. Как не потерять данные во время выполнения задачи, если ее прерывать нельзя?

Я вам о том, что в QNX умудряются все драйверы (а их там мно-о-о-го устройств, не только плеера ) представлять как пользовательские процессы - а вы мне про 1024 слова которые нельзя прерывать .

[v_shamaev]

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

Последнее следствие неочевидно, ...

Последнее следствие не только не очевидно, но, как на мой взгляд - и глубоко ошибочно...

Приведите пример, когда нужно использовать в реал-тайме вытеснение. Все остальное - лишнее.

Это что - для реал-тайм задач - один процессор, а для всех остальных - другой?
Сбор данных - реал тайм, а вывод в гуях на экран - совсем наоборот. И ради чистоты идеи - дополнительный процессор ставить?

[st256]

Вот так сразу?
Так давайте сначала определитесь, что вообще такое "реал-тайм" ... поскольку ваша модель потоковой сигнальной обработки к риал-тайму то, вообще то говоря, отношения и не имеет ...

Мда... Теперь ясно...

Пример не корректен, во-первых TCP/IP не реал-тайм уже по определению.

Пример корректен - потому что вы просто не знаете TCP/IP "по определению"

Базара нет. Я не знаю TCP/IP, а Вы не знаете, что он не реал-тайм...
Ну давайте на этом и разойдемся.

Сообщение отредактировал st256 - Feb 21 2006, 13:28

[Виктория]

st256, Вам вроде и нужна была критика

Вот эта мысль тоже хорошая:

исполняющая система (планировщик) потоковой сигнальной обработки

Или исполнительный монитор ЦОС. А средства поддержки проектирования есть (2 альтернативы: в ОС - библиотеки системных функций, в ЯВУ или case-системах - само описание уникально). Даже макросы и то инструмент.

Сообщение отредактировал Vic1 - Feb 21 2006, 13:58

[st256]

st256, Вам вроде и нужна была критика

Вот эта мысль тоже хорошая:

исполняющая система (планировщик) потоковой сигнальной обработки

Или исполнительный монитор ЦОС. А средства поддержки проектирования есть (2 альтернативы: в ОС - библиотеки системных функций, в ЯВУ или case-системах - само описание уникально). Даже макросы и то инструмент.

Понимаете, леди, критика хороша когда она идет из хорошего источника. А когда человек знает ноль, то и энтропия его постов (мат. ожидание количества информации) - тоже ноль. Есть моменты, которые я не понимаю. Например, я не понял Вашего поста. Ну просто не понял. Без второго дна, как говориться. Тогда я пытаюсь разобраться или хотя бы понять, что мне тут не надо разбираться, не мой профиль, не моя компетенция. Но объяснять неучу, что TCP/IP не реал-тайм, простите, не стану. Потом ему придется объяснять правила сложения и конца этому не будет.

На счет ЖАБЫ или CASE.... Ну это точно не ко мне. У меня конвейер, у меня суперскаляр, у меня страшные ограничения на память, я даже не могу позволить писать себе на Си...

Такая тяжелая судьба у специалистов по Цифровой Обработке Сигналов. Потому нас так мало

[Olej]

Тогда я пытаюсь разобраться или хотя бы понять, что мне тут не надо разбираться, не мой профиль, не моя компетенция. Но объяснять неучу, что TCP/IP не реал-тайм, простите, не стану. Потом ему придется объяснять правила сложения и конца этому не будет.

Ну, вы пока можете попытаться объяснить, в меру понимания, хоть то, что есть профиль - что такое риал-тайм... А там и я, может быть, объясню, почему и TCP/IP даже, при определённых условиях - может быть компонентом очень даже hard realtime системы ...

Такая тяжелая судьба у специалистов по Цифровой Обработке Сигналов. Потому нас так мало

Это что? : "сам себя с утра не похвалишь - весь день как оплёванный ходишь?"
А кто вам сказал, что вы "волшебник"? Вы - только учитесь (с)

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

[TMX]

По-моему, автор дал описание архитектуры "cyclic executive".
Которая обеспечивает жесткое РВ для выделенного круга задач.
Не понимаю, правда, причем тут ОС.
Т.е. неясно, зачем сохранять и восстанавливать контекст, если задачи и драйверы не вытесняют друг друга...
Противоречие какое-то.

[Виктория]

st256, спасибо за леди (а то как уж тут только не обижала молодежь зеленая).
Вообще то, лучше Olej критику Вам никто и не скажет. Для того, чтобы заявлять "Я написал RTOS" нужно по минимуму хоть архитектуру операционных систем знать. Ответы в форуме - короткие по форме (доброжелательные по содержанию), не рецензию же Вам на статью писать. Умейте читать между строк, уточняйте, если кажется, что Вас не понимают. А разводить базар, как Вы говорите, на пустом месте - пользы для Вас точно не будет (желания беседовать/критиковать пропадет). Уж лучше тогда с Olej побеседовать на более захватывающие темы (место ОС в мире Embedded: когда есть необходимость в ОС, а когда нет; ОС - это не только (наверно и не столько) real time, сколько концепция ввода/вывода, модульность, многопроцессность и т.п.; какую дополнительную технологичность представляет ОС разработчику).
У Вас, повторюсь, проблемно-ориентированное ПО (под определенную задачу). Для того, чтобы понять эту задачу, Вам и задают вопросы.

[fontp]

Приведите пример, когда нужно использовать в реал-тайме вытеснение. Все остальное - лишнее.

Вот так сразу?
Так давайте сначала определитесь, что вообще такое "реал-тайм" ... поскольку ваша модель потоковой сигнальной обработки к риал-тайму то, вообще то говоря, отношения и не имеет ... А вот когда с моделью самой "реал-тайм" определитесь - тогда можно и о вытеснении и о примерах говорить...

Olej Иванович, не горячись. 256-ой известный корейский провокатор. Бывший с Самсунга . Но специалист он грамотный. Только зря он заговорил про RTOS. То что он описывает всегда называлось framework.

Попробую объяснить, что в DSP считают real-time, чтобы вернуть дискуссию в конструктивное русло.
Реальное ВРЕМЯ в отличии от физической абстракции как известно не однородно. Оно имеет абсолютное начало координат (настоящее) и однородную ось повёрнутую в прошлое. Будущего строго говоря не существует. Компьютеры используют для сбора информации её обработки и использования в корыстных целях. Информация представляется в виде функций. Если эти функции не зависят от времени - то нет никакого совсем смысла говорить про real-time. Но даже если они есть функции времени (т.е. представлены дискретными парами (value, time-stamp) то говорить о real-time в большинстве случаев, когда о нём говорят, нет смысла. Смысл говорить о жёстком реале есть только тогда когда для решаемой задачи значения меток времени time-stamp имеют абсолютное, но не относительное значение, т.е. начало координат нельзя сдвинуть по смыслу задачи. Вернее его можно сдвинуть только в пределах незначительных допустимых deadline обработки. Запаздывание обработки позже dead-line делает саму обработку бессмысленной, это программа лузер и её лучше было бы вообще никогда не запускать и не писать. Синхронность или асинхронность не является признаком real-time, признаком real-time является существование дэдлайнов в течении которого обработка должна быть выполнена. Поэтому система реального времени должна характеризоваться максимальными, а не средними временами отклика. Поэтому возможность вытеснения для таких задач действительно существенно ограничены.

Исторически термин обработки реального времени появился из обслуживания периферийных устройств, портов и прочего железа, которое может ожидать обслуживания только в пределах ограниченого времени. Но если изолировать железо слоем драйверов/обработчиков прерываний, то выяснится, что почти все коммуникационные задачи считаются задачами реального времени по недоразумению. В формулировке задачи передачи данных абсолютное время (дэдлайны) не входит никоим образом. От данных требуется только поступать последовательно. Поэтому строго говоря ни факс, ни передача данных по TCP/IP не являются задачами реального времени (можно буферизировать как угодно, и достаточно гарантировать среднее, а не максимальное время реакции системы). Обработка звука является очевидно задачей реального времени, поскольку абсолютное время есть координата сигнала и отсчёты должны быть обработаны и доставлены за время ограниченых временных дэдлайнов. Нарушение дэдлайнов приводит к такой ситуации, когда передачу лучше было бы не начинать - ведь поезд уже ушёл.

Передача речи UDP-дэйтаграммами, конечно, уже есть задача реального времени. А передача файлов - наоборот нет.

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

Большинство если не все знаменитые коммерческие РТОС (WxWorks, pSOS) в действительности не гарантируют максимальное время реакции, обеспечивая только среднее (во всяком случае в масштабе мсек или даже десятков мсек), поэтому настоящие универсальные РТОС так не популярны в мире DSP. Хотя если говорить о таких гарантиях - то их может обеспечивать только программно-аппаратный комплекс, но никак не универсальная РТОС самостоятельно.

Сообщение отредактировал fontp - Feb 22 2006, 08:53

[st256]

По-моему, автор дал описание архитектуры "cyclic executive".
Которая обеспечивает жесткое РВ для выделенного круга задач.
Не понимаю, правда, причем тут ОС.
Т.е. неясно, зачем сохранять и восстанавливать контекст, если задачи и драйверы не вытесняют друг друга...
Противоречие какое-то.

Представьте, что на время выполнения каждой задачи отводится фиксированный фрейм, а выполняется задача гораздо дольше. В следующем фрейме будет выполняться уже другая задача. Т.е. необходимо сохранить/восстановить, регистры и т.д.

Тогда я пытаюсь разобраться или хотя бы понять, что мне тут не надо разбираться, не мой профиль, не моя компетенция. Но объяснять неучу, что TCP/IP не реал-тайм, простите, не стану. Потом ему придется объяснять правила сложения и конца этому не будет.

Ну, вы пока можете попытаться объяснить, в меру понимания, хоть то, что есть профиль - что такое риал-тайм...

Да фиг его знает, что это такое... Вроде - фрукты...

А там и я, может быть, объясню, почему и TCP/IP даже, при определённых условиях - может быть компонентом очень даже hard realtime системы ...

Не утруждайте себя. Я уже понял, что это тот самый реал-тайм и есть, собственной персоной...

[Olej]

Olej Иванович, не горячись.

Да я и не горячусь - меня просто в заблуждение ввело название темы: "Народ, что думаешь...". Но если обсудить - то обсудить, а если ... "губки надувать" будем - так это о другом совсем...

Поэтому строго говоря ни факс, ни передача данных по TCP/IP не являются задачами реального времени (можно буферизировать как угодно, и достаточно гарантировать среднее, а не максимальное время реакции системы). Обработка звука является очевидно задачей реального времени, поскольку абсолютное время есть координата сигнала и отсчёты должны быть обработаны и доставлены за время ограниченых временных дэдлайнов. Нарушение дэдлайнов приводит к такой ситуации, когда передачу лучше было бы не начинать - ведь поезд уже ушёл.

Передача речи UDP-дэйтаграммами, конечно, уже есть задача реального времени. А передача файлов - наоборот нет.

Вот я о том же и говорил: "... почему и TCP/IP даже, при определённых условиях ...". Только не нужно так сужать к конкретностям: а что, если поток поступает не в UDP-дэйтаграммах, а через TCP-поток, или вообще совершенно другим протоколом ... или если это не передача речи, а поток радиолокационного скана - то от этого что-то меняется? И как только появляется асинхронный поток внешних событий - то же поступление блоков данных - и синхронным полингом round-robin, по крайней мере без развитого API примитивов взаимной синхронизации (что тоже всегда "вытеснение") N задач - не обойтись. А что касаемо "одноприоритетности"? ... то почти всегда и в исполняющей системе, допускающей множество приоритетов - можно реализовать и одноприоритетное построение (просто не использовать), и часто такие решения оказываются особенно "красивыми" (кстати, Дейкстра свои "взаимодействия последовательных процессов", откуда всё и пошло - всегда описывал в безприоритетной абстракции), но ... роль и разнообразие примитивов синхронизации и изощрённость (или тщательность?) их использования - намного возрастает. И такая реализация уже становится ближе к области "искусства", но и гарантия обеспечения deadline-ов в любых стечениях обстоятельств - относится на совесть "художника". А в том же Частотном Монотонном Анализе (одна из моделей, которые я упоминал), обязательным условием реализации которого является: "для каждой параллельной ветки - свой уровень приоритета, отличный от всех других" - гарантия обеспечивается (и доказывается!) строгой математической моделью.

[st256]

st256, спасибо за леди (а то как уж тут только не обижала молодежь зеленая).

Не, тут такое дело, я только с леди разговариваю. А если она не леди, то я с ней не общаюсь. Незачем.

Вообще то, лучше Olej критику Вам никто и не скажет.

Да уж...

Для того, чтобы заявлять "Я написал RTOS" нужно по минимуму хоть архитектуру операционных систем знать.

Поэтому, я не заявляю, а тихо пишу. Прям щас. А архитектуры, которые я знаю (правда я мало их знаю), для DSP очень неудачные. Вы думаете, я сам такие вещи делаю от неимения, чем заняться? Увы, это не так... Просто, сравнительный анализ портов чужих RTOS приводит меня в депрессию. А работу надо сдавать в любом случае....

Хотя между собой, то, что я описал мы зовем scheduler (планировщик). RTOS это исключительно для яркости оперения.

Ответы в форуме - короткие по форме (доброжелательные по содержанию),

Дык пока я перед всеми расшаркиваться буду, меня подпишут на бесплатное преподавание DSP. Я этим и так в двух ВУЗах занимаюсь... А так: сказал, что TCP/IP - реал тайм, и сразу свободен.

не рецензию же Вам на статью писать. Умейте читать между строк, уточняйте, если кажется, что Вас не понимают. А разводить базар, как Вы говорите, на пустом месте - пользы для Вас точно не будет (желания беседовать/критиковать пропадет). Уж лучше тогда с Olej побеседовать на более захватывающие темы (место ОС в мире Embedded: когда есть необходимость в ОС, а когда нет; ОС - это не только (наверно и не столько) real time, сколько концепция ввода/вывода, модульность, многопроцессность и т.п.; какую дополнительную технологичность представляет ОС разработчику).
У Вас, повторюсь, проблемно-ориентированное ПО (под определенную задачу). Для того, чтобы понять эту задачу, Вам и задают вопросы.

Я просто экономлю свое время. Зачем мне говорить про ввод/вывод, модульность и многопроцессность (и даже многопроцессорность), если про это я знаю (из-за специфики работы) и так совсем неплохо?

[st256]

[quote name='fontp' date='Feb 22 2006, 17:47' post='89265']
Olej Иванович, не горячись. 256-ой известный корейский провокатор. Бывший с Самсунга . Но специалист он грамотный. Только зря он заговорил про RTOS. То что он описывает всегда называлось framework.
[/qoute]

Ув. г-н Фунт... т.е.Фонт... в смысле fontp!

Во-первых, я никогда не работал в Самсунге, т.е. Вы обманываете.
Во-вторых, то про что я заговорил framework-ом никак быть не может. Что это такое, рекомендую узнать в словаре, или на худой конец в ближайшем офисе Майкрософт, где Вы получите первичные сведения о MFC т.е. Вы обманываете вторично.
В-третьих... Т.к. Вы обманули дважды, то, сами понимаете, вероятность того, что Вы надули аудиторию, называя меня провокатором, очень высока. И тогда с Ваших слов получается, если провокатор один из нас, то это именно Вы.
В-четвертых. Ничего не имею против Вашего понимания Real-Time.

[fontp]

Ув. г-н Фунт... т.е.Фонт... в смысле fontp!

Во-первых, я никогда не работал в Самсунге, т.е. Вы обманываете.
Во-вторых, то про что я заговорил framework-ом никак быть не может. Что это такое, рекомендую узнать в словаре, или на худой конец в ближайшем офисе Майкрософт, где Вы получите первичные сведения о MFC т.е. Вы обманываете вторично.
В-третьих... Т.к. Вы обманули дважды, то, сами понимаете, вероятность того, что Вы надули аудиторию, называя меня провокатором, очень высока. И тогда с Ваших слов получается, если провокатор один из нас, то это именно Вы.
В-четвертых. Ничего не имею против Вашего понимания Real-Time.

Сами Вы Фунт

А что такое Майкрософт? У нормальных людей scheduler есть часть framework.
Или теперь TI и AD называют ЭТО Real-Time Kernel (DSP/BIOS и VDK, соответственно).
Кстати на них отлично строится одноприоритетная система. Но они не имеют такой
наглости называть ЭТО RTOS

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

[st256]

Вот я о том же и говорил: "... почему и TCP/IP даже, при определённых условиях ...". Только не нужно так сужать к конкретностям: а что, если поток поступает не в UDP-дэйтаграммах, а через TCP-поток, или вообще совершенно другим протоколом ... или если это не передача речи, а поток радиолокационного скана - то от этого что-то меняется? И как только появляется асинхронный поток внешних событий - то же поступление блоков данных - и синхронным полингом round-robin, по крайней мере без развитого API примитивов взаимной синхронизации (что тоже всегда "вытеснение") N задач - не обойтись.

Что такое реал тайм? Вообще-то это очень просто. Пусть у Вас на проце одновременно работают МР3 и эквалайзер. Теперь представте, что кто-то перестроил эквалайзер. Т.е. была запущена (параллельно проигрыванию трека) задача пересчета коэффициентов. Так вот система Real-Time только тогда если Вы гарантируете, что звук НИКОГДА не будет прерываться (из-за загрузки проца пересчетом, это очень вероятно). Если гарантируете ( а не говорите, что этого не случится с вероятностью 90%) то сее - real-time. Не можете гарантировать? Ну тогда и TCP/IP можно назвать реалтайм... Только заказчики Вас, боюсь, поймут превратно. Примерно как я.
Кстати, забудьте про "развитый API примитивов взаимной синхронизации". Я ограничился только одним флагом (0 или 1). Все прекрасно работало.

А что касаемо "одноприоритетности"? ... то почти всегда и в исполняющей системе, допускающей множество приоритетов - можно реализовать и одноприоритетное построение

Попробуйте это сделать в uCOS

(просто не использовать), и часто такие решения оказываются особенно "красивыми" (кстати, Дейкстра свои "взаимодействия последовательных процессов", откуда всё и пошло - всегда описывал в безприоритетной абстракции), но ... роль и разнообразие примитивов синхронизации и изощрённость (или тщательность?) их использования - намного возрастает.
И такая реализация уже становится ближе к области "искусства", но и гарантия обеспечения deadline-ов в любых стечениях обстоятельств - относится на совесть "художника". А в том же Частотном Монотонном Анализе (одна из моделей, которые я упоминал), обязательным условием реализации которого является: "для каждой параллельной ветки - свой уровень приоритета, отличный от всех других" - гарантия обеспечивается (и доказывается!) строгой математической моделью.

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

[zltigo]

После этого, разработчик выкидывает мудрые книжки, написанные людями, далекими от DSP, RTOS, Real-Time и начинает потихоньку кропать на асме.

Вы ошибаетесь. Жестоко. Могу только пожелать со временем понять это с минимальными последствиямми для Вашей собственной шкуры.

[st256]

Ув. г-н Фунт... т.е.Фонт... в смысле fontp!

Во-первых, я никогда не работал в Самсунге, т.е. Вы обманываете.
Во-вторых, то про что я заговорил framework-ом никак быть не может. Что это такое, рекомендую узнать в словаре, или на худой конец в ближайшем офисе Майкрософт, где Вы получите первичные сведения о MFC т.е. Вы обманываете вторично.
В-третьих... Т.к. Вы обманули дважды, то, сами понимаете, вероятность того, что Вы надули аудиторию, называя меня провокатором, очень высока. И тогда с Ваших слов получается, если провокатор один из нас, то это именно Вы.
В-четвертых. Ничего не имею против Вашего понимания Real-Time.

Сами Вы Фунт

Нет, я - st256. Это у меня в паспорте записано. Техническом.

А что такое Майкрософт?

Не скажу. А Вы будете теперь мучиться любопытством. Причем в конвульсиях.

У нормальных людей scheduler есть часть framework.

Значит Linux делали ненормальные люди. Я им передам Ваше мнение о них.

Или теперь TI и AD называют ЭТО Real-Time Kernel (DSP/BIOS и VDK, соответственно).
Кстати на них отлично строится одноприоритетная система. Но они не имеют такой
наглости называть ЭТО RTOS

ДА НУ??? Про AD не знаю, но TI прямо-таки надрывается в своих буклетах, говоря о некой навороченной RTOS. Но Вы им не верьте. Такую гнусь как DSP/BIOS не то, что операционной, а просто системой назвать нельзя. У меня при ее упоминании повышается психомоторика, слюноотделение и уровень желчи в организме. Со мой так нильзя. Меня так испортить можно...

[Виктория]

Но они не имеют такой называть ЭТО RTOS

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

2 st256
Во-первых,

на более захватывающие темы (место ОС в мире Embedded: когда есть необходимость в ОС, а когда нет; ОС - это не только (наверно и не столько) real time, сколько концепция ввода/вывода, модульность, многопроцессность и т.п.; какую дополнительную технологичность представляет ОС разработчику).

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

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

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

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

[st256]

После этого, разработчик выкидывает мудрые книжки, написанные людями, далекими от DSP, RTOS, Real-Time и начинает потихоньку кропать на асме.

Вы ошибаетесь. Жестоко. Могу только пожелать со временем понять это с минимальными последствиямми для Вашей собственной шкуры.

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

[zltigo]

Кстати, доводами Вы побрезговали... Стьюдент? Бачелор?

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

[fontp]

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

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

[Olej]

Что такое реал тайм? Вообще-то это очень просто. Пусть у Вас на проце одновременно работают МР3 и эквалайзер. Теперь представте, что кто-то перестроил эквалайзер. Т.е. была запущена (параллельно проигрыванию трека) задача пересчета коэффициентов. Так вот система Real-Time только тогда если Вы гарантируете, что звук НИКОГДА не будет прерываться (из-за загрузки проца пересчетом, это очень вероятно). Если гарантируете ( а не говорите, что этого не случится с вероятностью 90%) то сее - real-time.

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

Кстати, забудьте про "развитый API примитивов взаимной синхронизации". Я ограничился только одним флагом (0 или 1). Все прекрасно работало.

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

Попробуйте это сделать в uCOS

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

Вот отдельно пройдусь на счет "красоты". А Вы когда-нибудь видели дезассемблер реализации семафора? Или, на худой конец, обработчика прерываний?

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

После этого, разработчик выкидывает мудрые книжки, написанные людями, далекими от DSP, RTOS, Real-Time и начинает потихоньку кропать на асме.

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

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

[st256]

Но они не имеют такой называть ЭТО RTOS
Да, fontp наглости и самомнения тут в избытке!

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

2 st256

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

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

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

(или только правила свои указываете и неправильные определения)?

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

Зачем мне тогда эта фигня?

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

Чем она мне поможет в моих задачах ЦОС на сигнальных процессорах?

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

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

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

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

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

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

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

Если уж пишите "В принципе, это статья ", то хотя бы более грамотно смотрите на устоявшиеся термины.

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

[st256]

Кстати, доводами Вы побрезговали... Стьюдент? Бачелор?

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

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

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

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

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

[zltigo]

А есть ли доводы у человека, пытающегося рассуждать на DSP темы и проживающего в Риге?
Вот я Сигнальные Процессоры до недавнего времени разрабатывал....

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

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

[st256]

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

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

- принудительно остановить MP3, а не по наступлению time-slice ...
- занести весь массив целиком (или вы будете использовать в фильтре коэффициенты 1-7 из старого "комплекта", а 8-13 - из нового? )...
- и после этого опять принудительно (не по наступлению time-slice) снова активизировать задачу МР3...

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

Кстати, забудьте про "развитый API примитивов взаимной синхронизации". Я ограничился только одним флагом (0 или 1). Все прекрасно работало.

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

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

Попробуйте это сделать в uCOS

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

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

Вот отдельно пройдусь на счет "красоты". А Вы когда-нибудь видели дезассемблер реализации семафора? Или, на худой конец, обработчика прерываний?

Семафора или мютекса? - вы их различаете в лицо?

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

Видел, видел ... и обработчики прерываний ... более того, что обработчики могут быть идеологически принципиально разными (см. напр. InterruptAttachEvent QNX , который не совсем и обрабтчик, а ... перепланировщик ).

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

После этого, разработчик выкидывает мудрые книжки, написанные людями, далекими от DSP, RTOS, Real-Time и начинает потихоньку кропать на асме.

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

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

А есть ли доводы у человека, пытающегося рассуждать на DSP темы и проживающего в Риге?
Вот я Сигнальные Процессоры до недавнего времени разрабатывал....

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

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

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

[_artem_]

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

[zltigo]

И почему в прошлом? Вы не забывайте, я живу в России. А это сегодня уже очень серьезная страна.

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

По моему раздел медленно переходит от темы исследования мнения народа о статье к исследованию мнения народа о авторе оной. Может мирно закрыть тему ?

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

[Olej]

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

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

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

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

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

Может мирно закрыть тему ?

что впрочем, тоже приводит к мыслям о закрытии темы....

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

[fontp]

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

[slabnoff]

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

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

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

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

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

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

[Olej]

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

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

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

URL ?

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

[slabnoff]

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

В переводе: Введение+Главы 2-4 - 340 Кб в Зипе
Есть старая книжка на английском в doc-файлах (зато вся) - 840 Кб.

URL ?
www.freertos.org
Простая встраиваемая RTOS. Основные изюминки: можно использовать как вытесняющую так и кооперативную многозадачность при одинаковом API + есть Round Robin.

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

Вечером прочитаю, тогда подробно отвечу. Мельком пробежался - достаточно здравая статья, хотя философствования там хватает. С заключением статьи я не согласен - все таки RTOS я считаю систему обеспечивающую детерминированное время отклика на событие, а не "просто добротно спроектированную и отлаженную многозадачную ОС", хотя с другой стороны в ряде случаев вполне достаточно и оправдано просто применение системы с в среднем хорошим откликом.

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

[slabnoff]

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

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

P.S. Я занимаюсь в основном встраиваемыми ОСРВ (скорее даже просто диспетчерами задач), в то время как автор статьи их практически убрал из рассмотрения.

[Nixon]

Положил в \pub\doc\books\os\
Cheng A. Real-Time systems. Scheduling, analysis and verification.pdf
Беллетристика, но кое что интерестно.

[slabnoff]

Положил в \pub\doc\books\os\
Cheng A. Real-Time systems. Scheduling, analysis and verification.pdf
Беллетристика, но кое что интерестно.

Спасибо. Обязательно посмотрю.

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

[Боинг749]

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

Не верно.
Не за заданное время, в заданном временном коридоре.. Потому что существуют такие задачи, когда система не только должна "успевать" всё делать, но и должна НЕ "приходить на финиш" раньше некоторого заданного времени. Например представьте что будет если система управления дверями начнёт закрывать двери раньше чем Вы зайдёте в супермаркет. Двери просто могут Вам тогда и по ушам дать