Критерии перехода к 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?

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

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