IPB

Здравствуйте, гость ( Вход | Регистрация )

8 страниц V   1 2 3 > »   
Ответить в данную темуНачать новую тему
> RTOS во встроенных системах., Критерии применения.
Прохожий
сообщение 1.8.2010, 18:05
Сообщение #1


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Как и обещал открываю тему о RTOS во встроенных системах.
Сначала личное мнение о предмете спора.
По моему скромному мнению RTOS во встроенных системах не является необходимостью.
В большинстве применений можно обойтись имеющейся у большинства МК системой вложенных (или нет) приоритетных прерываний.
По моему мнению, лишний уровень абстракции между программой юзера и "железом" МК в виде RTOS не является необходимостью.
И вообще, представление программы в виде отдельных задач, подобных задачам PC - решение, требующее дополнительных оснований для применения.
Эти основания при решении определенного круга задач, безусловно, есть, но не для всех проектов такой подход обоснован.
ПМСМ, основные критерии к применению ОС следующие:
1. Работа над проектом коллектива разработчиков, слабо разбирающихся в смежных областях (механик и электрик, например).
2. Большой объем HMI, или наличие GUI.
3. Большое количество "дядиного" кода, выполненного под ту или иную RTOS.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 1.8.2010, 18:11
Сообщение #2


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



Вы не могли бы, для начала, раскрыть аббревиатуру RTOS?
Дико извиняюсь.. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 1.8.2010, 18:19
Сообщение #3


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(Wise @ 1.8.2010, 20:11) *
Вы не могли бы, для начала, раскрыть аббревиатуру RTOS?
Дико извиняюсь.. smile.gif

Real Time Operating System.
Операционная система реального времени.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 1.8.2010, 19:31
Сообщение #4


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



Цитата
Операционная система реального времени.

Не очень, пока, понятно.
Что это такое, например, в приложении к (пресловутому) PIC16F?
Для меня будет хорошо, если такой пример будет стоять в самом начале темы.

Может, еще такие же найдутся.. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 1.8.2010, 19:37
Сообщение #5


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(Wise @ 1.8.2010, 21:31) *
Не очень, пока. понятно.
Что это такое, например, в приложении к (пресловутому) PIC16F?
Для меня будет хорошо, если такой пример будет стоять в самом начале темы.

Может, еще такие же найдутся.. smile.gif

Лучше этого на русском языке вряд ли что найдется.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 1.8.2010, 19:47
Сообщение #6


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



Цитата(Прохожий @ 2.8.2010, 0:37) *
Лучше этого на русском языке вряд ли что найдется.

Зафиксировал, почитаю.
Спасибо.
Перейти в начало страницы
 
+Цитировать сообщение
Wise
сообщение 2.8.2010, 20:58
Сообщение #7


стажер
***

Группа: Пользователи
Сообщений: 871
Регистрация: 28.11.2009
Пользователь №: 36



..Маленький оффтоп, извините..
Я начинал заниматься Qt, даже вопрос задавал, на этом форуме.
Никто ничего не ответил.
Ну и я пока забросил (не потому, что не ответили, конечно.. smile.gif )
Прохожий, подобные дела входят ли в круг ваших интересов, планируете ли вы открыть раздел на такие темы?
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 2.8.2010, 21:28
Сообщение #8


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(Wise @ 2.8.2010, 22:58) *
..Маленький оффтоп, извините..
Я начинал заниматься Qt, даже вопрос задавал, на этом форуме.
Никто ничего не ответил.
Ну и я пока забросил (не потому, что не ответили, конечно.. smile.gif )
Прохожий, подобные дела входят ли в круг ваших интересов, планируете ли вы открыть раздел на такие темы?

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

Но, если кому будет интересен Qt, тогда пожалуйста без проблем.
Перейти в начало страницы
 
+Цитировать сообщение
one_man_show
сообщение 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. smile.gif
А были ли реального времени ОС на семействе 10хх? Мож портировать, не отдаваясь в руки современных ява/хтмл-программеров, попутнопейсателей RTOS?
Перейти в начало страницы
 
