RTOS: распространенные заблуждения, Обсудим? |
Здравствуйте, гость ( Вход | Регистрация )
RTOS: распространенные заблуждения, Обсудим? |
5.1.2012, 18:55
Сообщение
#1
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Собственно - сабж.
|
|
|
5.1.2012, 19:23
Сообщение
#2
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
...зашибись тема...апять про домхвоны....))))
Цитата Оглянитесь вокруг: нас окружают десятки, сотни и тысячи разнообразных устройств. Попробуйте мысленно спроектировать программу для любого устройства дома: будильник, пульт д/у, музыкальный звонок, холодильник и т.д. Выйдите на улицу: светодиодные вывески над магазинчиками, сигнализации почти в каждом автомобиле, домофоны. Зайдите в магазин: кассовые аппараты, система освещения, турникет с магнитной рамкой.
|
|
|
5.1.2012, 19:37
Сообщение
#3
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
5.1.2012, 19:40
Сообщение
#4
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
|
|
|
5.1.2012, 19:48
Сообщение
#5
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
...про далесса с максимкой лень влезать...))) ...а тута само то... ...цытатник...))) Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное. Я бы хотел узнать, в чем по мнению окружающих, с автором статьи можно согласиться, а с чем можно поспорить в области применения RTOS. |
|
|
5.1.2012, 19:51
Сообщение
#6
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное. Я бы хотел узнать.... ...енто факт...мы с вами мыслим разными категориями....)))...лично мне более интересна личность Ю.Тёмкина ... http://www.tnkernel.com/about.html |
|
|
Гость_MrYuran_* |
5.1.2012, 20:40
Сообщение
#7
|
Гости |
По-моему, в настоящее время очень сузился круг задач и контроллеров, где было бы оправдано НЕприменение оси.
Хотя бы жалкого имитатора типа прототреда. Ртос - это инструмент. Такой же, как компилятор, как библиотеки итд. Позволяет программисту не отвлекаться на разную, извиняюсь, хню а делать СВОЮ работу. И не забивать голову лишними сущностями, которые уже давно и, главное, правильно реализованы в сервисах оси. С прискорбием отмечу, что у нас в конторе оси пока не применяются в боевых девайсах. Пришедший недавно молодой было поднял фриртос на мсп-шке, но тут срочно дали проект, давай-давай, быстрей-быстрей, никаких осей, делай как обычно, думать некогда... Ну и в результате занимается самой что ни на есть хней. "Как бы мне получше реализовать мигание символа при посисвольном вводе и при этом продолжать выполнять всю остальную работу"... |
|
|
5.1.2012, 20:46
Сообщение
#8
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Для начала, Вы не автор. При этом никак не обозначили своё мнение. Можно я выступлю чуть позже? Но это всё относится к эмбеддерным девайсам. Для девайсов, которые ближе к комповым системам (на АРМовых процах таких много) весы таки перевешивают в сторону РТОСов. И чаще всего наличие эзернета и разных протоколов тоже перевешивают в сторону РТОСов. Но наличие эзернетов и протоколов - это не RTOS. Это приложение к ней. Может существовать само по себе... Даже GUI может существовать немного в стороне от RTOS. Позволяет программисту не отвлекаться на разную, извиняюсь, хню а делать СВОЮ работу. И не забивать голову лишними сущностями, которые уже давно и, главное, правильно реализованы в сервисах оси. Вот и давайте поконкретнее о хне и лишних сущностях. Иными словами, какого уровня абстрагирования от железа и внешнего мира Вам не хватает? Что для Вас лишняя сущность? "Как бы мне получше реализовать мигание символа при посисвольном вводе и при этом продолжать выполнять всю остальную работу"... Это элементарно делается без всякой RTOS. |
|
|
5.1.2012, 20:58
Сообщение
#9
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
Попробую по пунктам. Профи в МК-программировании себя не считаю (просто жизнь заставила), поэтому можно и нужно пинать.
1. Смутил последний абзац: Цитата Разумеется, приведенные доводы не означают, что RTOS следует применять везде и всюду. Остается класс задач, где она помешает, но это уже за рамками постановки данного вопроса. А неплохо бы рассмотреть. 2,3. При ограниченных ресурсах абсолютный контроль, увы, необходим. Ситуацию усугубляет момент, когда МК выбирает не сам разработчик, а его начальство, на которое давят сверху, в основном из ценовых соображений. Так тоже бывает! Там не то что RTOS, даже на С не напишешь. Плавал два раза... в одном случае был ограничен 8 кБ (AT89S8252, довольно навороченная радиостанция), в другом - нечто 2-килобайтное, тоже 51, но шустрее в 6 раз и с очень приличной периферией (которая позволила втиснуть в 2 кБ то, что у других занимало почти всю память Меги8). Авантюра вообще-то, сознаю. Но продаётся. Потом переписал на C, тоже без ОС (флаговый автомат) - заняло, дай бог памяти, 2300 байт где-то, и все оптимизации до лампочки. Не влезло, короче. Извращение обратного плана - применение МК о 64 кБ флеши, которой было занято аж полтора, при этом никакой оптимизации не делалось. Просто в нём 2 уарта и 2 доллара стоит. Тривиальный перекодировщик протоколов, из китайского в общепонятный. Поднапрягшись, можно было слепить на тини 2313, благо один из уартов работает только на приём, а второй в полудуплексе (485)... или вообще обойтись без этого "костыля", перешив 48-ю мегу в китайском блэкбоксе (дней 10 попыхтеть - на это не пошли). 4. Ерунда. Знаком с "дядями", пишущими ОС, в случае чего не проблема спросить. 5. Проходили. Самодозванивающиеся автоответчики и тому подобное (ну забыли прибить неактуальную задачку). То скорей вопрос дисциплины. 6. Вкратце - улыбнуло. |
|
|
5.1.2012, 21:03
Сообщение
#10
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Гуй гуём - при чем тута ось?
Стеки протоколов - это единственный способ завлечь колеблющихся. А штука - в стандартизации. Если таковая не нужна - ось не нать и даром. |
|
|
5.1.2012, 21:26
Сообщение
#11
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Не согласен. ///большими буквами/// Делал несколько проектов, в которых много независимых алгоритмов (тредов). И делать их жерез опу желанием не горю. Я не хочу никого ни в чем упрекать. Каждый поступает так, как считает нужным. Но существует туева хуча способов организовать псевдопараллельность на последовательной машине. И для огромного количества процессов в том числе. РТОС - это всего лишь один из способов. Кто-то считает его единственно верным, а остальные через (_!_). Лично я с этим не согласен. |
|
|
5.1.2012, 21:42
Сообщение
#12
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Не согласен. ///большими буквами/// Делал несколько проектов, в которых много независимых алгоритмов (тредов). И делать их жерез опу желанием не горю. Ну и? Прикинул - у мну всё (99%) вертится над прототредами или над ими же с реалтаймовыми костылями . Необходимости в упорядочении способов передачи событий, мутексов итд не испытываю. |
|
|
5.1.2012, 21:53
Сообщение
#13
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Ну так давайте расставим все точки над ы. А то каждый останется при мнении "сам дурак" Какие удобные хучи есть, сравнимые с тредопереключалкой (не важно осевой или внеосевой)? Вы кстати собственноручно писали тредопереключалку? Я не знаю что это такое. У меня несколько иное представление об организации псевдопараллельности. Вкратце поясню. 1. МК со всеми своими потрохами воспринимается как готовая операционная среда. 2. Его система прерываний - это множество возможных событий в системе. 3. Вся совокупность задач - это множество внешних процессов, требующих обслуживания. 4. Множество задач и множество процессов могут не совпадать, потому как задача может требовать нескольких процессов. 5. Множество процессов - это гиперавтомат, состоящий из элементарных автоматов. 6. Каждый процесс в отдельности - элементарный автомат. 7. Смена состояний автоматов производится по событиям (см. п. 2). Естественно, это упрощенная схема, поскольку сюда накладывается динамическая смена приоритетов прерываний и еще много чего, зависящего от разных нюансов. Не будем забывать и о основном суперлупе, который тоже участвует в этом деле, если это требуется. |
|
|
5.1.2012, 22:56
Сообщение
#14
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
А разница между тем же и Фриртосей, например, какая? Название раздражает? Или спор тупо о наклейке "intel inside"? Дык я уже сказал: стандартизация. Например, стек тцп/ип, который настолько муторно перекраивать, он же еще и подминает под себя необходимость не возвращаться более к вопросам устроительства обмена сообщениями соотв. уровня сложности. Или, например, - нарастает что-то типа гуя и не факт, что я единолично буду этим заниматься. А в остальном мне оно не надо. Разве что удобства организации мониторинга ресурсов, но это для случая, когда управлять потреблением наряду с чем-либо серьёзным. Все. ЗЫ вот в металлодетектор, например, я бы ось впендюрил не задумываясь. |
|
|
5.1.2012, 23:43
Сообщение
#15
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
|
|
|
5.1.2012, 23:58
Сообщение
#16
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
|
|
|
6.1.2012, 9:47
Сообщение
#17
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Согласен со всеми пунктами полностью. Есть несколько случаев, когда, например, вытесняющая ось не катит. Это, очевидно, когда проц откровенно не тянет - есть определённый порог, ниже которого такую систему не поставить - просто элементарно не хватит памяти на контексты. Т.е. МК со 128 байтами ОЗУ под вытесняющую ОС никак не подойдёт. Правда, нынче в ценовой нише таких МК завелись камешки, в которых ось встаёт со свистом - 8К ОЗУ, 32К флеши, куча периферии и всё это удовольствие за цену порядка доллара! Трудно поверить, но это так.
Второй случай, где подобная ось не очень подходит - это когда программа содержит код, формирующий сигналы в жёстком реальном времени программно. Тут, понятно, ногодрыжество требуется в атомарном режиме, т.е. без прерываний, а вытесняющая ось активно юзает критические секции со всеми вытекающими. Но такой подход требует хорошего обоснования. Сигналы в жёстком реальном времени должны формироваться с помощью соответствующей аппаратной периферии МК, если это не так, то либо условия задачи какие-то очень специфичные, либо что-то в консерватории надо подправить. Что касается гуёв, стеков протоколов, файловых систем, то это вещи ортогональные по отношению к осям. Просто удобно эти задачи (особенно стеки протоколов) распределять по разным процессам - код получается более структурированным, прозрачным, переносимым и сопровождаемым. Насчёт того, что любую программу можно написать как угодно - это так. Вопрос только в цене - трудозатраты, и качестве полученного решения (та самая расширяемость, сопровождаемость, прозрачность кода) . Есть много прикладных задач, которые прекрасно ложатся на вытесняющий движок, и не очень хорошо реализуются на тех же автоматах. Например - не выдуманный пример, из моей практики: у меня уже лет 8 назад был проект, где надо было раз в 100 мс производить интенсивные вычисления с плавающей точкой (численное нахождение значения по измеренной величине от датчика угла), при этом ещё надо было обслуживать командный канал по UART'у и производить обновление динамическому индикатору - разряды переключать. Проц был MSP430F149, работал на 5 МГц, вычисления занимали порядка 20 мс. Т.е. процесс вычислений занимает процессор на весьма длительное время. Выбор был - либо распихать всё остальное, что требует более быстрой реакции (UART на 9600 - это порядка 1 мс период передачи символов, обновление индикатора - 250 Гц = 4 мс) в обработчики прерываний, либо использовать вытесняющую ось с приоритетным планированием процессов. С прерываниями решение простое, но не очень хорошее и красивое. Во-первых, некоторые задачи там иногда требовали значительного процессорного времени, поэтому тоже весьма желательно было бы перераспределять приоритетность выполнения, а контроллер прерываний в этом проце простейший одноуровневый. Во-вторых, для гарантированного времени отклика нужно было бы в обработчиках прерываний организовывать разрешение вложенных прерываний, и всё равно это решение корявое - например, нужно, чтобы одна задача могла прервать выполнение другой, более приоритетной, но не должна быть прерываемой третьей - менее приоритетной. Понятно, что с таким контроллером прерываний эту задачу не решить. Зато с вытесняющей осью целевая задача решается вообще без напрягов. Интенсивные вычисления помещаются низкоприоритетный процесс, остальные задачи распределяются по своим процессам. Код пишется независимо, и результирующее решение получается тривиальным, легко расширяемым и прозрачным. Без такой оси пришлось бы процесс вычислений разбивать на куски, обеспечивать их время выполнения не более определённого и т.д. - куча ручной работы, где всегда есть возможность что-то неверно рассчитать и нарушить целостность работы программы. Да, и код получается тут совсем не такой простой и прозрачный. Время на передачу управления в тех условиях (MSP430F149 @5MHz) составляло порядка 50 мкс (т.е., скажем, при возникновения события - байт прилетел в последовательный порт, поток управления окажется в коде, который должен обработать событие, через промежуток времени порядка 50 мкс, это гарантировано) . Подобная вытесняющая RTOS во многом аналогична аппаратному приоритетному контроллеру прерываний, но реализованная программно, поэтому имеет недостаток в виде накладных расходов и достоинство в виде большей гибкости. |
|
|
Гость_MrYuran_* |
6.1.2012, 11:17
Сообщение
#18
|
Гости |
Вкратце поясню. 1. МК со всеми своими потрохами воспринимается как готовая операционная среда. 2. Его система прерываний - это множество возможных событий в системе. 3. Вся совокупность задач - это множество внешних процессов, требующих обслуживания. Не всегда система прерываний конкретного контроллера отвечает требованиям задачи. Тем более, что сегодня железо одно, завтра другое, а бывает, что и одновременно разное. Цитата Естественно, это упрощенная схема, поскольку сюда накладывается динамическая смена приоритетов прерываний и еще много чего, зависящего от разных нюансов. Не будем забывать и о основном суперлупе, который тоже участвует в этом деле, если это требуется. Ось позволяет абстрагироваться от такого ненужного програмисту понятия, как поток инструкций и состедоточиться на алгоритме непосредственной задачи. То есть, в случае с тем же меню, видеть задачу глазами пользователя. Вывели картинку - ждем нажатия кнопки. Например, WaitForEvent() или что-то в этом роде. И мигание осуществлять тупым Sleep(500) |
|
|
7.1.2012, 11:42
Сообщение
#19
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Не всегда система прерываний конкретного контроллера отвечает требованиям задачи. Тем более, что сегодня железо одно, завтра другое, а бывает, что и одновременно разное. Ну, в этом плане я сам себе хозяин. А у Microchip-а всегда можно найти все, что нужно. Ось позволяет абстрагироваться от такого ненужного програмисту понятия, как поток инструкций и состедоточиться на алгоритме непосредственной задачи. То есть, в случае с тем же меню, видеть задачу глазами пользователя. Вывели картинку - ждем нажатия кнопки. Например, WaitForEvent() или что-то в этом роде. И мигание осуществлять тупым Sleep(500) Вот про это я и говорю и то же самое говорил автору статьи. Если Вам для сосредоточения на задаче нужна ОС, то мне это не требуется. Если Вам для осуществления замысла необходимо привести как задачу, так и архитектуру под какие-то удобные Вам, как программисту условия, то мне этого не нужно. Я умею приспосабливаться к любому сочетанию архитектура/набор задач без промежуточных прокладок в виде ОС. ОС - это сам МК. А отговорки в виде неподходящего под задачу МК попахивают дилетантизмом. Или еще хуже - нежеланием разбираться с его "железом". Простите, если кого обидел. Теперь про WaitForEvent() и Sleep(500). Я Вас удивлю. Но я так и делаю. Я довожу уровень абстракции от железа именно до этого состояния. Но несколько иным способом. Для этого существуют специальные глобальные битовые переменные. Blink500ms и RxEvent (сказывается тяжелое наследие PLC) Хотя, для меня не составит труда сделать и по-Вашему. И вообще - HAL существует и при моем подходе (куда же без него), но без ОС. И я не месил бы в кучу абстрагирование от железа и ОС. Зато с вытесняющей осью целевая задача решается вообще без напрягов. Приведенная Вами задача решена мною без всяких ОС на PIC18F при разработке терморегулятора с двухстрочным индикатором, кнопками и Modbus/RTU на RS485. Там как раз и было все, что Вами упомянуто. Плавающая запятая при расчете температуры по термо ЭДС, то же самое для ПИД, плюс к этому, линеаризация для фазового управления. Туда же была встроена проверка на коротыш и обрыв при включении тиристора. Ну и само фазовое управление для трехфазной сети без рабочего нуля. С учетом фильтрации моментов перехода через ноль каждой из фаз. Задача чудным образом решается исключительно с помощью автоматов и прерываний на МК всего лишь с двумя уровнями приоритетов. Контроллер приоритетов эмулируется непосредственно при программном поллинге флагов. Поверьте, это совсем незначительное количество команд на ASM-е. Подобная вытесняющая RTOS во многом аналогична аппаратному приоритетному контроллеру прерываний, но реализованная программно, поэтому имеет недостаток в виде накладных расходов и достоинство в виде большей гибкости. Ну и какой же тогда смысл в ОС, если у большинства современных МК это добро есть в аппаратном виде? А если, вдруг, нет, то это опять же Ваша недоработка. |
|
|
7.1.2012, 12:21
Сообщение
#20
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
|
|
|
Текстовая версия | Сейчас: 28.3.2024, 14:51 |