Критерии перехода к RTOS Опции

[kichkine]

Каковы по вашему мнению критерии перехода от "голой" программы к использованию RTOS?
Я вижу следующие:
необходимость работы с tcp/ip и т.д.
IPC (может легче что-то свое прикрутить?)

[Alex B._]

>> Остается понять, что такое "реакция".
Это хорошо описано в книжках, статьях и документациях про РТОСы. Декомпозиция задачи, синхронизация, dead-time, проблемы синхронизации (типа инверсии приоритетов)... Если вы утверждаете что в курсе что такое РТОС (чего не скажешь по вашей типа "статье"), вам должно быть известно, что такое "реакция".

>> то для меня совершенно понятно, что к real-time Вы отношения не имели.
да нет, конечно, не имел.

>> Добавьте еще две недели на флаги, мьютексы, семафоры и API-функции
и еще полгода на то, чтоб это все вместе работало. И самая интересная фича - это когда якобы работает, а у заказчика начинает глючить.

В чем вопрос-то, непонятно? При ваших условиях _без_прерываний_ никакая ОС вам не поможет. Должно быть хотя бы прерывание от таймера.

[st256]

>> то для меня совершенно понятно, что к real-time Вы отношения не имели.
да нет, конечно, не имел.

Тогда не перечьте тому, кто имел.

>> Добавьте еще две недели на флаги, мьютексы, семафоры и API-функции
и еще полгода на то, чтоб это все вместе работало. И самая интересная фича - это когда якобы работает, а у заказчика начинает глючить.

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

В чем вопрос-то, непонятно?

Как я понял, вопросы у Вас (см. Вашу реплику про "анекдот"). У меня все работает без вопросов. Т.е. существуют стандартные документы из соответствующих контролирующих служб и желающие дать мне новую разработку с использованием real-time.
А если Вам не нравятся мои статьи, то приведите аргументированное опровержение. Хотя вряд ли Вы это сможете сделать. На этом форуме очень низкая подготовка участников. Могут потявкать, поскулить, заявить, что "спрашивать для них равносильно пощечине", но аргументировать это явно не для местной публики. Так, что, может разойдемся? Вы мне по указанным причинам не интересны...

[zltigo]

Тогда не перечьте тому, кто имел.

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

[st256]

Тогда не перечьте тому, кто имел.

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

Г-н Прибалт, я уже знаю, что на любые разумные доводы Вы отвечаете сезонными обострениями. В этой веточке я лишь сказал следующее:

1. Когда я применяю RTOS.
2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.
3. Что в RTOS не надо применять прерываний для обмена данных.
4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

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

[Прохожий]

1. Когда я применяю RTOS.
2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.

Я вот тоже не могу понять зачем нужна RTOS. До сих пор мне удавалось решать совместно ряд задач управления и коммуникаций в рамках одного МК без всяких RTOS. Изделия работают в условиях сильных электромагнитных полей в составе силового промышленного оборудования.
Зачем нужна RTOS PIC18Fxxx или AVR мне совершенно непонятно. Зачем разбираться в чужой лепнине, которая в общем случае неизвестно кем и как написана, если за то же или чуть большеее время можно просто решить поставленную задачу?
С другой стороны, я четко представляю зачем нужна хотя бы DOS для ПК.
На мой взгляд, переносить принципы программирования ПК в программирование МК, управляющего чем-то в реальном времени, нельзя.

3. Что в RTOS не надо применять прерываний для обмена данных.

Извините, но лично мне кажется, что прерывания это самый быстрый способ обработать, то или иное событие (появление нарастания/спада напряжения на входе, конец цикла АЦП, прием байта по USART и т. д.). До сих пор никогда не имел проблем с прерываниями при обмене данными.
Не могли бы Вы еще раз более развернуто объяснить на чем основан такой Ваш подход и отношение к прерываниям.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков.

Пока Вы окончательно не истратили свои 70%, поясните, пожалуйста, Ваше представление о грамотном разработчике. Интересно узнать, без всяких шуток.

[st256]

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

Угу. Именно это я и имею в виду.

3. Что в RTOS не надо применять прерываний для обмена данных.

Извините, но лично мне кажется, что прерывания это самый быстрый способ обработать, то или иное событие (появление нарастания/спада напряжения на входе, конец цикла АЦП, прием байта по USART и т. д.). До сих пор никогда не имел проблем с прерываниями при обмене данными.
Не могли бы Вы еще раз более развернуто объяснить на чем основан такой Ваш подход и отношение к прерываниям.

Сначала вводные: я никогда не работал с двигателями и прочим силовым оборудованием. Потому считаю для себя неправильным лезть на чужую территорию. Но могу объяснить свой тезис на базе того, с чем мне приходилось встречаться - аудиообработка.

Представьте, что у Вас следующая часто встречающаяся задача: на вход процессора подается сигнал с частотой дискретизации 44.1 кГц, а на выходе Вы имеете частоту дискретизации 48.0 кГц.

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

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

К чему это приводит? А вот к чему: если у меня на одно прерывание от системного таймера уходило только 2% общего времени работы процессора, то уже для двух разных прерываний мне требовалось не 4%, а... 10%!

Кроме того, у меня начинался просто страшный геморрой из-за нагромождения критических секций, отдельных стеков, вариантов сохранения контекстов и т.д.

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

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

