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

Всегда :-)
Кроме вырожденных случаев экономии "последнего байта" и "последнего такта".
Причем это тоже не факт, ибо за счет правильно посторенной системы можно и на объеме съэконогмить и
наиболее безболезненно разделить недостающие ресурсы между страждующими.
Вышенаписанное результат личного ~20-летнего движения от "сейчас сам быстренько напишу
маленькую и шустую" к системным вещам. Естественно "движение" сопровождалось возрастающей сложностью программ и мощностью контроллеров.


:-) Ну а это к RTOS ни при чем. Обычно такая причина выдвигается теми, кто по жизни пишет очень небольшие простенькие программы и при необходимости поднять нечто более сложное готов "поступиться с принципами" и взять хоть RTOS, хоть что угодно, лишь-бы там "было то, что нужно".
Собственно в такой подход и такая мотивация совершенно НОРМАЛЬНА, просто иногда на таком пути
человеков заносит куда-нибудь в "другую канаву" типа - "Как поставить Linux на ARM7" :-(

Отсутствие свободного времени :-)) Ну некогда мне писать scheduler, file system и networking stack - надо аппликацию разрабатывать, за которую деньги и платят. Хотя вырожденные случаи, когда из дохлого надо выжать всё, тоже встречаются.

Есть алтернатива и firmware и RTOS - real time kernel.
К привмеру FreeRTOS (GNU,портирована на многие CPU), VDS kernel (для BlakFin, потдерживается analog device).
Такия ядра, как правило, дают возмодность динамически выделять память, и синхронизировать tasks.
Так, например VDS kernel можно сконфигурировать в 4k.

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

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

Позволю себе заметить, что зачастую (пусть далеко не всегда, но в последнее время - особенно) привычки программиста и time-to-market играют более важную роль, нежели требования задачи.
А кстати, что есть такое - требования задачи? Кому-то задача ставила требования? По-моему и в этом случае всё достаточно субьективно.

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

Ой, извините пожалуйста! А вот у моей задачи такие требования:

сделать БПФ для вектора длинной в 2048 точек, если новый отсчет сигнала появляется каждые 4000 тактов процессора.

БПФ у меня получается минимум за 40000 тактов.

Следовательно, пока у меня наберется полный вектор проходит 2048*4000= 8096000 тактов.

Первое впечатление - я успеваю! Ведь мое БПФ делается всего за 40000 тактов.

Впечатление второе: нет... не успеваю... Ведь пока я БПФ делаю (функция естественно библиотечная, переписать нельзя), кто-то должен принять 10 отсчетов входного сигнала. Значит, библиотечную ф-цию нужно как-то прервать, принять очередной отсчет и запустить снова с прерванного места?

Не считаете ли Вы, что моя задача требует написания планировщика?

Бога ради, принимайте по прерываниям или DMA. А вот если параллельно к этому надо еще и парсить IP пакеты, считать часы реального времени, писать лог во флешку, ждать нажатия клавиши пользователем и рисовать на экране результаты- вот тут RTOS просто незаменима.

IP - это уже не real-time. Это раз.

считать часы реального времени? Ну не знаю, вроде тоже не real-time, многие инструментальные оси имеют эту приблуду... хотя сильно настаивать не буду.

писать лог во флешку, ждать нажатия клавиши пользователем и рисовать на экране результаты? Ну знаете, к real-time это имеет уже совсем отдаленное отношение.

Другими словами - Real-Time Operating System (RTOS) для Ваших задач не нужна. Справится и банальный порт LINUX для ARM. Это из собственного опыта говорю. А вот, как без ртосины решить мою задачу, если к примеру, когда я принимал участие в разработке одного DSP мы для уменьшения площади кристалла и облегчения собственной жизни выкинули всякие DMA и т.п. посчитав, что это себя просто не оправдывает?

>> Не считаете ли Вы, что моя задача требует написания планировщика
Речь идет не о _написании_ а об _использовании_
Отсчеты у вас что, не по прерываниям принимаются?

Написание планировщика вещь не сложная - пару недель всего вместе с отладкой. Использовать чужую ось (типа microC) - часто означает потерять теже пару недель, но для получения гораздо худшего результата.



Если у Вас real-time, то использовать прерывания и приоритеты строго не рекомендуется. Работают, обычно, по опросу - так надежнее.

real-time это абстрактное условие реакции на внешние события в заданный интервал времени.
Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

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

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




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



Добавьте еще две недели на флаги, мьютексы, семафоры и API-функции.