+Цитировать сообщение
one_man_show
сообщение 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



Цитата(MrYuran @ 3.8.2010, 9:48) *
И совсем другое дело:
Код
os_task ProcessCommand(PRIORITY_5)
{
    WaitForEvent(&PacketReceived);
    CheckPacketStructure(&InputBuffer);
    ExecuteCommand(&InputBuffer);
}

Ну, то, что Вы привели и задачей-то назвать сложно.
Это некая учебная запись.
Хотя суть понятна.
В моем случае все осложняется прерываниями.
Кроме этого, в Вашей записи есть функция ожидания события в явном виде.
Т. е. Ваша модель не событийная в общем случае.
Мне же ближе событийное программирование, базирующееся на системе приоритетных прерываний.
Ну и автоматы, безусловно.
К стати, в природе есть такие PLC.
В них в текущий момент времени работают только обработчики наступивших событий.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 3.8.2010, 17:15
Сообщение #14


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(one_man_show @ 3.8.2010, 13:34) *
На задачи раскладывать проще, когда заранее известны все возможные состояния системы. Кроме того, есть ОС РВ, которые сертифицированы для применений в критических средах, например uC/OS-II. используя ее ядро, можно хотя бы не беспокоиться о ее устойчивости и об отсутствии глюков. Некорректное использование и манипуляция задач могут привести к неверным результатам, но хоть не к краху всей системы...правда, об этом тоже придется отдельно позаботиться

Выделил в Вашем тексте главные слова, на мой взгляд.
Раз они сказаны, то тогда все ложится на автоматный подход к программированию.
В принципе, это доказано чисто математически...
Если его развивать, то становится очевидной ненужность РТОС, как таковой.
Поскольку вместо нее всегда можно применить событийный гиперавтомат, ложащийся непосредственно на архитектуру выбранного вычислителя (МК или МП).
Другой компот, что методология этого дела находится пока еще в стадии оформления.
Нет специальных языков. Хотя, в принципе, они есть. Но несколько в иной сфере.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 3.8.2010, 18:39
Сообщение #15





Гости






Цитата(Прохожий @ 3.8.2010, 19:06) *
Ну, то, что Вы привели и задачей-то назвать сложно.

Вполне себе реальная задача.
Ждёт эвента по принятию пакета, парсит и исполняет команду.
Таких задач может быть больше десятка, а то и двух, что сильно усложняет построение (а также последующую модификацию) автоматов, особенно при необходимости соблюдения приоритетов.
Цитата
В моем случае все осложняется прерываниями.

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

Ну, в конце концов, эта функция при отсутствии эвента может просто передать правление планировщику, равно как и sleep()

Перейти в начало страницы
 
+Цитировать сообщение
one_man_show
сообщение 3.8.2010, 21:18
Сообщение #16


Админ с Элха
***

Группа: Пользователи
Сообщений: 735
Регистрация: 28.7.2010
Из: Москва
Пользователь №: 188



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

Полностью согласен, но это возможно, когда задача вылиза и изучена вдоль и поперек. А на практике проще посадить одного-двух программистов и предложить решать задачу "традиционными" для задачи методами. Когда со временем все определено и понятно, уже по экономическим соображениям никто ничего не переделывает. Изучал прошивки множества различных устройств, везде виден почерк не программиста, а менеджера, который диктовал подход. А менеджеры в основном думают о минимизации затрат, а не о технических вопросах
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 3.8.2010, 21:39
Сообщение #17


сундук
***

Группа: Пользователи
Сообщений: 4043
Регистрация: 21.11.2009
Из: Ростов-на Дону
Пользователь №: 15



Цитата(MrYuran @ 3.8.2010, 20:39) *
Вполне себе реальная задача.
Ждёт эвента по принятию пакета, парсит и исполняет команду.
Таких задач может быть больше десятка, а то и двух, что сильно усложняет построение (а также последующую модификацию) автоматов, особенно при необходимости соблюдения приоритетов.

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

