IPB

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

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


сундук
***

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



Собственно - сабж.
Перейти в начало страницы
 
+Цитировать сообщение
Secter
сообщение 5.1.2012, 19:23
Сообщение #2


Активный участник
***

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



biggrin.gif ...зашибись тема...апять про домхвоны....))))
Цитата
Оглянитесь вокруг: нас окружают десятки, сотни и тысячи разнообразных устройств. Попробуйте мысленно спроектировать программу для любого устройства дома: будильник, пульт д/у, музыкальный звонок, холодильник и т.д. Выйдите на улицу: светодиодные вывески над магазинчиками, сигнализации почти в каждом автомобиле, домофоны. Зайдите в магазин: кассовые аппараты, система освещения, турникет с магнитной рамкой.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 5.1.2012, 19:37
Сообщение #3


сундук
***

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



Цитата(Secter @ 5.1.2012, 20:23) *
biggrin.gif ...зашибись тема...апять про домхвоны....))))

Кому что, а голодный про сранье.
Перейти в начало страницы
 
+Цитировать сообщение
Secter
сообщение 5.1.2012, 19:40
Сообщение #4


Активный участник
***

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



Цитата(Прохожий @ 5.1.2012, 20:37) *
Кому что, а голодный про сранье.

smile.gif...про далесса с максимкой лень влезать...))) ...а тута само то... pardon.gif ...цытатник...)))
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 5.1.2012, 19:48
Сообщение #5


сундук
***

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



Цитата(Secter @ 5.1.2012, 20:40) *
smile.gif...про далесса с максимкой лень влезать...))) ...а тута само то... pardon.gif ...цытатник...)))

Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное.
Я бы хотел узнать, в чем по мнению окружающих, с автором статьи можно согласиться, а с чем можно поспорить в области применения RTOS.
Перейти в начало страницы
 
+Цитировать сообщение
Secter
сообщение 5.1.2012, 19:51
Сообщение #6


Активный участник
***

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



Цитата(Прохожий @ 5.1.2012, 19:48) *
Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное.
Я бы хотел узнать....

smile.gif ...енто факт...мы с вами мыслим разными категориями....)))...лично мне более интересна личность Ю.Тёмкина ... pardon.gif http://www.tnkernel.com/about.html
Перейти в начало страницы
 
+Цитировать сообщение
Гость_MrYuran_*
сообщение 5.1.2012, 20:40
Сообщение #7





Гости






По-моему, в настоящее время очень сузился круг задач и контроллеров, где было бы оправдано НЕприменение оси.
Хотя бы жалкого имитатора типа прототреда.
Ртос - это инструмент. Такой же, как компилятор, как библиотеки итд.
Позволяет программисту не отвлекаться на разную, извиняюсь, хню а делать СВОЮ работу. И не забивать голову лишними сущностями, которые уже давно и, главное, правильно реализованы в сервисах оси.
С прискорбием отмечу, что у нас в конторе оси пока не применяются в боевых девайсах.
Пришедший недавно молодой было поднял фриртос на мсп-шке, но тут срочно дали проект, давай-давай, быстрей-быстрей, никаких осей, делай как обычно, думать некогда...
Ну и в результате занимается самой что ни на есть хней.
"Как бы мне получше реализовать мигание символа при посисвольном вводе и при этом продолжать выполнять всю остальную работу"...
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 5.1.2012, 20:46
Сообщение #8


сундук
***

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



Цитата(GuruKiller @ 5.1.2012, 21:08) *
Для начала, Вы не автор. При этом никак не обозначили своё мнение.

Можно я выступлю чуть позже?
Цитата(GuruKiller @ 5.1.2012, 21:08) *
Но это всё относится к эмбеддерным девайсам. Для девайсов, которые ближе к комповым системам (на АРМовых процах таких много) весы таки перевешивают в сторону РТОСов. И чаще всего наличие эзернета и разных протоколов тоже перевешивают в сторону РТОСов.

Но наличие эзернетов и протоколов - это не RTOS. Это приложение к ней.
Может существовать само по себе...
Даже GUI может существовать немного в стороне от RTOS.