Если время выполнения задачи ограничено (имеется в виду астрономическое время) то это Real Time. Например, подсчёт зарплаты в конце месяца :-))

Почти всегда, наряду с hard real time CPU должен выполнять какие-нибудь совершенно не Real Time функции. И для этих целей off the shelf OS весьма хороша.

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


Я не знаю, что такое off the shelf OS. Извините.

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

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

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

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

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





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



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

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

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

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

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

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



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



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

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



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

2st256
дружище, да тебя всерьез уже никто не воспринимает, как ты не можеш понять? ты, баран, мне не смог на телесистемах ответить, где я смогу в России купить широко тобой рекламируемый, якобы тобой же разработанный проц.
О чем с тобой можно разговаривать, если кроме растопыренных пальцев ничего не видно?
тсссс. спокойно...

Наезд! Конкретный!

Чего-то я не понял.
감사합니다
Вы точно это имели ввиду? А по теме высказаться и не по-корейски?

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



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

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

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

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

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

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

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

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

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

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

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


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





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



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

Да ну??? Вы уверены?




Нет, я совсем другой знак Зодиака - водолей. Т.е. я склонен к философствованию, научной работе и обретению контроля над умами широких народных масс...

Бараном с вероятностью 1/12 можете оказаться Вы. С той же вероятностью Вы являетесь казлом и свиньей.




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

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

Это по теме. Ни о каких особых приемуществах BIOS по сравнению с UCOS я не знаю.


Разрабатывают. Но для себя в основном. Я работал с человеком, который наваял себе операционку, и работал с ней. Ну я часто без операционки обхожусь.


Я бы не сказал что у меня на прошлой работе была не серьезная математика. Да и не начинаются у меня проблемы. Проверял уже.

Ну ты же знаешь, что я знаю какая у тебя была тематика. Несерьезной я бы ее не назвал. Я бы ее назвал - средней серьезности. Именно поэтому, там у тебя проканал системный косяк. Ты вдруг решил, что можно работать с ДПФ без окна. Кстати, я тебе об этом уже говорил, но услышан не был

Во первых, ты кое что перепутал. А во вторых, я тебе хоть с форточкой разрешаю работать.

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

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

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




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



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



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



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

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

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

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

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

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

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

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


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



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

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

Тот у кого работает, тот и профессионал. У того у кого не работает называется банкрот.


переходный период завершился. Я когда занимался SMPS, так всегда знал, когда у меня транзистор может сгореть а когда нет. (IGBT сборка 50 баксов). Но это с очень большим радиолюбительским опытом. Правда я не на помойку их выкидывал, а на провод нанизывал и на окно вешал.

Плюс еще ИМХО привычка, которая идет от винды, не вникать в проблему а старься найти "особую", "умную" программу, которая ему решение подскажет.

Бред. Иногда она полезна, иногда нет. Если делать что-то БОЛЬШОЕ, то вероятность что она будет полезна повышается.

Тут я вашу мысль не понял. Я сейчас железяку делаю. Первый этап - запуск того, в чем я не до конца уверен. Второй - проверка на глючность. Если эти не пойдут, то и дальше идти смысла нет. Хотя, вот к примеру корейский подход - это начать с самого простого, а потом искать всяких профессоров, которые им будут помогать, за безумные деньги AFAIK.

Все критерии уже давно продуманы и сказаны:
например здесь хороший размышлизм
http://www.ganssle.com/articles/artos.htm
(обратите внимание на дату)
или вот здесь:
http://linuxdevices.com/articles/AT9560688601.html
или вот:
Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 000
долларов купленный продукт стоит примерно столько, сколько годовое содержание
программиста. И поставка немедленная! Немедленная, по крайней мере, для реально
существующих продуктов, проспект которых разработчик может послать счастливому
пользователю. Более того, такие продукты обычно гораздо лучше документированы
и несколько лучше сопровождаются, чем доморощенные программы.

Мифический человеко--месяц
ииллии ккаакк ссооззддааютссяя ппррооггррааммммнныыее ссиисстееммыы
Фредерик БРУКС
стр. 110

Почему это бред? Что такого БОЛЬШОГО Вы собрались делать?
Никогда не испытывал доверия к БОЛЬШИМ устройствам. На мой взгляд они вторичны и, как правило, в подавляющем большинстве случаев просто не нужны. Практически всегда можно найти простой выход. Редкие исключения в виде PLC, частотных инверторов лишь подтверждают этот тезис. Да и в этих случаях у девайсов имеется богатая история по которой можно отследить путь, по которому шли люди их создававшие. И мне кажется, что RTOS в данном случае дело не десятое, а тысячное.




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

