RTOS: распространенные заблуждения, Обсудим? |
Здравствуйте, гость ( Вход | Регистрация )
RTOS: распространенные заблуждения, Обсудим? |
Гость_MrYuran_* |
21.2.2012, 6:49
Сообщение
#121
|
Гости |
Есть открытое ядро openmsp430. Ввиду заточенности под микропотребление оно очень компактно и структурировано.
А есть вот такое чудо: Код Параметры процессоров Характеристика Старый вариант Новый на EP1K50QC208-2 нa EP2C20F484C7 Разрядность, бит 16 16/32/64 тактовая частота, MHz 100 159/129/98 Длительность цикла, тактов 5 и более 1..2 Занимаемый объем, LE ~700 794/1517/3010 Основная фишка - экономия памяти программ (компактный байт-код) |
|
|
21.2.2012, 8:53
Сообщение
#122
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Есть открытое ядро openmsp430. Ввиду заточенности под микропотребление оно очень компактно и структурировано. А есть вот такое чудо: Основная фишка - экономия памяти программ (компактный байт-код) Это всё полноценные "толстые" ядра. А там речь шла о микроядре, которое умеет делать ограниченный набор действий, требуемых для данного конкретного места. И таких микроядер в проекте может быть десяток и больше - каждое на своём месте. Своего рода программируемый автомат - именно как замена сложным КА. |
|
|
21.2.2012, 19:16
Сообщение
#123
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Проектирование на аппаратном уровне при прочих равных всегда сложнее где-то на порядок, чем на программном. Позволю себе не согласиться. Для меня, к примеру, нет разницы. Поскольку корни этого дела - одни и те же. В случае же такого ядра, оно разрабатывается один раз (при необходимости можно добавлять команды, это в имеющейся канве не слишком сложный процесс) и используется единообразно. Логику работы можно гибко менять, загружая микропрограмму прямо на рантайме - это второе качественное преимущество микроядра перед автоматом. Что касается самих микро-ядер, то они тоже автоматы и после добавления команд их так же надо верифицировать. И где гарантия, что в микропрограмме не будет ошибок? Другое дело, что здесь можно сократить время проектирования, при условии, что имеется поток проектов. |
|
|
22.2.2012, 4:35
Сообщение
#124
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Позволю себе не согласиться. Для меня, к примеру, нет разницы. Поскольку корни этого дела - одни и те же. Если попробовать, к примеру, сделать парсер протокола программно для процессора и его же (или аналогичный) аппаратно на ПЛИС, то разница становится сразу же отчётливо понятной. В первом случае алгоритм кодируется на базе отработанной аппаратной платформы, во втором - алгоритм реализуется в виде аппаратной платформы, которую нужно ещё спроектировать и отладить. Это значительно более сложное и трудоёмкое дело, поверьте. Даже простой парсер - это куча логики, триггеров, где критичен каждый такт - ошибся на такт, ничего не работает, и где искать, фиг знает. Конечно, рулят продвинутые HDL и средства верификации (симуляторы, методологии), но даже при их использовании процесс далеко не прост. Конечно, это даёт свои преимущества: скорость за счёт параллельности выполнения, реализация, заточенная под конкретную задачу на аппаратном уровне, поэтому несмотря на все сложности подход живёт и процветает. Но есть простое железное правило, которое рулит в 99.9% случаев: всё, что можно хорошо сделать программно - надо делать программно! Что касается самих микро-ядер, то они тоже автоматы и после добавления команд их так же надо верифицировать. И где гарантия, что в микропрограмме не будет ошибок? Да, надо верифицировать. Но это делается один раз и потом микроядро используется без проблем. А ошибки в микропрограмме отлавливаются на раз - микропрограммы по объёму небольшие, по тексту сразу видно, что делается. В отличие от аппаратных автоматов, где куча логики работает распределённо и параллельно. В этих делах без хорошего HDL симулятора делать вообще нечего, в то время как с классическими программами, даже достаточно сложными, симуляторы вообще почти не используются (ну разве что на этапе освоения платформы). |
|
|
22.2.2012, 21:24
Сообщение
#125
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
всё, что можно хорошо сделать программно - надо делать программно! Да кто бы спорил. Я здесь с Вами абсолютно согласен. В этих делах без хорошего HDL симулятора делать вообще нечего, в то время как с классическими программами, даже достаточно сложными, симуляторы вообще почти не используются (ну разве что на этапе освоения платформы). С ПЛИС у меня опыт не очень богатый. Quartus II от Alter-ы. Язык VHDL. Но разницы не заметил. Поскольку при моем подходе симулятор используется по полной программе. А что касается парсера, то для MODBUS во всех ипостасях можно хоть сейчас. Автоматы все прорисованы. Лежат в папочке со сделанными проектами. |
|
|
29.2.2012, 20:35
Сообщение
#126
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
http://electronix.ru/forum/index.php?showt...t&p=1032682 Битва титан(ик)ов. Этот дядя давно на элх не заходил и, по ходу, рамсы попутал. Он и раньше отличался менторским тоном, но на этот раз его что-то зашкалило. Таких надо один раз предупреждать, а потом банить безпощадно. |
|
|
1.3.2012, 18:05
Сообщение
#127
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
1.3.2012, 19:21
Сообщение
#128
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Просто скрыто. .... Что-то рациональное в словах персонажа имеется. Но это рациональное покрыто толстым слоем ЧСВ этого перца. А обсудить в данном контексте есть чего, ПМСМ. К примеру, тот же реал-тайм. Кто и что под этим понимает. К примеру, событийное программирование. С детерминированным временем реакции на событие. ПМСМ, верный путь к реал-тайму. P. S. Насчет PLC персонаж не совсем в теме. Как я говорил, есть PLC, работающие исключительно по прерываниям. Прерывания так же являются неотъемлемой сущностью современных дешевых PLC, даже китайских. Да и суперлупов в современных PLC далеко не один. Каждый суперлуп имеет гарантированное время одного прохода. |
|
|
1.3.2012, 22:27
Сообщение
#129
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Так как они обсуждают ОСи, то рилтайм в этом контексте завязан на возможности проца. То есть голый проц (любой) есть 100% рилтаймовый. Не скажите. Если имеется бортовой кэш команд, и его надо разгрузить (иногда такое случается), то... ПМСМ, здесь можно вести речь только о моторах с ограниченным пипелайном. А уже относительно его возможностей, ограничения и задержки вносимые самой ОСью можно обсуждать. Так вот, во Фриртос@ARM можно получать максимальную реакцию на аппаратные события. И я такое делал. Если кто-то этого не умеет и твердит, что это невозможно, то это его личные проблемы. Первое, что приходит в голову - это событийный вариант. Но возня с сообщениями, ПМСМ, несколько тяжеловесна. Или что-то еще? |
|
|
2.3.2012, 2:21
Сообщение
#130
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Да и суперлупов в современных PLC далеко не один. Каждый суперлуп имеет гарантированное время одного прохода. Сейчас как раз по принципу ПЛК пишу одну фиговину. 1. Получил данные со входных модулей 2. Обработал 3. Разослал по выходным модулям. Время реакции, к счастию, 10мс. Слона можно съесть. Зато писанины оч много. Параллельно жки /кнопки/линк тот самый, микроскопический. Как задолбала систематизация конфигурационных параметров!!! Раньше пытался как-то через ёксель разруливать, но быстро понял, что это все фигня. Кстати, ось и тут не нужна абсолютно, даже прототреды даром не нать. Все разруливается функциями в карусельке , с блокировкой рекурсивного вызова. Потому что все задачи слабо связаны между собой |
|
|
2.3.2012, 5:24
Сообщение
#131
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Мои пять копеек.
Термин "система реального времени" имеет смысл только в контексте приложения. Если устройство (программно-аппаратный комплекс) успевает отрабатывать события по мере их возникновения, то это система (в общем смысле, не обязательно ОС) реального времени. Что касается ОС, то тут применим этот же самый критерий, но на практике он слишком размытый и неконкретный, поэтому вводят всякие более узкие критерии - например, время реакции на событие и его детерминированность. Понятно, что и тут есть определённые условности - с какой точностью детерминированность и т.п. По факту к RTOS относят системы, при проектировании которых разработчики позаботились о механизмах быстрой реакции на события и передачи управления. Т.е. обычно есть понятие прерывания на низком уровне и завязки на передачу управления по событиям, возникающим в прерываниях. Это может быть мелкая RTOS на голом МК, а может быть и приличных размеров система, но не монолитная, а разделённая на уровни, один из которых близок к "железу" в указанном смысле - обычно этот уровень реализуется в виде микроядра (т.е. как бы в большой ОС есть внутри где-то мелкая RTOS, которая и обеспечивает более-менее жёсткий реалтайм). Если отвлечься от определений и формулировок и говорить о фактической ситуации, с которой сталкивается разработчик на практике, то системой реального времени для него является такая, где он может держать под контролем процесс. Т.е. не только вычислить величину задержки между возникновением события и передачей управления коду, который должен это событие обрабатывать, но чётко знать и понимать все внутренние механизмы работы системы, все цепочки прохождения сигналов, чтобы учитывать это при организации кода. Как правило, это достижимо в относительно небольших системах, где внутреннее устройство относительно несложное и обозримое. В толстых десктопных осях типа венды или линя с этим много сложнее - там внутри работает очень много различных процессов, и на деле практически невозможно учесть всё их влияние. Это неудивительно - ведь при проектировании таких ОС не ставилась задача обеспечения RT. Если разработчик программно-аппаратного комплекса может удерживать под контролем временнЫе характеристики прибора, то для него это система реального времени. Иначе - нет. |
|
|
2.3.2012, 12:24
Сообщение
#132
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
ИМХО с такими формулировками вечный холивар обеспечен. Кроме прочего, есть разные алгоритмы буферизации под той же вендой. Тогда и венду можно называть системой реального времени. Естественно. Вот я загружаю UT и гоняю годлайков - динамика сумасшедшая, а всё успевает в реальном времени - и реакция на клавиши и мышь, и прорисовка экрана (ЖК мониторы тормозят всё же, ЭЛТ рулят тут без базара). Хотя венда. Получается этот комплекс вполне реального времени. А холиварят пусть те, кому заняться нечем. То, что контекст всё определяет, с этим спорить глупо. Поэтому чёткое определения никто не даст. И слова RT в аббревиатуре RTOS - это не более, чем качественная характеристики и маркетинговый ход. Никаких точных количественных характеристик по динамике тут в общем случае не получить. Вот я знаю, что у меня в оси время передачи управления (от возникновения события до того момента, когда получит управление код процесса, ответственный за обработку) 1.5 мкс при 200 МГц тактовой (Blackfin), но это в идеальных условиях, т.е. когда нету другого более приоритетного процесса, готового к выполнению, когда не висит запросов на прерывания, когда нет длинных критических секций и т.д. Поэтому реальное время передачи управления будет каким-то другим. Иное дело, что я знаю все эти нюансы, могу оценить эти временные лаги и определить наихудший случай задержки, а при необходимости и переделать код так, чтобы избежать нежелательных задержек и улучшить время реакции (хотя в подавляющем большинстве случаев этого не требуется). Но и на каком-нить embedded линухе тоже можно затюнить так, что времянки будут с достаточной степенью точности предсказуемыми (пообрезать фичи, повыгрузить все демоны и т.д.). Но в случае мелкой ОС этот процесс проще и с более предсказуемым результатом. Это всё сказано к тому, что главное, чтобы разработчик понимал, что он делает, с чем имеет дело. А как это называется - дело пятнадцатое, и это тоже все должны понимать. И тут нет ни причины, ни повода для холиваров. Имхо. Мне кажется, что любой человек, кто имел хоть раз дело с этими вещами, быстро понимает суть. Во всяком случае, думается, все местные участники вполне адекватно разбираются в теме. |
|
|
2.3.2012, 20:44
Сообщение
#133
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
2.3.2012, 21:15
Сообщение
#134
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Но тогда получается, что все решают испытания изделия в целом. А это уже дело вероятностное. Дык вся жизнь вероятностная. Но ведь от того, что нечто назвали "системой реального времени", оно не делается чем-то архинадёжным. Надёжность определяется тщательностью проработки основных концепций и отработкой мелочей. Думается, что вы это лучше меня знаете. Когда звучит термин "система реального времени", я всегда стараюсь понять контекст, в котором он употреблён. Обычно термин несёт смысл уточнения, но не утверждения. А вне контекста это пустой звук. Ровно как и слово "свобода". |
|
|
2.3.2012, 21:34
Сообщение
#135
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Дык вся жизнь вероятностная. Но ведь от того, что нечто назвали "системой реального времени", оно не делается чем-то архинадёжным. Надёжность определяется тщательностью проработки основных концепций и отработкой мелочей. Это точно. Завтра с утра пойду отрабатывать мелочи. Необходимо измерить напряжение на выходе импульсного источника тока. Желательно за 1 такт. Пока на устройствах выборки/хранения, дабы понять физику процесса, а потом буду думать. Когда звучит термин "система реального времени", я всегда стараюсь понять контекст, в котором он употреблён. Обычно термин несёт смысл уточнения, но не утверждения. А вне контекста это пустой звук. Ровно как и слово "свобода". Но, как ни странно, многие пользуются этими словами вне контекста. Но это уже другая тема... |
|
|
3.3.2012, 6:20
Сообщение
#136
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Но, как ни странно, многие пользуются этими словами вне контекста. Но это уже другая тема... А вот тут и возникает почва для холиваров. Употребляя термин, одни имеют в виду одно, а другие другое. И дальше начинается ломание копий на пустом месте. Было много раз и повторяется регулярно. Хотите сказать, что термин "операционная система реального времени" по сути бесполезен, если не вреден? И у неё нет никаких отличительных признаков на уровне архитектуры? Мне почему-то кажется, есть. Не, не хочу такого сказать. Смысл в нём есть, он характеризует акцент обсуждаемого/озвучиваемого. Но характеристика эта скорее качественная. Вроде того, когда говорят "высококачественный" или "быстродействующий". Тут ведь не определятся степень качественности и быстродействия (помнится, были времена, когда ОУ с частотой единичного усиления 10 МГц считался "быстродействующим"), а лишь делается акцент на одной из фич по назначению. Когда я слышу термин "операционная система реального времени", у меня включается образ небольшой системы, где есть "завязки" на систему прерываний аппаратной платформы, где все внутренние связи простые и короткие, что даёт хорошую предсказуемость поведения в смысле обработки потока событий, что неизменно влечёт относительно простую внутреннюю организации систему. Термин помогает лучше понять контекст обсуждаемого, но именно в качественном смысле (навроде как термин "быстродействующий" сообщает, что автор тут хотел подчеркнуть это качество элемента), поэтому смысл, конечно, есть. В этом контексте. Плохо то, что все этот смысл понимают по-разному, и получаются те самые холивары (разного рода конфликты чаще всего и возникают из-за разного понимания контекста, а слова иные (не обязательно технические термины, любые - как уже приводил - "свобода") тут не только не помогают, но и усугубляют. Последний срач на элхе на тему, как раз, "реального времени" является ярким примером. |
|
|
3.3.2012, 8:32
Сообщение
#137
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
|
|
|
3.3.2012, 19:50
Сообщение
#138
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
3.3.2012, 20:28
Сообщение
#139
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
|
|
|
3.3.2012, 20:35
Сообщение
#140
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Система РТОС должна предоставлять возможность (или [эквивалентно] не ограничивать) создание юзер-кода с максимально возможной реакцией проца. +500 Я сам подумывал о двухслойности. Внизу - рукописная система прерываний под конкретный набор задач. Вверху - ОС под долгоиграющие и GUI-евые задачи. Вам не нгавятся пгоценты? згя, батенька, згя Пгоценты - наше фсе. |
|
|
Текстовая версия | Сейчас: 29.3.2024, 11:54 |