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

[kichkine]

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

[zltigo]

Каковы по вашему мнению критерии перехода от "голой" программы к использованию RTOS?

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

необходимость работы с tcp/ip

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

[KirillS]

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

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

[surge]

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

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

[Hardman]

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

[IgorKossak]

Применять или не применять RTOS прежде всего зависит от конкретной задачи...

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

[khach]

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

[st256]

Применять или не применять RTOS прежде всего зависит от конкретной задачи...

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

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

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

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

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

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

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

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

Сообщение отредактировал st256 - Nov 30 2006, 18:08

[khach]

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

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

[st256]

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

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

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

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

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

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

[Alex B._]

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

[st256]

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

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

Отсчеты у вас что, не по прерываниям принимаются?

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

[Alex B._]

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

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

[st256]

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

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

Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

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

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

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

[KirillS]

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

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

Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

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

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

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

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

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

[st256]

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

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

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

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

[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%, поясните, пожалуйста, Ваше представление о грамотном разработчике. Интересно узнать, без всяких шуток.

[Artem-1.6E-19]

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

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

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

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

[Alex B._]

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

[Artem-1.6E-19]

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

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

[zltigo]

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

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

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

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

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

[st256]

2st256
дружище, да тебя всерьез уже никто не воспринимает, как ты не можеш понять?

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

ты, баран,

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

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

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

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

[Artem-1.6E-19]

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

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

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

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

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

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

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

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

[st256]

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

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

[Artem-1.6E-19]

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

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

[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 Можно найти кого спросить...

[Прохожий]

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

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

Представьте, что у Вас следующая часто встречающаяся задача: на вход процессора подается сигнал с частотой дискретизации 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.
Путь сверху вниз проще, поскольку исключает гаражный этап и в случае неответственных устройств типа "глючащего" сотового телефона однозначно приводит к получению денег в сжатые сроки.
Но подобный подход, примененный в ответственном устройстве, приводит к тому, что иметь дело с оным в качестве потребителя просто опасно.

[Artem-1.6E-19]

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

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

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

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

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

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

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

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

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

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

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

[path_finder]

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

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

[Прохожий]

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

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

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

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

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

[Artem-1.6E-19]

Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 000
долларов купленный продукт стоит примерно столько, сколько годовое содержание

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

Более того, такие продукты обычно гораздо лучше документированы
и несколько лучше сопровождаются, чем доморощенные программы.

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

Почему это бред? Что такого БОЛЬШОГО Вы собрались делать?

Ну, к примеру осцилограф. Типа тетроникса.

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

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

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

Да.

Да мысль проста и тривиальна. То, что хорошо для софта сотового телефона, абсолютно не подходит для баллистической ракеты.

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

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

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

Дядин софт априори считается ненадежным, в том числе и RTOS.

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

[Прохожий]

Ну, к примеру осцилограф. Типа тетроникса.

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

Сложность програмной части частотного инвертора, ИМХО сильно привеличина.

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

Да мысль проста и тривиальна. То, что хорошо для софта сотового телефона, абсолютно не подходит для баллистической ракеты.

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

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

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

Дядин софт априори считается ненадежным, в том числе и RTOS.

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

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

[Artem-1.6E-19]

Ну, к примеру осцилограф. Типа тетроникса.

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

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

Кстати, а зачем делать осциллограф? Их ведь есть на рынке в достаточно большом количестве и по приемлемой цене?

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

Сложность програмной части частотного инвертора, ИМХО сильно привеличина.

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

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

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

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

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

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

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

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

Сказали бы честно, что мол прежде, чем использовать ОС ее надо приготовить, съесть и выс...ть хотя бы один раз. Я тогда и не выступал бы вовсе.

Вы uCOS видели?

[Прохожий]

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

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

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

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

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

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

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

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

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

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

Сказали бы честно, что мол прежде, чем использовать ОС ее надо приготовить, съесть и выс...ть хотя бы один раз. Я тогда и не выступал бы вовсе.

Вы uCOS видели?

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

[st256]

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

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

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

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

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

[st256]

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

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

Процессор обязательно должен быть столь сложным или имеется возможность применить девайс попроще?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Artem-1.6E-19]

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

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

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

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

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

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

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

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

Вы uCOS видели?

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

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

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

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

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

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

[Прохожий]

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

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

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

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

[KirillS]

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

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

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

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

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

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

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

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

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

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

[Прохожий]

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

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

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

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

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

Вы uCOS видели?

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

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

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

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

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

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

[Artem-1.6E-19]

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

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

Все хитрее. Есть две крайности. Первая, это Высшая Математика. У человека происходит отрыв от реальности, бесконечные токи, напряжения итд. Это не лечится. Это путь в Торсионные поля итд. Вариант номер два, это когда поверхностные знания теории, но понимание "на пальцах" что происходит когда транзистор отпускает реле. Нужно будет, человек и с математикой этого разберется (а куда он денется). Но когда он будет разбираться, он будет помнить и о том что и диод не идиален.

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

Все хитрее. Есть две крайности. Первая, это Высшая Математика. У человека происходит отрыв от реальности, бесконечные токи, напряжения итд. Это не лечится. Это путь в Торсионные поля итд. Вариант номер два, это когда поверхностные знания теории, но понимание "на пальцах" что происходит когда транзистор отпускает реле. Нужно будет, человек и с математикой этого разберется (а куда он денется). Но когда он будет разбираться, он будет помнить и о том что и диод не идиален.

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

[Artem-1.6E-19]

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

Если разбираться по учебникам из СССР, то не разберется. А когда человеку к примеру ну ОЧЕНЬ нужен фильтр, а в аналоге у него все хар-ки плывут, то разберется. По себе знаю.

[st256]

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

Ядро Linux может и стоило написать самому. Один горячий финский парень так и сделал. А вот не стоило самому писать стек TCP/IP, который и привел к использованию LINUX. Но речь шла все-таки о RTOS, а ни TCP/IP, ни LINUX к real-time не относятся.

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

Обычно, на сам планировщик недели две у меня уходит. Я уже писал об этом.

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

Минут 30. Может 45...

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

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

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

В Алабаме не был. Даже никого оттуда не знаю и не в курсах, что там пишут. А в Ницце ресоч-центр TI находится.

[Carmack]

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

Если разбираться по учебникам из СССР, то не разберется. А когда человеку к примеру ну ОЧЕНЬ нужен фильтр, а в аналоге у него все хар-ки плывут, то разберется. По себе знаю.

Учебники по высшей математике из СССР ,особенно 40-50-60- х годов
написаны так,что лучше и не нужно.
Не учебники виноваты в этом случае.

[st256]

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

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

[DRUID3]

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

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

Учебники по высшей математике из СССР ,особенно 40-50-60- х годов
написаны так,что лучше и не нужно.
Не учебники виноваты в этом случае.

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

Все хитрее. Есть две крайности. Первая, это Высшая Математика. У человека происходит отрыв от реальности, бесконечные токи, напряжения итд. Это не лечится. Это путь в Торсионные поля итд. Вариант номер два, это когда поверхностные знания теории, но понимание "на пальцах" что происходит когда транзистор отпускает реле. Нужно будет, человек и с математикой этого разберется (а куда он денется). Но когда он будет разбираться, он будет помнить и о том что и диод не идиален.

Позволю с Вами немного не согласиться, хотя в принципе сразу я хотел одобрить Ваш тезис, но после некоторого раздумия... Теория и практика неразделимы в своей диалектической борьбе, это как освещенная и теневая сторона одного предмета - человеческой деятельности.
Вот вспомнил я некоторые предметы, такие как теория радиоцепей и сигналов, теория цепей, теория автоматического управления... Если бы не огромный радиолюбительский опыт и книга В.Т.Полякова "радиолюбителям о технике прямого преобразования" где я все прочел сначала упрощенно и уже сформировал круг задач, научился прикидывать спектры, оценивать сложности получения и детектирования тех или иных способов модуляции нифига бы я там не понял! С теорией цепей было гораздо грустнее, создалось такое впечатления чо препода здорово задели, мол, он не может ввести взрослого человека в заблуждение и он решил исправиться . Разобрался гораздо позже, почитав книжку Константина Гомоюнова "Транзисторные цепи". Судя по тексту, автор старой советской закалки, но зато все толково и понятно. Хоть в книге далеко не все вопросы освещены, но как раз это бы ее и убило бы, превратив в никому не нужный талмуд. Кстати это основная черта бездарности препода, когда человек думает что он все знает, и стремится все это втиснуть в 40 лекций. Получается полный гной, причем абсолютно бесполезный. Ибо сейчас включил комп в инет и нашел все что тебе надо, время когда в ВУЗ приезжал выходец из простой узбекской деревушки которого следовало "прогрузить" давно прошли и я вообще сомневаюсь, что в технической области сейчас реально рассказать все... надо скорее научит человека думать в эту сторону, интересоваться и творчески подходить к проблеме. А это даже не пытаются делать, ибо сами никогда так не делали... Да я еще эту ТАУ забыл упомянуть. Курс был не столь глубокий но я как вспомню эту декларацию незыблемых истин. Ужжжас. Однажды, сидя на лекции, я вдруг понял, что нам рассказывают о возможном возникновении генерации в цепи обратной связи, и это так близко к будущим будням радистов - самовозбуждение в АРУ - но ведь нет же, надо это рассказывать так, что бы если в ряды студентов вдруг затесался потенциальный враг - то не смог бы вынести военную тайну буржуям .
Так вот о чем это я. А о том, что все эти бесконечные токи и напряжения имеют место быть на практике (хотя бы в эскизном проектировании устройств на полевых транзисторах), мало того если они появились в нашей истории то значит кому-то в чем-то помогли . Просто научить их понимать может только тот кому они и помогли, а не первый попавшийся бюрократ от науки обвешанный титулами которые у работников высшей школы появляются видимо за выслугу лет, а не за ясный и светлый ум

To: ALL

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

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

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

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

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

а где можно посмотреть какой-нибудь бук или ресурс по методах реализации ОС под «ембадед» проекты (не только RTOS) Форум не предлагать, ибо мне бы что-то более абстрактное, это раС, а еще в форуме никогда не приходят к единому мнению, это дваС . Описалово работы уже существующих ОС тоже не так интересно, интересует какой-либо учебник…

Рискну предложить-приложить МГУ, К.Ю.Богачев, ОСРВ предварительные материалы лекций. Судя по оглавлению толковая книжка.
P.S. Если кто желает - киньте в ваши закрома на фтп.

Сообщение отредактировал Сергей Борщ - Dec 7 2006, 11:28

Прикрепленные файлы

 rtos.part1.rar ( 292.97 килобайт ) Кол-во скачиваний: 9924
 rtos.part2.rar ( 234.63 килобайт ) Кол-во скачиваний: 1416

 

[Alex B._]

Если в ладах с английским -
/pub/DOC/Books/OS/OS_incl_RTOS/Li-EmbSyst.chm
про RTOS применительно к embedded.
И вообще в той папочке поройся

[Nixon]

2 Сергей Борщ - принудительно перевел в "свои"

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

2 Сергей Борщ - принудительно перевел в "свои"

:-) Спасибо. Может пригодится.