С корейским подходом не знаком. Но лично я берусь только за то, что на 100% могу сделать сам, не прибегая к посторонней помощи. И только с помощью лично проверенных методов. Дядин софт априори считается ненадежным, в том числе и RTOS.

Это значит только то, что программиста нужно содержать в Индии.

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



Сложность програмной части частотного инвертора, ИМХО сильно привеличина. По поводу ПЛС, могу сказать что там в основном очено тупая, хотя и трудоемкая программа.

Да.

Так прямо категорично?

Реактор чтоль? Я думаю что ситуация несколько другая. Он не хочет чтобы на него повесили всех собак, если случится тоже что и в Чернобыле.

А если есть исходники? И эти исходники ОЧЕНЬ не плохо написаны? Я к пимеру очень многому научился с мюкосом.

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



Ну а сервопривод?



А как должно быть по Вашему? Телефон имеет полное право глючить, что он время от времени и делает, а ракета нет.

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



Тут я с Вами соглашусь. Учиться на чужом хорошем софте, как впрочем и на схемотехнике - дело полезное.
Но я то имел ввиду совершенно бездумное использование RTOS, так как мы все привыкли делать это в Винде и к чему призывают здесь некоторые.
Сказали бы честно, что мол прежде, чем использовать ОС ее надо приготовить, съесть и выс...ть хотя бы один раз. Я тогда и не выступал бы вовсе.

RTOS не всегда приводит к ускорению. Насчет ответсвенности, то если он будет глючить, то фирма обонкретится.

На рынке нет приличного осцилографа за несколько сот долларов. Для стран "золотого миллиарда" несколько тыс. на такое вот "хобби" не дорого. Для нас часто неподъемно. (я спектрумы и усилители делал без осцилографа. )

Чего? Крышки унитаза или стержней в ядерном реакторе?
Если первое, то безопасность достигается ограничением мощьности двигателя. Если во втором случае, то RTOS (и компютеров) там скорее всего вообще нет. Тоесть любой глюк не приведет к катастрофе.

Почему? Вы - Бог? Вы не можете сделать безглючный агрегат? Если можете, то как вы докажете что он безглючен?

Вы о чем? Модель обычно используется для отладки девайса.


Чтобы использовать, что-то нужно и понимать как оно работает. В проинципе RTOS - фикция. Абстракция.

Вы uCOS видели?

И что? Думаете, будут брать?



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




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


С первым предложением согласен. А вот второе не понял. В чем Вы видите "абстрактность" и "фиктивность " RTOS?


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

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

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



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

Допустимы. Например, Вы слушаете по сотовому mp3 файл и в этот момент поступает звонок - т.е. midi-поток накладывается на mp3.



DSP это не процессоры в полном смысле этого слова. Это скорее контроллеры. Т.е. они очень просты и дешевы от 2 до 5 долларов.




Грубо говоря, для конкретного DSP круг решаемых задач уже очерчен разработчиками. Смотришь на рекламку чипа, и там говориться - способен потянуть несколько вокодеров. Делаешь выводы.




А я только одно прерывание от таймера и испульзую. Для создания системных тиков. Как я уже говорил, ОДНО прерывание - не страшно. Страшно когда их много и они накладываются.



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




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

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

Потому что, никто ничего сложнее топора, в цепи отвечающие за запуск ракеты не поставит. Это просто не надежно.

Сейчас, у военных куча проблем с кажется разгонным модулем "Бриз" кажется? Каждый раз когда "Ракета отланилась от курса", или что-то еще, это вполне может быть ошибка контроллера. Ариан-5 вон, тоже несколько лет назад взорвался.


Используются.


В том, что РТОС это просто название. Если я что-то такое напишу, но не назову это РТОС, то это будет РТОС или нет?

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

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

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

Вот оно. Появилось имя операционной системы (Linux), да ещё и с описанием области применения. А стоило ли "готовый" (f.ex. from kernel.org) Linux использовать ? Можно было и самому написать ....

Более серьёзно: можете ли Вы оценить, сколько времени заняло у Вас имплементировать "полную и совершенно конкретную мультизадачность", причём, как видно, модулярно так как были там и задачи "не Вами писаные" ? Сколько времени Вам понадобится, чтобы подключить к проекту ещё одного квалифицированного разработчика, но ... незнакомого с Вашим проектом ?





Если б в Ницце... В Алабаме, например. А про разработку ОС в России, я честно не знаю...

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

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



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


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

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