Цитата(MrYuran @ 5.1.2012, 21:40) *
Позволяет программисту не отвлекаться на разную, извиняюсь, хню а делать СВОЮ работу. И не забивать голову лишними сущностями, которые уже давно и, главное, правильно реализованы в сервисах оси.

Вот и давайте поконкретнее о хне и лишних сущностях.
Иными словами, какого уровня абстрагирования от железа и внешнего мира Вам не хватает?
Что для Вас лишняя сущность?
Цитата(MrYuran @ 5.1.2012, 21:40) *
"Как бы мне получше реализовать мигание символа при посисвольном вводе и при этом продолжать выполнять всю остальную работу"...

Это элементарно делается без всякой RTOS.
Перейти в начало страницы
 
+Цитировать сообщение
Harbinger
сообщение 5.1.2012, 20:58
Сообщение #9


посіпака Хунти
Иконка группы

Группа: Мод
Сообщений: 16061
Регистрация: 21.11.2009
Из: Vinnitsa
Пользователь №: 11



Попробую по пунктам. Профи в МК-программировании себя не считаю (просто жизнь заставила), поэтому можно и нужно пинать.
1. Смутил последний абзац:
Цитата
Разумеется, приведенные доводы не означают, что RTOS следует применять везде и всюду. Остается класс задач, где она помешает, но это уже за рамками постановки данного вопроса.

А неплохо бы рассмотреть.
2,3. При ограниченных ресурсах абсолютный контроль, увы, необходим. Ситуацию усугубляет момент, когда МК выбирает не сам разработчик, а его начальство, на которое давят сверху, в основном из ценовых соображений. Так тоже бывает! diablo.gif
Там не то что RTOS, даже на С не напишешь. Плавал два раза... в одном случае был ограничен 8 кБ (AT89S8252, довольно навороченная радиостанция), в другом - нечто 2-килобайтное, тоже 51, но шустрее в 6 раз и с очень приличной периферией (которая позволила втиснуть в 2 кБ то, что у других занимало почти всю память Меги8). Авантюра вообще-то, сознаю. Но продаётся. Потом переписал на C, тоже без ОС (флаговый автомат) - заняло, дай бог памяти, 2300 байт где-то, и все оптимизации до лампочки. Не влезло, короче.
Извращение обратного плана - применение МК о 64 кБ флеши, которой было занято аж полтора, при этом никакой оптимизации не делалось. Просто в нём 2 уарта и 2 доллара стоит. Тривиальный перекодировщик протоколов, из китайского в общепонятный. Поднапрягшись, можно было слепить на тини 2313, благо один из уартов работает только на приём, а второй в полудуплексе (485)... или вообще обойтись без этого "костыля", перешив 48-ю мегу в китайском блэкбоксе (дней 10 попыхтеть - на это не пошли).
4. Ерунда. Знаком с "дядями", пишущими ОС, в случае чего не проблема спросить.
5. Проходили. Самодозванивающиеся автоответчики и тому подобное (ну забыли прибить неактуальную задачку). То скорей вопрос дисциплины.
6. Вкратце - улыбнуло. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 5.1.2012, 21:03
Сообщение #10


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

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



Гуй гуём - при чем тута ось?
Стеки протоколов - это единственный способ завлечь колеблющихся.
А штука - в стандартизации. Если таковая не нужна - ось не нать и даром.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 5.1.2012, 21:26
Сообщение #11


сундук
***

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



Цитата(GuruKiller @ 5.1.2012, 22:04) *
Не согласен. ///большими буквами///

Делал несколько проектов, в которых много независимых алгоритмов (тредов). И делать их жерез опу желанием не горю.

Я не хочу никого ни в чем упрекать.
Каждый поступает так, как считает нужным.
Но существует туева хуча способов организовать псевдопараллельность на последовательной машине.
И для огромного количества процессов в том числе.
РТОС - это всего лишь один из способов.
Кто-то считает его единственно верным, а остальные через (_!_).
Лично я с этим не согласен.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 5.1.2012, 21:42
Сообщение #12


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

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