[Прохожий]

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

К сожалению, мои сведения по этому вопросу ограничиваются учебником по пром. электронике и Datasheet'ами на стандартные промышленные сетевые фильтры. Если Вас это устроит, могу дать ссылки на эти данные.

[Artem-1.6E-19]

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

Я не понял что вы написали. Вы написали конечного много, но я ниасилил.
Я сразу напишу все что думаю, чтобы у вас было еще больше поводов для несогласия. Я считают что образование в СССР было гавно. По крайней мере тогда, когда я в нем учился (1976г.р.) Я понял что нам расказывал старый маразматик на ТАУ, только спустя несколько лет после окончания института, когда в книжке от АД нашел знакомые формулы. Но вот в отличии от ТАУ, я понял что в них написано, и ужаснулся, до чего же все просто, не взирая на то, что инглишя тогда знал ну ОЧЕНЬ паршиво.

Так что. 1. Практика. И теория для того чтобы понять как работает практика. Именно так всегда двигалась наука. Сначала - эксперимент - потом теория его объясняющая. Так и нужно учится.
2. Практика для того чтобы зарабатывать бабло. К примеру сегодня считал индуктивность. У меня на компе несколько гигабайт книжек разных. Много очень умных. Но вот если там вместо того чтобы расказать как считать индуктивность, начинают расказывать про Максвелла, то у меня сразу начинали возникать сомнения, что этот человек действительно знает как считать индуктивности. Про Максвела он знает, я не спорю. может много чего расказать. А вот если ему сказать, мне нужен один генри, который будет работать при токе в один ампер, и частоте один герц, то думаю что закончится все проектом создания витка из сверхпроводника в космосе.

