RTOS во встроенных системах., Критерии применения. |
Здравствуйте, гость ( Вход | Регистрация )
RTOS во встроенных системах., Критерии применения. |
1.8.2010, 18:05
Сообщение
#1
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Как и обещал открываю тему о RTOS во встроенных системах.
Сначала личное мнение о предмете спора. По моему скромному мнению RTOS во встроенных системах не является необходимостью. В большинстве применений можно обойтись имеющейся у большинства МК системой вложенных (или нет) приоритетных прерываний. По моему мнению, лишний уровень абстракции между программой юзера и "железом" МК в виде RTOS не является необходимостью. И вообще, представление программы в виде отдельных задач, подобных задачам PC - решение, требующее дополнительных оснований для применения. Эти основания при решении определенного круга задач, безусловно, есть, но не для всех проектов такой подход обоснован. ПМСМ, основные критерии к применению ОС следующие: 1. Работа над проектом коллектива разработчиков, слабо разбирающихся в смежных областях (механик и электрик, например). 2. Большой объем HMI, или наличие GUI. 3. Большое количество "дядиного" кода, выполненного под ту или иную RTOS. |
|
|
1.8.2010, 18:11
Сообщение
#2
|
|
стажер Группа: Пользователи Сообщений: 871 Регистрация: 28.11.2009 Пользователь №: 36 |
Вы не могли бы, для начала, раскрыть аббревиатуру RTOS?
Дико извиняюсь.. |
|
|
1.8.2010, 18:19
Сообщение
#3
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
1.8.2010, 19:31
Сообщение
#4
|
|
стажер Группа: Пользователи Сообщений: 871 Регистрация: 28.11.2009 Пользователь №: 36 |
Цитата Операционная система реального времени. Не очень, пока, понятно. Что это такое, например, в приложении к (пресловутому) PIC16F? Для меня будет хорошо, если такой пример будет стоять в самом начале темы. Может, еще такие же найдутся.. |
|
|
1.8.2010, 19:37
Сообщение
#5
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Не очень, пока. понятно. Что это такое, например, в приложении к (пресловутому) PIC16F? Для меня будет хорошо, если такой пример будет стоять в самом начале темы. Может, еще такие же найдутся.. Лучше этого на русском языке вряд ли что найдется. |
|
|
1.8.2010, 19:47
Сообщение
#6
|
|
стажер Группа: Пользователи Сообщений: 871 Регистрация: 28.11.2009 Пользователь №: 36 |
|
|
|
2.8.2010, 20:58
Сообщение
#7
|
|
стажер Группа: Пользователи Сообщений: 871 Регистрация: 28.11.2009 Пользователь №: 36 |
..Маленький оффтоп, извините..
Я начинал заниматься Qt, даже вопрос задавал, на этом форуме. Никто ничего не ответил. Ну и я пока забросил (не потому, что не ответили, конечно.. ) Прохожий, подобные дела входят ли в круг ваших интересов, планируете ли вы открыть раздел на такие темы? |
|
|
2.8.2010, 21:28
Сообщение
#8
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
..Маленький оффтоп, извините.. Я начинал заниматься Qt, даже вопрос задавал, на этом форуме. Никто ничего не ответил. Ну и я пока забросил (не потому, что не ответили, конечно.. ) Прохожий, подобные дела входят ли в круг ваших интересов, планируете ли вы открыть раздел на такие темы? Я пользуюсь Борландовским Билдером. Нынче он официально бесплатный. Для него есть масса всего. Даже кросс-платформенность декларируется. Основное его преимущество - пакет специально создавался для тупых, типа меня. Простейшие приложения делаются практически сразу. А те, что посложнее через неделю. И Архангельский нам всем в помощь... Но, если кому будет интересен Qt, тогда пожалуйста без проблем. |
|
|
2.8.2010, 21:39
Сообщение
#9
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Использую ОС РВ только в тех проектах, где много параллельных или псеводопараллельных задач, причем когда время жизни данных сильно отличается. Например, в одном треде нужно считать таймаут или задержку какую-нибудь, время которой кратно миллисекундам. В другом треде нужно принимать данные из АЦП, проверять уровень сигнала и по тому или иному уровни выставлять разные флаги. В третьем треде проверяем нажатие клавишь. В четвертом ждем звонок...Это небольшой пример того, как работает например мобильник Моторола Мини Так. В свое время приходилось хакать, это та трубка, у которой откидушка была и антенна выдвижная.
|
|
|
Гость_MrYuran_* |
3.8.2010, 7:48
Сообщение
#10
|
Гости |
Реал тайм он как бы не всегда и нужен, в большинстве проектов достаточно кооперативной многозадачности (естественно, при правильной организации, никаких там пауз типа _delay_cycles(10000) ). У меня пока вообще простая каруселька, даже без приоритетов.
Однако, когда задач много, а времени мало, всё-таки организованная система даёт большую наглядность и удобство. Пусть даже это не РТОС, а просто планировщик, наподобие Protothreads, который Pasha по любому случаю пеарит. Конечно, можно всё на автоматах и флагах построить, но когда их (флагов и соответственно состояний) десятки, то очень трудно становится ориентироваться. Может, и не очень, и не так уж и трудно, но всё равно испытываешь дискомфорт, роясь в многоэтажных конструкциях наподобие стихов Маяковского. И совсем другое дело: Код os_task ProcessCommand(PRIORITY_5)
{ WaitForEvent(&PacketReceived); CheckPacketStructure(&InputBuffer); ExecuteCommand(&InputBuffer); } |
|
|
Гость_Максим Зиновьев_* |
3.8.2010, 8:23
Сообщение
#11
|
Гости |
Вспомнились ЕС-10хх, которые слабо отличаются от современных mcu.
А были ли реального времени ОС на семействе 10хх? Мож портировать, не отдаваясь в руки современных ява/хтмл-программеров, попутнопейсателей RTOS? |
|
|
3.8.2010, 11:34
Сообщение
#12
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
ГетСмарт, для Вас поясню ОС РВ - Операционные Системы реального Времени, это в нашей практике то же самое, что у буржуев RTOS - Real Time Operating System. Если есть желание обсудить меня, создавайте тему в соответствующем разделе.
На задачи раскладывать проще, когда заранее известны все возможные состояния системы. Кроме того, есть ОС РВ, которые сертифицированы для применений в критических средах, например uC/OS-II. используя ее ядро, можно хотя бы не беспокоиться о ее устойчивости и об отсутствии глюков. Некорректное использование и манипуляция задач могут привести к неверным результатам, но хоть не к краху всей системы...правда, об этом тоже придется отдельно позаботиться |
|
|
3.8.2010, 17:06
Сообщение
#13
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
И совсем другое дело: Код os_task ProcessCommand(PRIORITY_5) { WaitForEvent(&PacketReceived); CheckPacketStructure(&InputBuffer); ExecuteCommand(&InputBuffer); } Ну, то, что Вы привели и задачей-то назвать сложно. Это некая учебная запись. Хотя суть понятна. В моем случае все осложняется прерываниями. Кроме этого, в Вашей записи есть функция ожидания события в явном виде. Т. е. Ваша модель не событийная в общем случае. Мне же ближе событийное программирование, базирующееся на системе приоритетных прерываний. Ну и автоматы, безусловно. К стати, в природе есть такие PLC. В них в текущий момент времени работают только обработчики наступивших событий. |
|
|
3.8.2010, 17:15
Сообщение
#14
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
На задачи раскладывать проще, когда заранее известны все возможные состояния системы. Кроме того, есть ОС РВ, которые сертифицированы для применений в критических средах, например uC/OS-II. используя ее ядро, можно хотя бы не беспокоиться о ее устойчивости и об отсутствии глюков. Некорректное использование и манипуляция задач могут привести к неверным результатам, но хоть не к краху всей системы...правда, об этом тоже придется отдельно позаботиться Выделил в Вашем тексте главные слова, на мой взгляд. Раз они сказаны, то тогда все ложится на автоматный подход к программированию. В принципе, это доказано чисто математически... Если его развивать, то становится очевидной ненужность РТОС, как таковой. Поскольку вместо нее всегда можно применить событийный гиперавтомат, ложащийся непосредственно на архитектуру выбранного вычислителя (МК или МП). Другой компот, что методология этого дела находится пока еще в стадии оформления. Нет специальных языков. Хотя, в принципе, они есть. Но несколько в иной сфере. |
|
|
Гость_MrYuran_* |
3.8.2010, 18:39
Сообщение
#15
|
Гости |
Ну, то, что Вы привели и задачей-то назвать сложно. Вполне себе реальная задача. Ждёт эвента по принятию пакета, парсит и исполняет команду. Таких задач может быть больше десятка, а то и двух, что сильно усложняет построение (а также последующую модификацию) автоматов, особенно при необходимости соблюдения приоритетов. Цитата В моем случае все осложняется прерываниями. Обычно прерывания упрощают жизнь, а не усложняют. Например, заполнение буфера происходит по прерываниям, совершенно параллельно и незаметно для основного приложения Цитата Кроме этого, в Вашей записи есть функция ожидания события в явном виде. Т. е. Ваша модель не событийная в общем случае. Ну, в конце концов, эта функция при отсутствии эвента может просто передать правление планировщику, равно как и sleep() |
|
|
3.8.2010, 21:18
Сообщение
#16
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Цитата Выделил в Вашем тексте главные слова, на мой взгляд. Раз они сказаны, то тогда все ложится на автоматный подход к программированию. В принципе, это доказано чисто математически... Если его развивать, то становится очевидной ненужность РТОС, как таковой. Поскольку вместо нее всегда можно применить событийный гиперавтомат, ложащийся непосредственно на архитектуру выбранного вычислителя (МК или МП). Полностью согласен, но это возможно, когда задача вылиза и изучена вдоль и поперек. А на практике проще посадить одного-двух программистов и предложить решать задачу "традиционными" для задачи методами. Когда со временем все определено и понятно, уже по экономическим соображениям никто ничего не переделывает. Изучал прошивки множества различных устройств, везде виден почерк не программиста, а менеджера, который диктовал подход. А менеджеры в основном думают о минимизации затрат, а не о технических вопросах |
|
|
3.8.2010, 21:39
Сообщение
#17
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Вполне себе реальная задача. Ждёт эвента по принятию пакета, парсит и исполняет команду. Таких задач может быть больше десятка, а то и двух, что сильно усложняет построение (а также последующую модификацию) автоматов, особенно при необходимости соблюдения приоритетов. Обычно прерывания упрощают жизнь, а не усложняют. Например, заполнение буфера происходит по прерываниям, совершенно параллельно и незаметно для основного приложения Ну, в конце концов, эта функция при отсутствии эвента может просто передать правление планировщику, равно как и sleep() Вы сейчас излагаете вполне нормальный подход. И он вполне обоснован для больших систем. Но здесь у Вас стилистические противоречия. Это что, обработчик события заполнения буфера? Тогда вызов функции ожидания события алогичен. Это как бы должно подразумеваться. И чтобы быть до конца правильными, необходимо предъявить код приемника сообщения. Полностью согласен, но это возможно, когда задача вылиза и изучена вдоль и поперек. ПМСМ, Вы здесь правы, но не совсем. В принципе, все дело в привычке. Если брать CPLD или FPGA, то там вообще все на автоматах. И если сочетать МК и FPGA, то без РТОС как бы привычнее. Или если идти от железа к софту. Насчет вылизанности задачи тоже не согласен. Основной скелет решения любой задачи всегда можно представить в виде автомата. А убрать или добавить состояние и поправить функцию переходов, а так же входов и выходов несложно. И потом. В ООП-шном подходе при создании класса Вы, по-хорошему, должны заранее продумать гораздо больше, чем при автоматном. А на практике проще посадить одного-двух программистов и предложить решать задачу "традиционными" для задачи методами. Когда со временем все определено и понятно, уже по экономическим соображениям никто ничего не переделывает. Изучал прошивки множества различных устройств, везде виден почерк не программиста, а менеджера, который диктовал подход. А менеджеры в основном думают о минимизации затрат, а не о технических вопросах Правильно. Это когда речь идет о больших системах. Или о нереально малых временах. Но программирование "в навал", без предварительной проработки алгоритмов и способов взаимодействия отдельных процессов лично мне не нравится. Хотя бы потому, что я уже наелся результатами такого подхода, как человек, вынужденный обслуживать все это по долгу службы. |
|
|
4.8.2010, 10:49
Сообщение
#18
|
|
Админ с Элха Группа: Пользователи Сообщений: 735 Регистрация: 28.7.2010 Из: Москва Пользователь №: 188 |
Цитата Правильно. Это когда речь идет о больших системах. Или о нереально малых временах. Я именно такие системы и имел в виду, так как с ними последнее время приходится больше сталкиваться. Прошу прощения, если не до конца правильно понял тему. Относительно ПЛИС по своему опыту могу сказать, здесь тоже подходы меняются,мы сейчас в ПЛИС имплементируем ядро МК. Получается симбиоз, но в чистой части ПЛИС отпадает необходимость в автоматах, МК берет эту задачу на себя. Если пойти дальше, то в ядро МК можно встраивать ОС РВ. С одно стороны получается через одно место, проще использовать традиционные подходы, раз уж ПЛИС, то и автоматы. Но тут опять встревает практический опыт: экономически выгоднее использовать ПЛИС с ядром МК и с ОС РВ, та как для МК можно найти массу примеров реализации массы задач. Время выхода изделия уменьшается, что больше нравится менеджерам, будь они неладны. |
|
|
Гость_MrYuran_* |
4.8.2010, 11:54
Сообщение
#19
|
Гости |
Отличная статья про прототреды.
Для тех, кто не доверяет операционным системам |
|
|
4.8.2010, 16:50
Сообщение
#20
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Отличная статья про прототреды. Для тех, кто не доверяет операционным системам 1. Без гнусной фичи работы с метками, оно не на всех компилерах работает - switch не всегда превращается в таблицу переходов. Тоже геморрой. 2. Сами по себе прототреды - это уже не удивительно. Удивительно, как систему можно "прятать" в функцию idle() - обеспечивая при этом блокировку повторного вызова функций-тредов. Вот этим я и начал пользоваться в последнее время Код #define Thread_Pure(name,pc) void *name(void *pc) __attribute__((noinline)) #define Thread_Pure_Def(name,pc) void *name(void *pc) #define Run_Thread_Pure(name) do{static void *pc=NULL; if(pc != &name){pc = name(lock(&pc,&name));}}while(0); #define Run_Thread(name,param) do{static void *pc=NULL; if(pc != &name){pc = name(lock(&pc,&name),¶m);}}while(0); static void *lock(void **ppc,const void *pfunc) __attribute__((noinline)); static void *lock(void **ppc,const void *pfunc) { void *ptr = *ppc; *ppc = pfunc; return ptr; } Специально подточено под WinAVR - любит он иногда неоптимальностями плеваться. В общем, после этих манипуляций с блокировкой, необязательно прям-таки выходить из каждой функции, сохраняя ея контекст, только на уровне драйверов. Если поток более высокого уровня - там уж можно и ждать события в цикле. Правда, пожертвовать стеком немного нада... |
|
|
Текстовая версия | Сейчас: 29.3.2024, 7:38 |