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

[kichkine]

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

[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?