[KirillS]

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

Обычно, на сам планировщик недели две у меня уходит. Я уже писал об этом.

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

Минут 30. Может 45...

А можете ли вы "выделить" планировщик (надеюсь, вместе с механизмами синхронизации и intertask communication) и положить его куда нибудь как freeware ? По следам горячего финского парня? Ведь это ж RTOS которую можно изучить за полдня!

В Алабаме не был. Даже никого оттуда не знаю и не в курсах, что там пишут. А в Ницце ресоч-центр TI находится.

В Алабаме Mentor Graphics делают RTOS Nucleus (не верх совершенства, IMHO)

[st256]

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

К сожалению, мои сведения по этому вопросу ограничиваются учебником по пром. электронике и Datasheet'ами на стандартные промышленные сетевые фильтры. Если Вас это устроит, могу дать ссылки на эти данные.

Увы, меня не интересуют сами сетевые фильтры. Меня интересует, что будет, если эти фильтры не поставить. Мне не понятно, почему нефтянники так парятся по поводу 7-ой гармоники. Т.е. парятся они совершенно конкретно, но толком объяснить почему парятся - не могут. Я не могу даже понять, с какой точностью эту гармонику измерять. 0.1% хватит? А может хватит и 1%? И вообще, почему только седьмая? А остальные как? И т.д.

А можете ли вы "выделить" планировщик (надеюсь, вместе с механизмами синхронизации и intertask communication) и положить его куда нибудь как freeware ? По следам горячего финского парня? Ведь это ж RTOS которую можно изучить за полдня!

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

[Artem-1.6E-19]

Увы, меня не интересуют сами сетевые фильтры. Меня интересует, что будет, если эти фильтры не поставить. Мне не понятно, почему нефтянники так парятся по поводу 7-ой гармоники. Т.е. парятся они совершенно конкретно, но толком объяснить почему парятся - не могут.

Я не помню, но там какая-то возникает при трехфазном выпрямители.

Я не могу даже понять, с какой точностью эту гармонику измерять. 0.1% хватит? А может хватит и 1%? И вообще, почему только седьмая? А остальные как? И т.д.

Все нужны. К примеру посчитай какой у нее скин-эффект.

[Прохожий]

Увы, меня не интересуют сами сетевые фильтры. Меня интересует, что будет, если эти фильтры не поставить. Мне не понятно, почему нефтянники так парятся по поводу 7-ой гармоники. Т.е. парятся они совершенно конкретно, но толком объяснить почему парятся - не могут. Я не могу даже понять, с какой точностью эту гармонику измерять. 0.1% хватит? А может хватит и 1%? И вообще, почему только седьмая? А остальные как? И т.д.

Открыл учебник по пром. электронике и прочел следующее.

Код

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

Ниже написано

Код

В трехфазных системах, гармоники, кратные трем, обычно в силу симметрии отсутствуют, и гармоническими составляющими напряжения в сети бывают 5, 7, 11, 13-я и т. д. гармоники. Низшие из них наиболее интенсивны.

Далее следует описание системы поддержания коэффициента мощности на максимальном уровне при изменении реактивной мощности, потребляемой преобразователями. Присутствует и простая мат. модель.
Т. е. насколько я понял измерять 7-ю гармонику необходимо для того, чтобы улучшить качество регулирования т. наз. управляемого конденсаторно-тиристорного источника реактивной мощности.
Отсюда, я думаю, можно получить и желаемую точность. Впрочем, могу быть неправ.
Вот название учебника.
Горбачев В. Г., Чаплыгин Е. Е. Промышленная электроника: Учебник для вузов/ Под ред. В. А. Лабунцова. - М.: Энергоатомиздат, 1988 - 320 с.: ил.
Вам может понадобиться глава 7 и в частности параграф 7.3 на стр. 269.