Ну, в конце концов, эта функция при отсутствии эвента может просто передать правление планировщику, равно как и sleep()

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

Цитата(one_man_show @ 3.8.2010, 23:18) *
Полностью согласен, но это возможно, когда задача вылиза и изучена вдоль и поперек.

ПМСМ, Вы здесь правы, но не совсем.
В принципе, все дело в привычке.
Если брать CPLD или FPGA, то там вообще все на автоматах.
И если сочетать МК и FPGA, то без РТОС как бы привычнее.
Или если идти от железа к софту.
Насчет вылизанности задачи тоже не согласен.
Основной скелет решения любой задачи всегда можно представить в виде автомата.
А убрать или добавить состояние и поправить функцию переходов, а так же входов и выходов несложно.
И потом.
В ООП-шном подходе при создании класса Вы, по-хорошему, должны заранее продумать гораздо больше, чем при автоматном.
Цитата(one_man_show @ 3.8.2010, 23:18) *
А на практике проще посадить одного-двух программистов и предложить решать задачу "традиционными" для задачи методами. Когда со временем все определено и понятно, уже по экономическим соображениям никто ничего не переделывает. Изучал прошивки множества различных устройств, везде виден почерк не программиста, а менеджера, который диктовал подход. А менеджеры в основном думают о минимизации затрат, а не о технических вопросах

Правильно. Это когда речь идет о больших системах.
Или о нереально малых временах.
Но программирование "в навал", без предварительной проработки алгоритмов и способов взаимодействия отдельных процессов лично мне не нравится.
Хотя бы потому, что я уже наелся результатами такого подхода, как человек, вынужденный обслуживать все это по долгу службы.
Перейти в начало страницы
 
+Цитировать сообщение
one_man_show
сообщение 4.8.2010, 10:49
Сообщение #18


Админ с Элха
***

Группа: Пользователи
Сообщений: 735
Регистрация: 28.7.2010
Из: Москва
Пользователь №: 188



Цитата
Правильно. Это когда речь идет о больших системах.
Или о нереально малых временах.

Я именно такие системы и имел в виду, так как с ними последнее время приходится больше сталкиваться. Прошу прощения, если не до конца правильно понял тему.

Относительно ПЛИС по своему опыту могу сказать, здесь тоже подходы меняются,мы сейчас в ПЛИС имплементируем ядро МК. Получается симбиоз, но в чистой части ПЛИС отпадает необходимость в автоматах, МК берет эту задачу на себя. Если пойти дальше, то в ядро МК можно встраивать ОС РВ. С одно стороны получается через одно место, проще использовать традиционные подходы, раз уж ПЛИС, то и автоматы. Но тут опять встревает практический опыт: экономически выгоднее использовать ПЛИС с ядром МК и с ОС РВ, та как для МК можно найти массу примеров реализации массы задач. Время выхода изделия уменьшается, что больше нравится менеджерам, будь они неладны.
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 4.8.2010, 11:54
Сообщение #19





Гости






Отличная статья про прототреды.
Для тех, кто не доверяет операционным системам
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 4.8.2010, 16:50
Сообщение #20


тот самый
Иконка группы

Группа: Мод
Сообщений: 13629
Регистрация: 24.11.2009
Из: Харьковская обл., UA
Пользователь №: 25



Цитата(MrYuran @ 4.8.2010, 12:54) *
Отличная статья про прототреды.
Для тех, кто не доверяет операционным системам

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),&param);}}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 - любит он иногда неоптимальностями плеваться.
В общем, после этих манипуляций с блокировкой, необязательно прям-таки выходить из каждой функции, сохраняя ея контекст, только на уровне драйверов. Если поток более высокого уровня - там уж можно и ждать события в цикле.
Правда, пожертвовать стеком немного нада...
Перейти в начало страницы
 
+Цитировать сообщение

8 страниц V   1 2 3 > » 
Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 29.3.2024, 7:38