Цитата(GuruKiller @ 5.1.2012, 21:04) *
Не согласен. ///большими буквами///
Делал несколько проектов, в которых много независимых алгоритмов (тредов). И делать их жерез опу желанием не горю.

Ну и? Прикинул - у мну всё (99%) вертится над прототредами или над ими же с реалтаймовыми костылями . Необходимости в упорядочении способов передачи событий, мутексов итд не испытываю.
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 5.1.2012, 21:53
Сообщение #13


сундук
***

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



Цитата(GuruKiller @ 5.1.2012, 22:31) *
Ну так давайте расставим все точки над ы. А то каждый останется при мнении "сам дурак" smile.gif
Какие удобные хучи есть, сравнимые с тредопереключалкой (не важно осевой или внеосевой)?

Вы кстати собственноручно писали тредопереключалку?

Я не знаю что это такое.
У меня несколько иное представление об организации псевдопараллельности.
Вкратце поясню.
1. МК со всеми своими потрохами воспринимается как готовая операционная среда.
2. Его система прерываний - это множество возможных событий в системе.
3. Вся совокупность задач - это множество внешних процессов, требующих обслуживания.
4. Множество задач и множество процессов могут не совпадать, потому как задача может требовать нескольких процессов.
5. Множество процессов - это гиперавтомат, состоящий из элементарных автоматов.
6. Каждый процесс в отдельности - элементарный автомат.
7. Смена состояний автоматов производится по событиям (см. п. 2).
Естественно, это упрощенная схема, поскольку сюда накладывается динамическая смена приоритетов прерываний и еще много чего, зависящего от разных нюансов.
Не будем забывать и о основном суперлупе, который тоже участвует в этом деле, если это требуется.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 5.1.2012, 22:56
Сообщение #14


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

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



Цитата(GuruKiller @ 5.1.2012, 21:50) *
А разница между тем же и Фриртосей, например, какая? Название раздражает? Или спор тупо о наклейке "intel inside"?

Дык я уже сказал: стандартизация. Например, стек тцп/ип, который настолько муторно перекраивать, он же еще и подминает под себя необходимость не возвращаться более к вопросам устроительства обмена сообщениями соотв. уровня сложности. Или, например, - нарастает что-то типа гуя и не факт, что я единолично буду этим заниматься. А в остальном мне оно не надо. Разве что удобства организации мониторинга ресурсов, но это для случая, когда управлять потреблением наряду с чем-либо серьёзным. Все. pardon.gif
ЗЫ вот в металлодетектор, например, я бы ось впендюрил не задумываясь.
Перейти в начало страницы
 
+Цитировать сообщение
Harbinger
сообщение 5.1.2012, 23:43
Сообщение #15


посіпака Хунти
Иконка группы

Группа: Мод
Сообщений: 16061
Регистрация: 21.11.2009
Из: Vinnitsa
Пользователь №: 11



Цитата(_pasha @ 5.1.2012, 22:56) *
ЗЫ вот в металлодетектор, например, я бы ось впендюрил не задумываясь.

В рыбоэхолоте тоже не помешает. smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 5.1.2012, 23:58
Сообщение #16


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

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



Цитата(Harbinger @ 5.1.2012, 23:43) *
В рыбоэхолоте тоже не помешает. smile.gif

А в такие вещи, как ПЛК - ось нужна, начиная с того момента, как идет работа с CAN и ETHERNET. Вывод - чтоы объять большую линейку изделий, лучше пересаживаться на плюсы и оборачивать в классы возможную ось.
Перейти в начало страницы
 
+Цитировать сообщение
dxp
сообщение 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





Гости






Цитата(Прохожий @ 5.1.2012, 23:53) *
Вкратце поясню.
1. МК со всеми своими потрохами воспринимается как готовая операционная среда.
2. Его система прерываний - это множество возможных событий в системе.
3. Вся совокупность задач - это множество внешних процессов, требующих обслуживания.

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

Ось позволяет абстрагироваться от такого ненужного програмисту понятия, как поток инструкций и состедоточиться на алгоритме непосредственной задачи.
То есть, в случае с тем же меню, видеть задачу глазами пользователя.
Вывели картинку - ждем нажатия кнопки.
Например, WaitForEvent() или что-то в этом роде.
И мигание осуществлять тупым Sleep(500)
Перейти в начало страницы
 