[zltigo]

Здорово тема "развивается".

P.S.
Может стоит ее перименовать в "Зачем попу гармонь", ну или
"Критерии использования RTOS служителями культа при отправлении обрядов"?

[st256]

Здорово тема "развивается".

P.S.
Может стоит ее перименовать в "Зачем попу гармонь", ну или
"Критерии использования RTOS служителями культа при отправлении обрядов"?

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

Код

В трехфазных системах, гармоники, кратные трем, обычно в силу симметрии отсутствуют, и гармоническими составляющими напряжения в сети бывают 5, 7, 11, 13-я и т. д. гармоники. Низшие из них наиболее интенсивны.

Далее следует описание системы поддержания коэффициента мощности на максимальном уровне при изменении реактивной мощности, потребляемой преобразователями. Присутствует и простая мат. модель.
Т. е. насколько я понял измерять 7-ю гармонику необходимо для того, чтобы улучшить качество регулирования т. наз. управляемого конденсаторно-тиристорного источника реактивной мощности.
Отсюда, я думаю, можно получить и желаемую точность. Впрочем, могу быть неправ.
Вот название учебника.
Горбачев В. Г., Чаплыгин Е. Е. Промышленная электроника: Учебник для вузов/ Под ред. В. А. Лабунцова. - М.: Энергоатомиздат, 1988 - 320 с.: ил.
Вам может понадобиться глава 7 и в частности параграф 7.3 на стр. 269.

Спасибо, лезть не надо. Теперь ясно, что гармошки, в основном, накодятся от 2-ой до 13-ой (старый ГОСТ 13109-97)
убираем четные (симметричный относительно нуля сигнал) и кратные трем. Остаются всего четыре:

5,7,11,13

На седьмую и пятую падает основная мощща. Спасибо.

[Прохожий]

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

Вопрос о многоканальном регистраторе. Если этот проект выполнять на МК c DSP ядром или чистом DSP, то каково должно быть тех. задание, чтобы RTOS стала необходимостью? И в чем близость между гармониками и RTOS? Без шуток...
Лично для себя я решил, что в своих проектах на МК с ограниченными внутренними ресурсами постараюсь обойтись вовсе без нее. Причины этого могу изложить по пунктам, если кому будет интересно.

Что же касается серости, то мне кажется, что все мы не без этого греха в той или иной степени. Эмоции по этому поводу считаю просто излишними.

На седьмую и пятую падает основная мощща. Спасибо.

Всегда рад оказать посильную помощь.

[Artem-1.6E-19]

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

Интересно. Часто RTOS позволяет лучше использовать ресурсы, и их нужно меньше, чем без RTOS (если программист не опытный).

[Прохожий]

Интересно. Часто RTOS позволяет лучше использовать ресурсы, и их нужно меньше, чем без RTOS (если программист не опытный).

Сразу оговорюсь, что все нижеизложенное отражает только лишь мое личное мнение.
1. Использование RTOS снижает надежность системы на МК, поскольку сама она вещь в себе и кроме этого есть порты неизвестно кем и как писанные.
2. Использование RTOS снижает производительность системы хотя бы из-за необходимости сохранения достаточно обширного контекста задач.
3. Большинство RTOS принуждает использовать ЯВУ, в частности С, даже там, где для этого нет необходимости. В нашей ситуации это приводит к воровству софта, что после в ступления в ВТО может пагубно отразиться на многих из нас. Исключение GCC для AVR и частично MCC18 и С30 для PIC.
4. Использование RTOS в общем случае замедляет работу системы на время обслуживания собственных процессов.
5. Использование RTOS уменьшает доступные ресурсы системы. В частности уменьшает доступную память на величину, необходимую для хранения ядра и на хотя бы один таймер, используемый для службы времени.
6. Использование RTOS принуждает к изучению вторичной информации о ее функциях, методах и событиях, никак не связанных с решаемыми реальными задачами. Это непроизводительные временные затраты и необходимость хранения "в голове" абсолютно бесполезной информации.
7. Использование RTOS приучает к определеннму стилю программирования, на мой взгляд не очень красивому и эффективному. Пример этого стиля - использование замкнутых на себя циклов в качестве задержек.
8. RTOS зачастую не всегда хорошо отображается на архитектуру конкретного МК. Может я в чем-то не разобрался, но на мой взгляд RTOS только мешает эффективному использованию системы прерываний, особенно векторной.
9. RTOS приводит к появлению новых сущностей, таких как семафоры, мьютексы, майл-боксы, планировщики заданий и т. д. и т. п. На мой взгляд все это лишнее и только уводит разработчика от "железа" МК и внешнего оборудования, а это плохо.
Пока все. Если что появится, тогда добавлю еще.

[Artem-1.6E-19]

Интересно. Часто RTOS позволяет лучше использовать ресурсы, и их нужно меньше, чем без RTOS (если программист не опытный).

Сразу оговорюсь, что все нижеизложенное отражает только лишь мое личное мнение.
1. Использование RTOS снижает надежность системы на МК, поскольку сама она вещь в себе и кроме этого есть порты неизвестно кем и как писанные.

Нет. Это часто просто кусок уже написаной программы. Зачем писать то, что уже неписано. Разумеется, RTOS ДОЛЖНА быть в исходниках.

2. Использование RTOS снижает производительность системы хотя бы из-за необходимости сохранения достаточно обширного контекста задач.

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

3. Большинство RTOS принуждает использовать ЯВУ, в частности С, даже там, где для этого нет необходимости. В нашей ситуации это приводит к воровству софта, что после в ступления в ВТО может пагубно отразиться на многих из нас. Исключение GCC для AVR и частично MCC18 и С30 для PIC.