1. Прерывание на ввод 2 каналов ( это если у Вас еще синхронный ввод по каналам возможен, что не всегда верно).
2. Вывод на 2 канала.
3. Два прерывания на управление стереоэквалайзером.
4. Командный канал (включить-выключить 3D звук, к примеру)

Не кисло? Тут пахнет далеко не 2%.

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


Возможно, я чего-то не учитываю или не знаю, но пародокс то в том, что в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков.

Пока Вы окончательно не истратили свои 70%, поясните, пожалуйста, Ваше представление о грамотном разработчике. Интересно узнать, без всяких шуток.

Ну вот Вам пример: вчера листая Оппемгейма-Шафера нашел, как мне показалось, ошибку в описании дискретизированного сигнала. Так вот, профессионал это тот, с кем я могу аргументированно обсудить этот момент. Может я чего не понимаю, а может это стандартная некорректность, которых полно в радиотехнике, но для ее обсуждения требуются ДОВОДЫ. Профессионал может эти доводы порождать. Вам понятно?

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.
3. Что в RTOS не надо применять прерываний для обмена данных.
4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

Камсамида¸ в натуре!

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

[KirillS]

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

Угу. Именно это я и имею в виду.

3. Что в RTOS не надо применять прерываний для обмена данных.

Извините, но лично мне кажется, что прерывания это самый быстрый способ обработать, то или иное событие (появление нарастания/спада напряжения на входе, конец цикла АЦП, прием байта по USART и т. д.). До сих пор никогда не имел проблем с прерываниями при обмене данными.
Не могли бы Вы еще раз более развернуто объяснить на чем основан такой Ваш подход и отношение к прерываниям.

Сначала вводные: я никогда не работал с двигателями и прочим силовым оборудованием. Потому считаю для себя неправильным лезть на чужую территорию. Но могу объяснить свой тезис на базе того, с чем мне приходилось встречаться - аудиообработка.

Представьте, что у Вас следующая часто встречающаяся задача: на вход процессора подается сигнал с частотой дискретизации 44.1 кГц, а на выходе Вы имеете частоту дискретизации 48.0 кГц.

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

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

К чему это приводит? А вот к чему: если у меня на одно прерывание от системного таймера уходило только 2% общего времени работы процессора, то уже для двух разных прерываний мне требовалось не 4%, а... 10%!

Кроме того, у меня начинался просто страшный геморрой из-за нагромождения критических секций, отдельных стеков, вариантов сохранения контекстов и т.д.

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

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

1. Прерывание на ввод 2 каналов ( это если у Вас еще синхронный ввод по каналам возможен, что не всегда верно).
2. Вывод на 2 канала.
3. Два прерывания на управление стереоэквалайзером.
4. Командный канал (включить-выключить 3D звук, к примеру)

Не кисло? Тут пахнет далеко не 2%.

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


Возможно, я чего-то не учитываю или не знаю, но пародокс то в том, что в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков.

Пока Вы окончательно не истратили свои 70%, поясните, пожалуйста, Ваше представление о грамотном разработчике. Интересно узнать, без всяких шуток.

Ну вот Вам пример: вчера листая Оппемгейма-Шафера нашел, как мне показалось, ошибку в описании дискретизированного сигнала. Так вот, профессионал это тот, с кем я могу аргументированно обсудить этот момент. Может я чего не понимаю, а может это стандартная некорректность, которых полно в радиотехнике, но для ее обсуждения требуются ДОВОДЫ. Профессионал может эти доводы порождать. Вам понятно?

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.
3. Что в RTOS не надо применять прерываний для обмена данных.
4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

Камсамида¸ в натуре!

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

1)Ага. Простенькую аудио систему (так как она описана выше) действительно можно построить без операционной системы - этакий loop ввод-обработка-вывод. Опрос (polling) в RISC процессорах чаще всего гораздо эффективнее чем прерывание. Только вот ... есть ещё и командный канал. Если он - RS-232 или I2C, то можно обойтись без мультизадачности, но если кому-нибудь вздумается управлять такой системой с помощью TCP/IP, то тут услуги готовой ОС (покупной, freeware) весьма кстати.

2) "в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого" . Может быть. Но за пределами России разрабатывают. IMHO Можно найти кого спросить...

[st256]

1)Ага. Простенькую аудио систему (так как она описана выше) действительно можно построить без операционной системы - этакий loop ввод-обработка-вывод. Опрос (polling) в RISC процессорах чаще всего гораздо эффективнее чем прерывание. Только вот ... есть ещё и командный канал. Если он - RS-232 или I2C, то можно обойтись без мультизадачности, но если кому-нибудь вздумается управлять такой системой с помощью TCP/IP, то тут услуги готовой ОС (покупной, freeware) весьма кстати.

TCP/IP это не real-time. А оси для него не нужно. Нужно только приблуду из этой оси, которая драйвером называется и ее можно утянуть в комплекте с более-менее известной ОС. Потому мы для сих делов Linux используем. Именно из-за дармового софта, а вовсе не из-за его крутости или нужности.

Ну таких простеньких аудиосистем я никогда не реализовывал. Обычно полная и совершенно конкретная мультизадачность, причем с задачами не только тобой писаными. И задач таких в одном процессоре может крутиться до десятка. Возмите Ваш сотовый - это и есть "простенькая аудиосистема" - всякие mp3, midi и т.д.

2) "в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого" . Может быть. Но за пределами России разрабатывают. IMHO Можно найти кого спросить...

Ну в Ницце, наверное, делают RTOS, а еще где?