+Цитировать сообщение
Прохожий
сообщение 7.1.2012, 11:42
Сообщение #19


сундук
***

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



Цитата(MrYuran @ 6.1.2012, 13:17) *
Не всегда система прерываний конкретного контроллера отвечает требованиям задачи.
Тем более, что сегодня железо одно, завтра другое, а бывает, что и одновременно разное.

Ну, в этом плане я сам себе хозяин.
А у Microchip-а всегда можно найти все, что нужно.
Цитата(MrYuran @ 6.1.2012, 13:17) *
Ось позволяет абстрагироваться от такого ненужного програмисту понятия, как поток инструкций и состедоточиться на алгоритме непосредственной задачи.
То есть, в случае с тем же меню, видеть задачу глазами пользователя.
Вывели картинку - ждем нажатия кнопки.
Например, WaitForEvent() или что-то в этом роде.
И мигание осуществлять тупым Sleep(500)

Вот про это я и говорю и то же самое говорил автору статьи.
Если Вам для сосредоточения на задаче нужна ОС, то мне это не требуется.
Если Вам для осуществления замысла необходимо привести как задачу, так и архитектуру под какие-то удобные Вам, как программисту условия, то мне этого не нужно.
Я умею приспосабливаться к любому сочетанию архитектура/набор задач без промежуточных прокладок в виде ОС.
ОС - это сам МК.
А отговорки в виде неподходящего под задачу МК попахивают дилетантизмом.
Или еще хуже - нежеланием разбираться с его "железом".
Простите, если кого обидел.
Теперь про WaitForEvent() и Sleep(500).
Я Вас удивлю. Но я так и делаю.
Я довожу уровень абстракции от железа именно до этого состояния.
Но несколько иным способом.
Для этого существуют специальные глобальные битовые переменные.
Blink500ms и RxEvent (сказывается тяжелое наследие PLC)
Хотя, для меня не составит труда сделать и по-Вашему.
И вообще - HAL существует и при моем подходе (куда же без него), но без ОС.
И я не месил бы в кучу абстрагирование от железа и ОС.


Цитата(dxp @ 6.1.2012, 11:47) *
Зато с вытесняющей осью целевая задача решается вообще без напрягов.

Приведенная Вами задача решена мною без всяких ОС на PIC18F при разработке терморегулятора с двухстрочным индикатором, кнопками и Modbus/RTU на RS485. Там как раз и было все, что Вами упомянуто. Плавающая запятая при расчете температуры по термо ЭДС, то же самое для ПИД, плюс к этому, линеаризация для фазового управления. Туда же была встроена проверка на коротыш и обрыв при включении тиристора. Ну и само фазовое управление для трехфазной сети без рабочего нуля. С учетом фильтрации моментов перехода через ноль каждой из фаз. Задача чудным образом решается исключительно с помощью автоматов и прерываний на МК всего лишь с двумя уровнями приоритетов. Контроллер приоритетов эмулируется непосредственно при программном поллинге флагов. Поверьте, это совсем незначительное количество команд на ASM-е.
Цитата(dxp @ 6.1.2012, 11:47) *
Подобная вытесняющая RTOS во многом аналогична аппаратному приоритетному контроллеру прерываний, но реализованная программно, поэтому имеет недостаток в виде накладных расходов и достоинство в виде большей гибкости.

Ну и какой же тогда смысл в ОС, если у большинства современных МК это добро есть в аппаратном виде?
А если, вдруг, нет, то это опять же Ваша недоработка.
Перейти в начало страницы
 
+Цитировать сообщение
_pasha
сообщение 7.1.2012, 12:21
Сообщение #20


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

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



Цитата(dxp @ 6.1.2012, 9:47) *

Да, плавучие калькуляторы ложатся исключительно на вытесняющую ось. В общем-то все задачи, где муторно прерывать поток всякими йелдами и релаксами.
Перейти в начало страницы
 
+Цитировать сообщение

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

 



Текстовая версия Сейчас: 21.8.2018, 13:36