Еще есть SDCC и GCC для ARM и MSP. Остаются DSP. Стоимость компилятора - несколько килобаксов. Воровство софта прекратится, как только З.П. дойдет до уровня к примеру Бангалора.

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

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

5. Использование RTOS уменьшает доступные ресурсы системы. В частности уменьшает доступную память на величину, необходимую для хранения ядра и на хотя бы один таймер, используемый для службы времени.

Тоже что и пункт два.

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

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

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

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

8. RTOS зачастую не всегда хорошо отображается на архитектуру конкретного МК.

Есть МК на которые вообще С не отображается.

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

Юкосу нужно только одно прерывание. Остальные остаются у пользователя.

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

Весьма удобные вещи. Если задача сложная. Использование готовых сущьностей освобождает время для траха с железом и внешним оборудованием. Коме того, дает стандартный интерфейс для этого.

Пока все. Если что появится, тогда добавлю еще.

Хорошие РТОС - могут быть полезны. Но не всегда. Если задача взять поток из одного ДМА, пересемплировать, и запихать в другой ДМА, то никакие оси там не нужны.
Если задача - сложный технологический процесс, есть граф. интерфейс, файловая система, (не просто мерять токи и транзисторами хлопать) то нужна.

[Прохожий]

Нет. Это часто просто кусок уже написаной программы. Зачем писать то, что уже неписано. Разумеется, RTOS ДОЛЖНА быть в исходниках.

Когда и кем написанная? Кем написаны порты? К примеру, в порте uCOS для PIC18 я нашел принципиальный недочет, приводящий к фатальной ошибке при определенных условиях. Это раз.
А во-вторых, зачем мне кусок ничего не делающей программы, которая не решает ни одной из поставленных задач?

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

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

Еще есть SDCC и GCC для ARM и MSP. Остаются DSP. Стоимость компилятора - несколько килобаксов. Воровство софта прекратится, как только З.П. дойдет до уровня к примеру Бангалора.

Не будет этого никогда. З. П, разработчиков будет только уменьшаться по отношению к остальным. Это общемировая тенденция. И кто такой Бангалор?

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

О дисках речи нет, поскольку лично я подразумеваю МК с ограниченными ресурсами. Я так понял, что Вы утверждаете, что машинное время МК совершенно не тратится на обслуживание разных семафоров, мьютексов и прочей ерунды? Между прочим, судя по порту uCOS для PIC18, простое переключение между задачами - это 10 команд и 20 машинных циклов. Всегда. Для меня лично это непозволительная роскошь.

Тоже что и пункт два.

Значит Вы утверждаете, что ядро RTOS никакого места в памяти программ не занимает? А где оно хранится тогда?

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

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

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

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

Есть МК на которые вообще С не отображается.

А что - это проблема? Есть Паскаль, Бэйсик, ну и Ассемблер. На мой взгляд человек, не освоивший Ассемблер выбранного МК, не имеет права применять ЯВУ, а тем более надстройку над ним в виде RTOS для создания встроенных систем, как не освоивший архитектуру системы. Это, естесственно, не касается инструментальных систем на РС. Там совершенно иные правила.

Юкосу нужно только одно прерывание. Остальные остаются у пользователя.

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

Весьма удобные вещи. Если задача сложная. Использование готовых сущьностей освобождает время для траха с железом и внешним оборудованием. Коме того, дает стандартный интерфейс для этого.

Ну да. Трах с железом абсолютно неизбежен, но к нему добавляется еще и трах с RTOS. Смотрел я на этот стандартный интерфейс к железу...

Хорошие РТОС - могут быть полезны. Но не всегда. Если задача взять поток из одного ДМА, пересемплировать, и запихать в другой ДМА, то никакие оси там не нужны.
Если задача - сложный технологический процесс, есть граф. интерфейс, файловая система, (не просто мерять токи и транзисторами хлопать) то нужна.

Еще раз напомню, что речь шла о встроенных системах без файловых систем и сложных графических интерфейсов. Обычно в пром. автоматике эти вещи разъеденины. Управление машиной - это PLC с примитивным языком или простой МК, а визуализация - PC с полноценной ОС. И где тут место для RTOS?

[Artem-1.6E-19]

[quote name='Прохожий' date='Dec 10 2006, 16:21' post='185726']
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Нет. Это часто просто кусок уже написаной программы. Зачем писать то, что уже неписано. Разумеется, RTOS ДОЛЖНА быть в исходниках.
[/quote]
Когда и кем написанная? Кем написаны порты? К примеру, в порте uCOS для PIC18 я нашел принципиальный недочет, приводящий к фатальной ошибке при определенных условиях. Это раз.
[/quote]


Ну? Я в порте для АВР нашел. И что с того?
[quote]
А во-вторых, зачем мне кусок ничего не делающей программы, которая не решает ни одной из поставленных задач?
[/quote]
Она их помогает решать.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Если контекст задачи нужно сохранять, то его нужно сохранять. Будет называться та часть программы РТОС, или нет, на производительность не влияет.
[/quote]
Есть стили программирования, когда даже нет понятия о контексте задачи. Да и понятия задачи тоже.
Сначала надо определиться с подходом, и при его правильном выборе вопрос о RTOS отпадает сам собой.
[/quote]
Согласен.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Еще есть SDCC и GCC для ARM и MSP. Остаются DSP. Стоимость компилятора - несколько килобаксов. Воровство софта прекратится, как только З.П. дойдет до уровня к примеру Бангалора.
[/quote]
Не будет этого никогда. З. П, разработчиков будет только уменьшаться по отношению к остальным. Это общемировая тенденция.
[/quote]
Значит что в будущем разработчиков не будет.


