Критерии перехода к 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. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

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

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

[Прохожий]

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

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

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

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

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

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

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

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

А чем плохи прерывания от аппаратных таймеров? Происходят всегда в одно и то же время +- несколько командных циклов.

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

Так, беда в том, что на свете вообще мало народа, разбирающегося до тонкостей в описании дискретизированного сигнала Оппемгеймом-Шафером. Откуда взяться ДОВОДАМ в этом конкретном случае? Но, ИМХО, это не критерий профессионализма.

В связи с этим пример из жизни. Довелось наблюдать лично...
Сварочный аппарат на основе инвертора. Занимается этим делом два индивидуума одновременно.

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

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

Оба укладываются приблизительно в одинаковые сроки, однако у первого индивидуума из десятка проданных аппаратов взрываются все 10 в течение 3 месяцев, а ко второму к этому сроку выстраивается очередь, потому как все его 10 аппаратов работают, при этом обладают достаточно хорошими характеристиками.

Однако, первый индивидуум может квалифицированно поговорить о краевых условиях при решении полевых задач, прекрасно представляет себе операторное счисление и при этом виртуозно владеет рядом профессиональных пакетов для ПК, включая IAR для ARMов.
Второй за это время с трудом овладевает PCADом 2002, получает патент на способ намотки силового трансформатора и остается девственно чист по отношению к высшей математике как таковой, поскольку высшее образование у него отсутствует напрочь.
Так вот вопрос. Кого можно считать профессионалом, а кого нет?

[Artem-1.6E-19]

Однако, первый индивидуум может квалифицированно поговорить о краевых условиях при решении полевых задач, прекрасно представляет себе операторное счисление и при этом виртуозно владеет рядом профессиональных пакетов для ПК, включая IAR для ARMов.
Второй за это время с трудом овладевает PCADом 2002, получает патент на способ намотки силового трансформатора и остается девственно чист по отношению к высшей математике как таковой, поскольку высшее образование у него отсутствует напрочь.
Так вот вопрос. Кого можно считать профессионалом, а кого нет?

Истина, как водится, где-то посредине. Но я вообще-то считаю что ведро транзисторов, говорит о некоем переходном этапе. После этого битых транзисторов остается очень мало. Многие, увы путают причину и следствие. Моделирование это следствие. А эксперимент причина.

[Прохожий]

Истина, как водится, где-то посредине.

Согласен.
Но вопрос задан конкретно. Кто профессионал?
Варианты ответов: 1 и 2.

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

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

Многие, увы путают причину и следствие. Моделирование это следствие. А эксперимент причина.

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

То же самое касается и RTOS. Если человек пишет программу для некоторого девайса на МК, т. е. идет сверху вниз, то RTOS ему остро необходима. А вот если человек делает девайс в целом, т. е. идет снизу вверх, то в этом случае создание софта обойдется без RTOS.
Путь сверху вниз проще, поскольку исключает гаражный этап и в случае неответственных устройств типа "глючащего" сотового телефона однозначно приводит к получению денег в сжатые сроки.
Но подобный подход, примененный в ответственном устройстве, приводит к тому, что иметь дело с оным в качестве потребителя просто опасно.

[Сергей Борщ]

Истина, как водится, где-то посредине.

Согласен.
Но вопрос задан конкретно. Кто профессионал?
Варианты ответов: 1 и 2.

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

[Прохожий]

Истина, как водится, где-то посредине.

Согласен.
Но вопрос задан конкретно. Кто профессионал?
Варианты ответов: 1 и 2.

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

Ваш вариант- софистика в чистом виде. Изначальное предположение о том, что я бью жену по ночам может быть ложным. Скажем так, у меня жены просто нет.
В своем вопросе аналогичного предположения я не вижу. Если Вы его увидели, то укажите где?

[Сергей Борщ]

Ваш вариант- софистика в чистом виде. Изначальное предположение о том, что я бью жену по ночам может быть ложным. Скажем так, у меня жены просто нет.
В своем вопросе аналогичного предположения я не вижу. Если Вы его увидели, то укажите где?

В вашем ответе изначальное предположение о том, что хотя бы один из них является профессионалом может быть ложным. Скажем так.

[Прохожий]

В вашем ответе изначальное предположение о том, что хотя бы один из них является профессионалом может быть ложным. Скажем так.

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

Знаете, силовые агрегаты и DSP вещи разные. Не хуже, не лучше, а просто разные.
У меня такой пример. Как-то я управлял самолетом. Знаете, а ведь управлять им гораздо проще, чем автомобилем - нет необходимости быть постоянно наготове притормозить или объехать. Не надо смотреть в зеркало заднего вида, переключать пердачи, жать на тормоз. Лети и все дела.
Но вот без обширных знаний т.н. "тонкостей", Вам самолета не поднять. В отличие от езды на автомобиле, которая гораздо сложнее и опасней.

Так и у Вас: где все определяет практика, а где-то в, основном, как у меня - теория.

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

Вы uCOS видели?

Нет не видел в силу ряда причин. Но пойду гляну.

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

Что-то не нашел. Одни порты.
Их реализация для PIC18 особого экстаза не вызвала.
А где взять сам уКОС2?
На Рапидшаре стерли за ненадобностью.
Помогите....