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

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

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

[syv 0]

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

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

[Artem-1.6E-19 0]

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

Я не понял что вы написали. Вы написали конечного много, но я ниасилил.

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

 

Так что. 1. Практика. И теория для того чтобы понять как работает практика. Именно так всегда двигалась наука. Сначала - эксперимент - потом теория его объясняющая. Так и нужно учится.

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

[akivas 0]

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

 

 

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

 

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

 

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

 

 

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

 

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

 

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

[st256 0]

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

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

 

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

 

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

 

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

[Artem-1.6E-19 0]

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

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

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

 

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

[syv 0]

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

 

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

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

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

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

Далее следует описание системы поддержания коэффициента мощности на максимальном уровне при изменении реактивной мощности, потребляемой преобразователями. Присутствует и простая мат. модель.

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

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

Вот название учебника.

Горбачев В. Г., Чаплыгин Е. Е. Промышленная электроника: Учебник для вузов/ Под ред. В. А. Лабунцова. - М.: Энергоатомиздат, 1988 - 320 с.: ил.

Вам может понадобиться глава 7 и в частности параграф 7.3 на стр. 269.

[zltigo 1]

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

 

P.S.

Может стоит ее перименовать в "Зачем попу гармонь", ну или

"Критерии использования RTOS служителями культа при отправлении обрядов"?

[st256 0]

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

 

P.S.

Может стоит ее перименовать в "Зачем попу гармонь", ну или

"Критерии использования RTOS служителями культа при отправлении обрядов"?

 

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

 

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

Далее следует описание системы поддержания коэффициента мощности на максимальном уровне при изменении реактивной мощности, потребляемой преобразователями. Присутствует и простая мат. модель.

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

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

Вот название учебника.

Горбачев В. Г., Чаплыгин Е. Е. Промышленная электроника: Учебник для вузов/ Под ред. В. А. Лабунцова. - М.: Энергоатомиздат, 1988 - 320 с.: ил.

Вам может понадобиться глава 7 и в частности параграф 7.3 на стр. 269.

 

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

убираем четные (симметричный относительно нуля сигнал) и кратные трем. Остаются всего четыре:

 

5,7,11,13

 

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

[syv 0]

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

 

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

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

 

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

 

 

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

 

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

[Artem-1.6E-19 0]

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

 

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

[syv 0]

Интересно. Часто 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 0]

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

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

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

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

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

[syv 0]

Нет. Это часто просто кусок уже написаной программы. Зачем писать то, что уже неписано. Разумеется, 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 0]

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

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

 

 

Ну? Я в порте для АВР нашел. И что с того?

А во-вторых, зачем мне кусок ничего не делающей программы, которая не решает ни одной из поставленных задач?

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

 

 

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

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

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

Согласен.

 

 

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

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

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

 

 

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

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

 

 

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

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

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

 

 

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

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

 

 

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

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

Занимает.

 

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

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

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

 

 

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

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

Согласен. Но операционку тоже можно использовать.

 

 

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

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

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

 

 

 

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

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

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

 

 

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

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

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

 

 

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

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

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

 

 

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

Изменено 10 декабря, 2006 пользователем Artem-1.6E-19