[quote]
И кто такой Бангалор?
[/quote]
Город в Индии. Где софт пишут для США.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Что за собственные процессы? Если брать UCOS то там их я не помню. Если к примеру линукс, и брать к примеру дисковый кеш, то ничто не мешает монтировать диски в снхронном режиме, правда вот скорости это обычно не прибавляет.
[/quote]
О дисках речи нет, поскольку лично я подразумеваю МК с ограниченными ресурсами. Я так понял, что Вы утверждаете, что машинное время МК совершенно не тратится на обслуживание разных семафоров, мьютексов и прочей ерунды?
[/quote]
Тратится, но какая разница на что его тратить, на свой самафор или на Юкосный?


[quote]
Между прочим, судя по порту uCOS для PIC18, простое переключение между задачами - это 10 команд и 20 машинных циклов. Всегда. Для меня лично это непозволительная роскошь.
[/quote]
Может вы просто не так пишете софт?


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Тоже что и пункт два.
[/quote]
Значит Вы утверждаете, что ядро RTOS никакого места в памяти программ не занимает? А где оно хранится тогда?
[/quote]
Занимает.

[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Да но снижает время на изобретение велосипеда. Вопрос что лучше - изобретать велосипед или воспользоваться готовым - вопрос сложности задачи. Если она достаточно сложная, то оно оправдывает.
[/quote]
Смотря что понимать под велосипедом. Мне кажется, что время, потраченное на RTOS, лучше потратить на освоение методик программирования при которых потребность в оной отпадает, даже при задачах любой степени сложности.
[/quote]
Попробуйте работать без операционки на персоналке.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
РТОС предоставляет очень эффективный способ формирования задержек - путем отдачи не используемого времени другой задаче.
[/quote]
Для того, чтобы организовать оптимальное взаимодействие между различными задачами (по-вашему, поскольку у меня другое определение для этой сущности) даже при большом их количестве вполне достаточно здравого смысла и правильной методики программирования.
[/quote]
Согласен. Но операционку тоже можно использовать.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Есть МК на которые вообще С не отображается.
[/quote]
А что - это проблема? Есть Паскаль, Бэйсик, ну и Ассемблер. На мой взгляд человек, не освоивший Ассемблер выбранного МК, не имеет права применять ЯВУ, а тем более надстройку над ним в виде RTOS для создания встроенных систем, как не освоивший архитектуру системы. Это, естесственно, не касается инструментальных систем на РС. Там совершенно иные правила.
[/quote]
Я не согласен. Досконально изучать ассемблер смысла нет. Достаточно разобраться что так к чему, чтобы можно было разобраться в листинге.



[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Юкосу нужно только одно прерывание. Остальные остаются у пользователя.
[/quote]
Я так и говорил, что одно как минимум прерывание потеряно. Для меня это существенно. И еще большой вопрос как это все будет между собой взаимодействовать.
[/quote]
Может вы что-то не так делали? К примеру время вам нужно считать? Интервал в 1 милисекунду достаточен? Вот и используйте интервал в 1 мс, и для шедулера.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Весьма удобные вещи. Если задача сложная. Использование готовых сущьностей освобождает время для траха с железом и внешним оборудованием. Коме того, дает стандартный интерфейс для этого.
[/quote]
Ну да. Трах с железом абсолютно неизбежен, но к нему добавляется еще и трах с RTOS. Смотрел я на этот стандартный интерфейс к железу...
[/quote]
Не стандартный интерфейс к железу, а к взаимодействию разных частей программы. Семафоры итд, уже давно придумали и продумали.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Хорошие РТОС - могут быть полезны. Но не всегда. Если задача взять поток из одного ДМА, пересемплировать, и запихать в другой ДМА, то никакие оси там не нужны.
Если задача - сложный технологический процесс, есть граф. интерфейс, файловая система, (не просто мерять токи и транзисторами хлопать) то нужна.
[/quote]
Еще раз напомню, что речь шла о встроенных системах без файловых систем и сложных графических интерфейсов. Обычно в пром. автоматике эти вещи разъеденины. Управление машиной - это PLC с примитивным языком или простой МК, а визуализация - PC с полноценной ОС. И где тут место для RTOS?
[/quote]


Нужно по задаче смотреть.

Сообщение отредактировал Artem-1.6E-19 - Dec 10 2006, 18:18

[Прохожий]

Она их помогает решать.

Не факт. Абсолютно. Здесь Вы меня не убедите никогда. Поэтому предлагаю ничью по этой части дискуссии. Каждый остается при своем.

Значит что в будущем разработчиков не будет.

В том виде, как мы с Вами представляем, к сожалению, нет. Я, лично, уже около 10 лет таковым не являюсь. Стремление к мат. благам перевесило. Пошел сменным инженером на крупное производство. Занимаюсь техническим творчеством только, когда сильно попросят или для души.
Зато могу взглянуть на процесс разработки со стороны. Да и подходы, принятые в пром. автоматике, оказали свое воздействие...

И кто такой Бангалор?

Город в Индии. Где софт пишут для США.

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

Тратится, но какая разница на что его тратить, на свой самафор или на Юкосный?

У меня нет семафоров. Есть входные переменные.

Может вы просто не так пишете софт?

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

Попробуйте работать без операционки на персоналке.

Пробовал. Был такой зверь - "Электроника 60" назывался, PDP/LSI-11 по-ихнему. Я на нем в юности программки валял прямо в кодах, даже без Ассемблера.
А сейчас даже и пытаться не буду. Я больше скажу. Я и Visual С++ пользоваться не буду. Потому как человеко-машинный интерфейс там не очень. По мне так Borland C++ Builder самое то.
Но одно дело встроенные системы, которые должны быть особо надежными и совсем другое системы на основе РС, обеспечивающие HMI. У них иные требования, и надежность среди них - не самое первое.
Хотя справедливости ради отмечу, что в свое время наблюдал создание полноценной системы визуализации с нуля на процессоре I80186 без всяких встроенных RTOS и ОС.

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

Так наизусть никто и не заставляет... Здесь важно осознать, я бы сказал, "почувствовать" архитектуру определенного класса МК. А для этого надо навалять пару, тройку не очень сложных программуль на Ассемблере, желательно с использованием прерываний и каких нибудь внутренних переферийных узлов МК.

Может вы что-то не так делали? К примеру время вам нужно считать? Интервал в 1 милисекунду достаточен? Вот и используйте интервал в 1 мс, и для шедулера.

Я вообще время не считаю. Временные переменные (разных типов) ничем не хуже и не лучше всех остальных.

Не стандартный интерфейс к железу, а к взаимодействию разных частей программы. Семафоры итд, уже давно придумали и продумали.

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

Нужно по задаче смотреть.

Пересмотрел хренову тьму пром. оборудования. Везде одно и то же. Концептуально от задачи ничего не зависит. Меняется мощность PLC и размер панели.

[Artem-1.6E-19]

Если будет идея "по существу", пишите. Возрастом махать, как-то не конструктивно.

[sensor_ua]

Сразу - всё ИМХО, не больше. Наверно...
Не так давно появился термин BSP (Board Support Package) - он вместил в себя дрова и подсистему синхронизации/времени (не часы-календарь, а системного). Причём эта штуковина предполагает дрова незавязанные на ОС (ОС не участвует в решении внутренних проблем драйверов), а предоставляющие себя. Соответственно дрова обеспечивают некоторый сервис, в том числе разделение/совмещение/преобразование потоков и блочных данных. На уровне взаимодействия с ОС становятся необходимыми быть какие-либо достаточно привычные способы взаимодействия, например IOCTL или "обычные" семафоры, мейлбоксы... Так вот ежели линуксовый люд и мелкомягкие всё чаще имеют одно мнение (помотрите факты отсутствия термина HAL во многих современных реализациях и линухов и виндовсэмбеддед и замена на BSP), то вопросов становится только больше.
Я считаю, что нужно так реализовывать дрова, чтобы максимально ОС там нафиг не была нужна, но спокойно могла ими пользоваться - тогда ОС и частный случай - RTOS - простой и унифицированный способ написания/выполнения прикладных задач. Конечно дрова не бывают одинаковыми под все ОС
Мне, правда, чаще хватает механизма сопрограмм и round robin, чем полноценной RTOS, но когда нужно хоть что-то, типа файловой системы, то реализация без ОС может быть относительно безболезненна только в очень узкоспециализированных задачах.
Ежели есть PC и ОС для него, то дрова и ОС завсегда завязаны - традиция установки костылей, и выбор ОС есть вопрос анализа преимуществ и недостатков не просто ОСей, а вместе с дровами... и их глюками... известными и неизвестными... Это отдельная тема для больших диссертаций и криков "ацтой"

[Artem-1.6E-19]

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

Извините, вы оптимист или просто человек со странностями?

[sensor_ua]

Считайте лучше, что со странностями.
Пример.
Нужен драйвер UART с кольцевыми буферами и управлением передачей (программно). Рассмотрим механизм передачи (чуть-чуть).
Вариант 1.
Наполнение/опустошение буфера передачи реализуем с семафорами, по окончании выгрузки из буфера передачи в аппаратное FIFO взведём событие. ОС поднимет ожидающую задачу, которая в свою очередь запустит отсчёт времени на выключение передачи и уйдёт ждать события таймера.
Вариант 2.
Флаг блокировки вынесем в интерфейс драйвера. Де-факто не будем пытаться разделять ресурс. "Часть от семафора" - локальный счётчик понадобится для работы с головой/хвостом буфера. По окончании выгрузки из буфера передачи в аппаратное FIFO добавим в слот таймера в список нашу маленькую функцию (в обработчике прерывания таймера двигаем однонаправленные списки, пустые или не совсем - махонький локальный жесткий планировщик) переключения передачи. Вуаля - ОС нифига не знает об этой локально решённой задаче - она не есть полноценный task - это её в task можно завернуть, ну и тягать за собой честный шедулер ОС, TCB и т.д.
Т.е. я не говорю, что можно сделать независимость нашару. Какие-то абстрактные уровни - низ/верх, железо/апликейшн - реализуются часто одними и теми же средствами/методами. Дороговато обходится бисером телогрейки вышивать

[st256]

Вопрос о многоканальном регистраторе. Если этот проект выполнять на МК c DSP ядром или чистом DSP, то каково должно быть тех. задание, чтобы RTOS стала необходимостью?

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

Вот мое ТЗ:

- Ввод по 48 независимым каналам.
- обработка во временной области (фильтрация, нахождение СКО и т.д.)
- обработка в частотной (гармонический анализ)
- вывод в буферное ОЗУ
- вывод во флэш
- перкачка из флэш в пользовательский(присоединяемый по необходимости) винчестер
- еще всякая фигня в такомже роде.

Есть и условия типа: 80% всего времени процессор щелкает обработку во временной области (фильтрация, нахождение СКО и т.д.) и 10% - на спектральный анализ.

И в чем близость между гармониками и RTOS? Без шуток...

Да вот не могу я заниматься гармониками без RTOS! Хоть ты тресни. Пробывал - не получается.

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

Изложите, пожалуйста.

Что же касается серости, то мне кажется, что все мы не без этого греха в той или иной степени. Эмоции по этому поводу считаю просто излишними.

Ну нада-а-а-а-ел он мне! Его манера лезть не имея достаточных DSP навыков в дискуссию надоела. Лез бы он хоть с идеями (пусть неправильными), а он лезет с философскими изысками типа острот. При этом меня раздражает его подспудная аппеляция к господам модераторам: ну я же свой! Я ж вас всех всегда хвалю! Это ничего, что я слабо шарю, главное во мне не это...

В принципе, один товарищ в подобной ситуации выразился гораздо лаконичнее: любителя бьют!!!

...т.е. радиолюбителя

[Прохожий]

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

Да вот не могу я заниматься гармониками без RTOS! Хоть ты тресни. Пробывал - не получается.

Я так понял, что Ваш регистратор будет снабжен собственной оригинальной RTOS, написанной специально для этого случая?

Изложите, пожалуйста.

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

Ну нада-а-а-а-ел он мне! Его манера лезть не имея достаточных DSP навыков в дискуссию надоела. Лез бы он хоть с идеями (пусть неправильными), а он лезет с философскими изысками типа острот. При этом меня раздражает его подспудная аппеляция к господам модераторам: ну я же свой! Я ж вас всех всегда хвалю! Это ничего, что я слабо шарю, главное во мне не это...

В принципе, один товарищ в подобной ситуации выразился гораздо лаконичнее: любителя бьют!!!

...т.е. радиолюбителя

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

[st256]

Я так понял, что Ваш регистратор будет снабжен собственной оригинальной RTOS, написанной специально для этого случая?

Ну RTOS или не RTOS, но что-то в этом роде. Правда, скорее всего на этот раз я писать не буду, а возьму что-то из себя раннего Т.е. у меня есть заготовки.

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

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

Ну нада-а-а-а-ел он мне! Его манера лезть не имея достаточных DSP навыков в дискуссию надоела. Лез бы он хоть с идеями (пусть неправильными), а он лезет с философскими изысками типа острот. При этом меня раздражает его подспудная аппеляция к господам модераторам: ну я же свой! Я ж вас всех всегда хвалю! Это ничего, что я слабо шарю, главное во мне не это...

В принципе, один товарищ в подобной ситуации выразился гораздо лаконичнее: любителя бьют!!!

...т.е. радиолюбителя

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

Разве я напрягаю нервы? Наоборот, я развлекаюсь! Еще мне интересно на сколько хватит местного модератора меня почитывать. Любителя Графики и Научного Атеизма ес-но жалко, но что делать? Он мне разонравился за совершенно конкретные деяния.

[IgorKossak]

Разве я напрягаю нервы? Наоборот, я развлекаюсь! Еще мне интересно на сколько хватит местного модератора меня почитывать. Любителя Графики и Научного Атеизма ес-но жалко, но что делать? Он мне разонравился за совершенно конкретные деяния.

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

[Massaew]

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

Здравствуйте.
Поделитесь опытом как наиболее безболезненно что ли перейти на ОС.

У меня мало опыта.
Первый мой проект был на MSP430F149. Тогда я только занакомился с МК и об ОС даже не задумывался. Он был простенький - я справился.

Второй (и текущий) на C167(+сетевушка реалтек).
Сначала это был интерфейс Ethernet-LPT, для управления некой аппаратурой с компа.
Я соорудил простенький TCP/IP стек.
Но потом стали добавлятся новые задачи, кот рушили мой "стройный" алгоритм.
Я решил что пора переходить к "системным вещам"

Что посоветуете?

[zltigo]

Что посоветуете?

Перейти к операционным системам . Простой и легкой методики лично мне не ведомо. Переходил много лет тому назад через написание от простых к более сложным операционок. Для ARMов не стал делать велосипед с нуля - выбрал в качестве отправной точки FreeRTOS, как наиболее соответствующую мому сложившему мировоззрению. Довольно много за 2-3 года работы поменял, но о выборе ее в качестве базы не пожалел ни разу.

[IgorKossak]

... как наиболее безболезненно что ли перейти на ОС.

Наиболее безболезненно это постепенно.
Очень стоит также почитать литературу об ОС вообще и о выбранной в частности. А также запустить у себя работающие примеры.

[Massaew]

Наиболее безболезненно это постепенно.
Очень стоит также почитать литературу об ОС вообще и о выбранной в частности.

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

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

Так что я хочу всетаки написать свою простенькую, "учебную" ОС.

Переходил много лет тому назад через написание от простых к более сложным операционок.

Вы я так понял тоже не сразу стали использовать гатовые ОС, а написали свои причем даже не только простые но и "более сложные".

Подскажите где найти материялы, кот помогли бы при написании ОС

[IgorKossak]

Подскажите где найти материялы, кот помогли бы при написании ОС

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

[ptolemy]

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

Подскажите где найти материялы, кот помогли бы при написании ОС

У нас студенты пишут такие штуки эпизодически. Присоединяйтесь http://embedded.ifmo.ru/index.php/project

Проект как раз недавно начался.

[Дон Амброзио]

на таком пути
человеков заносит куда-нибудь в "другую канаву" типа - "Как поставить Linux на ARM7" :-(

Некоторые чуть ли не Windows XP норовят поставить